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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1YgP7M-00067P-Dh
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:56:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgP7K-00017D-S8
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:56:28 +0000
Received: by wiax7 with SMTP id x7so6887307wia.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 19:56:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.78.231 with SMTP id e7mr63788568wjx.33.1428634580854;
Thu, 09 Apr 2015 19:56:20 -0700 (PDT)
Received: by 10.194.151.197 with HTTP; Thu, 9 Apr 2015 19:56:20 -0700 (PDT)
In-Reply-To: <20150409172808.GB27775@muck>
References: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
<CANEZrP12kZ8vRAo=feprJ9_oRXUPKJ=iF6kZdxxbai=TxjzM9g@mail.gmail.com>
<CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
<CAJHLa0NgV=6D=TAy4sm_EAfYiZULK-d9GMcddW1-DZRHCE8Sew@mail.gmail.com>
<20150409172808.GB27775@muck>
Date: Thu, 9 Apr 2015 22:56:20 -0400
Message-ID: <CABHVRKQOSHBzkWGoKROcXJd-mKcb3FvLLdSYMgOZJ3gC1zjNnw@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bfcf2fab4ad94051355e818
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: 1YgP7K-00017D-S8
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: Fri, 10 Apr 2015 02:56:28 -0000
--047d7bfcf2fab4ad94051355e818
Content-Type: text/plain; charset=UTF-8
Regarding the re-hashing the transaction data once per input being a
bottleneck, I was mistakenly only thinking about this from the point of
view of the signer. Full nodes have to check all transactions' inputs,
which is much more costly, as the link Gavin posted shows.
On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <mike@plan99.net> wrote:
>
> Right, good point. I wonder if this sort of auto forwarding could even be
> a useful feature. I can't think of one right now.
>
I can think of a few convoluted use cases, but not any good ones. People
have definitely looked for this feature before, though, just look at this
Bitcoin SE post
<http://bitcoin.stackexchange.com/questions/1495/is-there-a-way-to-automatically-send-bitcoins-from-one-wallet-to-another>.
I think there are better ways to handle key management than
auto-forwarding, though. Anyone looking for this feature probably just
wasn't aware that there are better solutions.
On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <mike@plan99.net> wrote:
>
> Yes but is that fundamental or is there a way to avoid it? That's what I'm
> getting at.
>
In the bitcointalk article referenced, Sergio actually gave us the answer:
> Hash(Tx,previn-index) = Hash ( Hash(outputs) || Hash
(Inputs-with-script-cleared) || <previn-index> )
> (for SIGHASH_ALL)
> This way the values "Hash(outputs)" and
"Hash(Inputs-with-script-cleared)" can be cached and reused.
Basically, just re-order the way stuff is serialized. Put the stuff that is
nearly always signed at the beginning, and vice versa. I'll see if I can
update the proposal to make this optimization possible. What I suspect,
though, is that with all the new controls, blocks with ordinary
transactions will verify faster, but an attacker could still create a very
CPU intensive block by signing inputs with a wide variety of nHashTypes and
then signing the last one with the equivalent of SIGHASH_ALL. I don't think
that's a big limitation, though, the attack is already somewhat possible,
and would be very hard to do, and doesn't really gain the attacker anything
(other than infamy).
On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd <pete@petertodd.org> wrote:
> For the OP: Have you looked at how CODESEPARATOR allows the signature to
> sign code to run as part of verifying the signature? E.g. my signature
> can say "valid if you run these additional opcodes and they return true"
> where those additional opcodes take the transaction, hash it in the
> defined way, and verify that the ECC signature correctly signs that
> hash and the hash of the additional opcodes. For instance in this case
> making a signature that's only valid if the tx fee is less than the
> defined amount would be a matter of GET_FEE <max fee + 1> LESSTHAN VERIFY
>
I've never been able to really see a good use case for OP_CODESEPARATOR,
and I'm not sure I completely have my head wrapped around what you're
proposing. From this
<http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparator-used-for>
and this
<https://bitcointalk.org/index.php?topic=52949.msg631255#msg631255>,
though, it seems like OP_CODESEPARATOR cannot really be made useful unless
you already have a way to sign without hashing the TXIDs referenced by your
input, in which case you need to modify the nHashType.
Best,
Stephen
--047d7bfcf2fab4ad94051355e818
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regarding the re-hashing the transaction data once per inp=
ut being a bottleneck, I was mistakenly only thinking about this from the p=
oint of view of the signer. Full nodes have to check all transactions' =
inputs, which is much more costly, as the link Gavin posted shows.=C2=A0<di=
v><br></div><div>On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn=C2=A0<span dir=
=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan=
99.net</a>></span>=C2=A0wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote">Right, good point. I wonder i=
f this sort of auto forwarding could even be a useful feature. I can't =
think of one right now.</div></div></div></blockquote><div><br></div><div>I=
can think of a few convoluted use cases, but not any good ones. People hav=
e definitely looked for this feature before, though, just look at <a href=
=3D"http://bitcoin.stackexchange.com/questions/1495/is-there-a-way-to-autom=
atically-send-bitcoins-from-one-wallet-to-another">this Bitcoin SE post</a>=
. I think there are better ways to handle key management than auto-forwardi=
ng, though. Anyone looking for this feature probably just wasn't aware =
that there are better solutions.</div><div><br></div><div>On Thu, Apr 9, 20=
15 at 10:45 AM, Mike Hearn=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:mik=
e@plan99.net" target=3D"_blank">mike@plan99.net</a>></span>=C2=A0wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">Yes but is that fundamental or is there a way to avoid it? That=
's what I'm getting at.</div></div></div></blockquote><div><br></di=
v><div>In the bitcointalk article referenced, Sergio actually gave us the a=
nswer:</div><div><br></div>> Hash(Tx,previn-index) =3D Hash ( Hash(outpu=
ts) || Hash (Inputs-with-script-cleared) || <previn-index> )<br>> =
=C2=A0 (for SIGHASH_ALL)<br>> =C2=A0 This way the values "Hash(outp=
uts)" and "Hash(Inputs-with-script-cleared)" can be cached a=
nd reused.<div><br></div><div>Basically, just re-order the way stuff is ser=
ialized. Put the stuff that is nearly always signed at the beginning, and v=
ice versa. I'll see if I can update the proposal to make this optimizat=
ion possible. What I suspect, though, is that with all the new controls, bl=
ocks with ordinary transactions will verify faster, but an attacker could s=
till create a very CPU intensive block by signing inputs with a wide variet=
y of nHashTypes and then signing the last one with the equivalent of SIGHAS=
H_ALL. I don't think that's a big limitation, though, the attack is=
already somewhat possible, and would be very hard to do, and doesn't r=
eally gain the attacker anything (other than infamy).=C2=A0<br><div><br></d=
iv><div>On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd <span dir=3D"ltr"><<a=
href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a=
>></span> wrote:<br></div></div></div></div><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><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">
For the OP: Have you looked at how CODESEPARATOR allows the signature to<br=
>
sign code to run as part of verifying the signature? E.g. my signature<br>
can say "valid if you run these additional opcodes and they return tru=
e"<br>
where those additional opcodes take the transaction, hash it in the<br>
defined way, and verify that the ECC signature correctly signs that<br>
hash and the hash of the additional opcodes. For instance in this case<br>
making a signature that's only valid if the tx fee is less than the<br>
defined amount would be a matter of GET_FEE <max fee + 1> LESSTHAN VE=
RIFY<br></blockquote><div><br></div><div>I've never been able to really=
see a good use case for OP_CODESEPARATOR, and I'm not sure I completel=
y have my head wrapped around what you're proposing. From=C2=A0<a href=
=3D"http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparat=
or-used-for">this</a>=C2=A0and=C2=A0<a href=3D"https://bitcointalk.org/inde=
x.php?topic=3D52949.msg631255#msg631255">this</a>, though, it seems like OP=
_CODESEPARATOR cannot really be made useful unless you already have a way t=
o sign without hashing the TXIDs referenced by your input, in which case yo=
u need to modify the nHashType.=C2=A0</div><div><br></div><div>Best,<br>Ste=
phen</div></div></div></div>
--047d7bfcf2fab4ad94051355e818--
|
