From: Gregory Maxwell <greg@xiph•org>
To: Johnson Lau <jl2012@xbt•hk>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme
Date: Mon, 2 Jul 2018 18:23:48 +0000 [thread overview]
Message-ID: <CAAS2fgRZS+mOhXeC462Vaib+KEuYm_2hWXSX-XxMmaUwhi+tHw@mail.gmail.com> (raw)
In-Reply-To: <9CCCE945-9432-41B9-8559-AFE7CF233603@xbt.hk>
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.
next prev parent reply other threads:[~2018-07-02 18:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 18:35 Johnson Lau
2018-06-01 15:03 ` Russell O'Connor
2018-06-01 17:03 ` Johnson Lau
2018-06-01 18:15 ` Russell O'Connor
2018-06-01 18:45 ` Johnson Lau
2018-07-02 18:23 ` Gregory Maxwell [this message]
2018-08-30 20:38 ` Johnson Lau
2018-08-30 20:51 ` Christian Decker
2018-08-31 7:42 ` Johnson Lau
2018-09-03 13:53 ` Christian Decker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgRZS+mOhXeC462Vaib+KEuYm_2hWXSX-XxMmaUwhi+tHw@mail.gmail.com \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox