Hi, I noticed there was just a tiny bit of work left to be done to support basic bcash signing functionality. This PR just adds support for extra arguments like amount and fork_id when building a previous output in the TxInBuilder.
Then if fork_id is present we make sure the hash_type for signging that output is "all|fork_id"
I tried to make the changeset as small as possible, I also had to skip the validation after signing because fork_id outputs need the whole utxo and we only have the script in that context. The specs do check the signature though.
Also I don't know what could happen if someone wants to build a transaction with heterogeneous output types (fork_id and non-fork_id). It does not make sense to do that, and both BTC and BCH networks would reject it, but as I see the library does sanity checks for other things, then it may do it for this too.
There are a few other things about the internal APIs that could be cleaned up a bit now.
Hi, I noticed there was just a tiny bit of work left to be done to support basic bcash signing functionality. This PR just adds support for extra arguments like amount and fork_id when building a previous output in the TxInBuilder.
Then if fork_id is present we make sure the hash_type for signging that output is "all|fork_id"
I tried to make the changeset as small as possible, I also had to skip the validation after signing because fork_id outputs need the whole utxo and we only have the script in that context. The specs do check the signature though.
Also I don't know what could happen if someone wants to build a transaction with heterogeneous output types (fork_id and non-fork_id). It does not make sense to do that, and both BTC and BCH networks would reject it, but as I see the library does sanity checks for other things, then it may do it for this too.
There are a few other things about the internal APIs that could be cleaned up a bit now.
Let me know what you think :)