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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1YgDAV-0003a5-IM
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 14:10:55 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgDAP-0008Pe-El
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Apr 2015 14:10:55 +0000
Received: by wgin8 with SMTP id n8so121557095wgi.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 07:10:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.78.231 with SMTP id e7mr59036996wjx.33.1428588643432;
Thu, 09 Apr 2015 07:10:43 -0700 (PDT)
Received: by 10.194.151.197 with HTTP; Thu, 9 Apr 2015 07:10:43 -0700 (PDT)
In-Reply-To: <CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
<CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
Date: Thu, 9 Apr 2015 10:10:43 -0400
Message-ID: <CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bfcf2fa9f3c5305134b36a2
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(stephencalebmorse[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YgDAP-0008Pe-El
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2015 14:10:55 -0000
--047d7bfcf2fa9f3c5305134b36a2
Content-Type: text/plain; charset=UTF-8
Hi Mike,
Hi Stephen,
>
> It's an interesting idea. I'm not sure that all the combinations make
> sense. Excluding the connected output script or value but still signing the
> prev tx hash appears pointless: the script cannot change anyway, and you
> still need to know what it is to actually calculate the inputs to it, so
> what is the point of this?
>
That's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and
SIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data
anyway. That gets the total number of flags down to 17. If we eliminate
SIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one),
then we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could
also be removed, I'm not convinced of the usefulness of that one either.
>
> I also worry that quite a few of these combinations could be unexpectedly
> dangerous. If you don't sign the prevout hash or value and combine it with
> a regular pay-to-address output then you've effectively written a blank
> cheque that can be used by anyone, to claim any money ever sent to that
> address ... no? And then any p2p
>
node or miner could do so, making the transaction pretty useless.
>
> That isn't inherently a problem as long as people understand which
> combinations have what effects or cannot be used for various reasons. But
> it would need good documentation and careful thought to explore each
> possibility people might use.
>
I don't think it's quite a blank check, but it would enable replay attacks
in the form of sending the money to the same place it was sent before if an
address ever receives coins again. Almost like auto-forwarding addresses.
If, in addition, you signed with just that input and no outputs as well,
then you're basically forfeiting your rights to any coins sent to that
address.
It allows for some dangerous combinations, but we already have some
dangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good
documentation and careful developers shouldn't have any issues if they use
a standard set of sighash flag combinations for their standard use cases.
But developers that need special combinations can now use them, so long as
they are careful and think things through.
>
> I'll leave the soft fork business to one side for now. I think any change
> in CHECKSIG or new version of it would likely be ready around the same time
> as the hard fork we need for changing the block size limit anyway, and it's
> much cleaner to do it that way.
>
> The most important change that we need in sighash calculation, IMO, is
> ensuring that you don't have to hash data over and over again without a
> good reason. The current sighash definition is unfortunate because it's
> possible to make small transactions that involve hashing huge amounts of
> data. It's not clear to me that your proposal fixes that: ideally there
> would be one exactly one sighash for one transaction no matter how many
> checksigs are involved in verifying it.
>
>
It's hard, though, because there is different data needs to be signed for
each input. Although, I suppose if you signed your input with
SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the
equivalent of SIGHASH_ALL, then the hash that needs to be signed would be
the same for all of your inputs. Strangely enough, I think we might have
just found use cases for the flags that we had nearly dismissed.
Another possibility would be to put the previous scriptPubKey and previous
output value at the END of the serialized transaction, so that you could
make use of some sort of a signature hash midstate. But that feels a little
messy. It sort of makes sense to have a base serialization for a
transaction and then append it with whatever input/output specific
information you have, but still, messy.
Is hashing transaction data once for each input really a huge bottleneck,
though? Do mobile devices have an issue with this?
Best,
Stephen
--047d7bfcf2fa9f3c5305134b36a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Mike,<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr">Hi Stephen,<div><br></div><di=
v>It's an interesting idea. I'm not sure that all the combinations =
make sense. Excluding the connected output script or value but still signin=
g the prev tx hash appears pointless: the script cannot change anyway, and =
you still need to know what it is to actually calculate the inputs to it, s=
o what is the point of this?</div></div></blockquote><div><br></div>That=
9;s a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and SIGHASH_WITHO=
UT_PREV_VALUE should be assumed false, since you need the data anyway. That=
gets the total number of flags down to 17. If we eliminate SIGHASH_WITHOUT=
_TX_VERSION (I can't think of any good reason for this one), then we=
9;re down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could also be r=
emoved, I'm not convinced of the usefulness of that one either.<br><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>I also w=
orry that quite a few of these combinations could be unexpectedly dangerous=
. If you don't sign the prevout hash or value and combine it with a reg=
ular pay-to-address output then you've effectively written a blank cheq=
ue that can be used by anyone, to claim any money ever sent to that address=
... no? And then any p2p=C2=A0</div></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>node or miner could do so, making the transaction pre=
tty useless.</div><div><br></div><div>That isn't inherently a problem a=
s long as people understand which combinations have what effects or cannot =
be used for various reasons. But it would need good documentation and caref=
ul thought to explore each possibility people might use.</div></div></block=
quote><div><br></div><div>I don't think it's quite a blank check, b=
ut it would enable replay attacks in the form of sending the money to the s=
ame place it was sent before if an address ever receives coins again. Almos=
t like auto-forwarding addresses. If, in addition, you signed with just tha=
t input and no outputs as well, then you're basically forfeiting your r=
ights to any coins sent to that address.<br></div><div><br></div><div>It al=
lows for some dangerous combinations, but we already have some dangerous nH=
ashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good documentation and =
careful developers shouldn't have any issues if they use a standard set=
of sighash flag combinations for their standard use cases. But developers =
that need special combinations can now use them, so long as they are carefu=
l and think things through.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>I'll leave the soft fork business to one s=
ide for now. I think any change in CHECKSIG or new version of it would like=
ly be ready around the same time as the hard fork we need for changing the =
block size limit anyway, and it's much cleaner to do it that way.</div>=
<div><br></div><div>The most important change that we need in sighash calcu=
lation, IMO, is ensuring that you don't have to hash data over and over=
again without a good reason. The current sighash definition is unfortunate=
because it's possible to make small transactions that involve hashing =
huge amounts of data. It's not clear to me that your proposal fixes tha=
t: ideally there would be one exactly one sighash for one transaction no ma=
tter how many checksigs are involved in verifying it.</div><div><br></div><=
/div></blockquote><div><br></div><div>It's hard, though, because there =
is different data needs to be signed for each input. Although, I suppose if=
you signed your input with SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITH=
OUT_PREV_VALUE, and the equivalent of SIGHASH_ALL, then the hash that needs=
to be signed would be the same for all of your inputs. Strangely enough, I=
think we might have just found use cases for the flags that we had nearly =
dismissed.=C2=A0</div><div><br></div><div>Another possibility would be to p=
ut the previous scriptPubKey and previous output value at the END of the se=
rialized transaction, so that you could make use of some sort of a signatur=
e hash midstate. But that feels a little messy. It sort of makes sense to h=
ave a base serialization for a transaction and then append it with whatever=
input/output specific information you have, but still, messy.</div><div><b=
r></div><div>Is hashing transaction data once for each input really a huge =
bottleneck, though? Do mobile devices have an issue with this?</div><div><b=
r></div><div>Best,</div><div>Stephen</div></div></div></div>
--047d7bfcf2fa9f3c5305134b36a2--
|
