From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Wed, 21 Nov 2018 06:29:04 +1000 [thread overview]
Message-ID: <20181120202904.gmbg5ebegvsgqfys@erisian.com.au> (raw)
In-Reply-To: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote:
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> and SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, but:
> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> the subsequent opcode/push is removed.
> * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
> * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143
tx digest consists of the hash of:
1 nVersion
4 outpoint
5 input scriptCode
6 input's outpoint value
7 input's nSeq
9 nLocktime
10 sighash
2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)
3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)
8 hashOutputs
- NONE: 0
- SINGLE: {value,scriptPubKey} for corresponding output
- otherwise: {value,scriptPubKey} for all outputs
The fee is committed to by hashPrevOuts and hashOutputs, which means
NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is set.
For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges (5))
is only useful given NOINPUT, since (4) indirectly commits to (5).
Given this implementation, NOINPUT effectively implies ANYONECANPAY,
I think. (I think that is also true of BIP 118's NOINPUT spec)
Does it make sense to treat this as two classes of options, affecting
the input and output side:
output: (pick one, using bits 0,1)
* NONE -- don't care where the money goes
* SINGLE -- want this output
* ALL -- want exactly this set of outputs
input: (pick one, using bits 4,5)
* PARTIALSCRIPT -- spending from some tx with roughly this script (and
maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)
* KNOWNSCRIPT -- spending from some tx with exactly this script (and
maybe others; NOINPUT|ANYONECANPAY)
* KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)
* ALL_INPUTS -- spending from exactly these txes
combo: (flag, bit 6)
* NOFEE -- don't commit to the fee
I think NONE without NOFEE doesn't make much sense, and
NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to
warn/error on signing when asking for those combinations, and maybe even
to fail on validating them.
(Does it make sense to keep SIGHASH_NONE? I guess SIGHASH_NONE|ALL_INPUTS
could be useful if you just use sigs on one of the other inputs to commit
to a useful output)
FWIW, OP_MASK seems a bit complicated to me. How would you mask a script
that looks like:
OP_MASK IF <p> ENDIF <q> ...
or:
IF OP_MASK ENDIF <p> ...
I guess if you make the rule be "for every OP_MASK in scriptCode the
*immediately* subsequent opcode/push is removed (if present)" it would
be fine though -- that would make OP_MASK in both the above not have
any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH"
or something might be good?)
I don't have a reason why, but committing to the scriptCode feels to me
like it reduces the "hackiness" of NOINPUT a lot.
Cheers,
aj
next prev parent reply other threads:[~2018-11-20 20:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 22:37 Pieter Wuille
2018-11-20 20:29 ` Anthony Towns [this message]
2018-11-21 11:20 ` Christian Decker
2018-11-21 17:55 ` Johnson Lau
2018-11-21 11:15 ` Christian Decker
2018-11-23 6:04 ` Anthony Towns
2018-11-23 9:40 ` Christian Decker
2018-11-24 8:13 ` Johnson Lau
2018-11-21 17:07 ` Russell O'Connor
2018-11-22 14:28 ` Johnson Lau
2018-11-22 16:23 ` Russell O'Connor
2018-11-22 20:52 ` Johnson Lau
2018-11-22 22:10 ` Russell O'Connor
2018-11-23 10:47 ` Johnson Lau
2018-11-23 5:03 ` Anthony Towns
2018-11-23 20:18 ` Russell O'Connor
2018-11-28 3:41 ` Pieter Wuille
2018-11-28 8:31 ` Johnson Lau
2018-11-29 17:00 ` Christian Decker
2018-11-29 18:29 ` Christian Decker
2018-12-06 16:57 ` Russell O'Connor
2018-12-09 19:13 ` Johnson Lau
2018-12-11 22:50 ` Russell O'Connor
2018-12-12 19:53 ` Johnson Lau
2018-12-13 16:50 ` Russell O'Connor
2018-12-13 0:05 ` Anthony Towns
2018-12-13 16:21 ` Russell O'Connor
2018-12-14 0:47 ` Anthony Towns
[not found] ` <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
2018-12-13 16:34 ` Russell O'Connor
2018-12-09 22:41 ` David A. Harding
2018-12-11 15:36 ` Russell O'Connor
2018-12-11 17:47 ` David A. Harding
2018-12-12 9:42 ` Rusty Russell
2018-12-12 20:00 ` Johnson Lau
2018-12-12 23:49 ` Rusty Russell
2018-12-13 0:37 ` Rusty Russell
2018-12-14 9:30 ` Anthony Towns
2018-12-14 13:55 ` Johnson Lau
2018-12-17 3:10 ` Rusty Russell
2018-12-20 19:34 ` Johnson Lau
2018-12-20 23:17 ` Rusty Russell
2018-12-21 18:54 ` Johnson Lau
2018-12-23 4:26 ` Anthony Towns
2018-12-23 16:33 ` Johnson Lau
2018-12-24 12:01 ` ZmnSCPxj
2018-12-24 21:23 ` Johnson Lau
2018-12-16 6:55 ` Rusty Russell
2018-12-17 19:08 ` Johnson Lau
2018-12-18 4:22 ` Peter Todd
2018-12-19 0:39 ` Rusty Russell
2019-02-09 0:39 ` Pieter Wuille
2018-12-13 0:24 ` Anthony Towns
2018-11-28 0:54 Bob McElrath
2018-11-28 8:40 ` Johnson Lau
2018-11-28 14:04 ` Bob McElrath
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=20181120202904.gmbg5ebegvsgqfys@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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