On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > The bit 0 to 3 of hashtype denotes a value between 0 and 15: > > • If the value is 1, the signature is invalid. > • If the value is 3 or below, hashPrevouts is the hash of all input, > same as defined in BIP143. Otherwise, it is 32-byte of 0x0000......0000. > • If the value is 7 or below, outpoint is the COutPoint of the > current input. Otherwise, it is 36-byte of 0x0000......0000. > • If the value is 0, hashSequence is the hash of all sequence, same > as defined in BIP143. Otherwise, it is 32-byte of 0x0000......0000. > • If the value is even (including 0), nSequence is the nSequence of > the current input. Otherwise, it is 0x00000000. > • If the value is 6, 7, 10, 11, 14, or 15, nInputIndex is 0x00000000. > Otherwise, it is the index of the current input. > • If the value is 11 or below, nAmount is the value of the current > input (same as BIP143). Otherwise, it is 0x0000000000000000. > > The bit 4 and 5 of hashtype denotes a value between 0 and 3: > > • If the value is 0, hashOutputs is same as the SIGHASH_ALL case in > BIP143 as a hash of all outputs. > • If the value is 1, the signature is invalid. > • If the value is 2, hashOutputs is same as the SIGHASH_SINGLE case > in BIP143 as a hash of the matching output. If a matching output does not > exist, hashOutputs is 32-byte of 0x0000......0000. > • If the value is 3, hashOutputs is 32-byte of 0x0000......0000. > If bit 6 is set (SIGHASH2_NOFEE), nFees is 0x0000000000000000. Otherwise, it > is the fee paid by the transaction. > If bit 7 is set (SIGHASH2_NOLOCKTIME), nLockTime is 0x00000000. Otherwise, it > is the transaction nLockTime. > > If bit 8 is set (SIGHASH2_NOVERSION), nVersion is 0x00000000. Otherwise, it > is the transaction nVersion. > > If bit 9 is set (SIGHASH2_NOSCRIPTCODE), scriptCode is an empty script. > Otherwise, it is same as described in BIP143. > > Bits 10 to 15 are reserved and ignored, but the signature still commits to > their value as hashtype. > > hashtype of 0 is also known as SIGHASH2_ALL, which covers all the available > options. In this case the singnature MUST be exactly 64-byte. > > hashtype of 0x3ff is also known as SIGHASH2_NONE, which covers nothing and is > effectively forfeiting the right related to this public key to anyone.
This seems fairly complicated and yet-- if I don't misunderstand-- it doesn't capture the one special output masking case that I've seen actual applications want (which itself, is one out of the only two special sighash cases I've seen applications want-- the other being no-input). The case I think this is missing is SIGHASH_SINGLE | SIGHASH_LAST_OUTPUT e.g. "Sign the matching output, and the last output regardless of its index". The application for this style is "kickstarter" joint-payment transactions where you wish to sign both your change output (SIGHASH_SINGLE) and the joint-payment output (SIGHASH_LAST_OUTPUT). Without it, this kind of usage requires usually a chain of depth two for each input to split off the change. I came back around to your post at Sipa's recommendation because I was musing on is there a _simple_ set of enhanced sighash flags that capture real useful behaviour without falling down a rathole of specifying a totally general behaviour. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
