Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-02 📝 Original message:On Thu, May 31, 2018 at ...
📅 Original date posted:2018-07-02
📝 Original message:On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev
<bitcoin-dev at 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.
📝 Original message:On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev
<bitcoin-dev at 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.