1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E1B1E8BF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Nov 2018 20:29:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4EAC0196
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Nov 2018 20:29:12 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1gPCdw-0001bM-0c; Wed, 21 Nov 2018 06:29:10 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 21 Nov 2018 06:29:04 +1000
Date: Wed, 21 Nov 2018 06:29:04 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20181120202904.gmbg5ebegvsgqfys@erisian.com.au>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 20 Nov 2018 23:23:21 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2018 20:29:13 -0000
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
|
