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
|
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 1Ym2CD-0007sD-Ab
for bitcoin-development@lists.sourceforge.net;
Sat, 25 Apr 2015 15:40:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.195 as permitted sender)
client-ip=209.85.212.195;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-wi0-f195.google.com;
Received: from mail-wi0-f195.google.com ([209.85.212.195])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ym2CB-0005x5-5B
for bitcoin-development@lists.sourceforge.net;
Sat, 25 Apr 2015 15:40:45 +0000
Received: by wivr20 with SMTP id r20so6208039wiv.3
for <bitcoin-development@lists.sourceforge.net>;
Sat, 25 Apr 2015 08:40:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.102.74 with SMTP id fm10mr6105056wib.25.1429976437155;
Sat, 25 Apr 2015 08:40:37 -0700 (PDT)
Received: by 10.194.185.68 with HTTP; Sat, 25 Apr 2015 08:40:37 -0700 (PDT)
In-Reply-To: <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com>
References: <552EF785.7000207@sky-ip.org>
<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
<552FDF73.6010104@sky-ip.org>
<CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com>
<CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com>
Date: Sat, 25 Apr 2015 11:40:37 -0400
Message-ID: <CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444812b92eb3805148e5573
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: 1Ym2CB-0005x5-5B
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
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: Sat, 25 Apr 2015 15:40:45 -0000
--f46d0444812b92eb3805148e5573
Content-Type: text/plain; charset=UTF-8
Hi Gregory,
In particular not covering the ID allows for transaction replay which
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers can
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
>
With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
specify that they are to be signed without the previous UTXO's
value/amount. This means that, at worst, replay attacks can send the money
to the same place it was sent before (which in many cases is likely not be
a loss of funds), and only if the amount sent to the reused address is the
exact same as it was before. I don't think this is worse than an attacker
being able to mutate their transaction and extort a merchant who accepts
zero-conf transactions. Anyway, not signing the input ID wouldn't exactly
be the norm, there would be a defined set of flags for standard use cases.
Not signing the input TXID would only be used in specialized cases, such as
setting up micropayment channels.
> There are no free lunches; the proposal linked to there is itself a
> game of wack-a-mole with assorted masking flags;
I agree that it is also a bit of wac-a-mole, but the defined space of
issues is possibly more limited here. There are only X number of things
that can be signed/not signed in a transaction, and the 'Build your own
nHashType' proposal enables you to fully specify which of those are being
signed. If you don't want to get burned by not fully signing your
transactions, then don't use the non-standard sighash flags.
many of which we have
> no notion of if they're useful for any particular application(s);
A few of the flags, indeed, may not ever be useful. But we can't predict
the future, and I think it's better to build in a more flexible solution
now than to wish we had more flexible nHashTypes later.
To the original point of this thread, hopefully the suggested proposal
won't be necessary as wallets will upgrade to use version 3 transactions
and the rules associated with them over time.
Best,
Stephen
--f46d0444812b92eb3805148e5573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Gregory,<br><div class=3D"gmail_extra"><br><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-l=
eft-style:solid;padding-left:1ex">In particular not covering the ID allows =
for transaction replay which<br>
can result in monetary losses far more severe than any possible<br>
mishandling of malleability could result in. Byzantine attackers can<br>
costlessly replay your old transactions any time anyone reuses an<br>
address, even accidentally (which cannot be easily prevented since<br>
they can race).<br></blockquote><div><br></div>With the SIGHASH_WITHOUT_PRE=
V_VALUE flag, signatures have to explicitly specify that they are to be sig=
ned without the previous UTXO's value/amount. This means that, at worst=
, replay attacks can send the money to the same place it was sent before (w=
hich in many cases is likely not be a loss of funds), and only if the amoun=
t sent to the reused address is the exact same as it was before. I don'=
t think this is worse than an attacker being able to mutate their transacti=
on and extort a merchant who accepts zero-conf transactions. Anyway, not si=
gning the input ID wouldn't exactly be the norm, there would be a defin=
ed set of flags for standard use cases. Not signing the input TXID would on=
ly be used in specialized cases, such as setting up micropayment channels.=
=C2=A0<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">There are no free lunches;=C2=A0 th=
e proposal linked to there is itself a<br>
game of wack-a-mole with assorted masking flags; </blockquote><div><br></di=
v><div>I agree that it is also a bit of wac-a-mole, but the defined space o=
f issues is possibly more limited here. There are only X number of things t=
hat can be signed/not signed in a transaction, and the 'Build your own =
nHashType' proposal enables you to fully specify which of those are bei=
ng signed. If you don't want to get burned by not fully signing your tr=
ansactions, then don't use the non-standard sighash flags.</div><div><b=
r></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">many of which we have<br>
no notion of if they're useful for any particular application(s); </blo=
ckquote><div><br></div><div>A few of the flags, indeed, may not ever be use=
ful. But we can't predict the future, and I think it's better to bu=
ild in a more flexible solution now than to wish we had more flexible nHash=
Types later.</div><div><br></div><div>To the original point of this thread,=
hopefully the suggested proposal won't be necessary as wallets will up=
grade to use version 3 transactions and the rules associated with them over=
time.=C2=A0</div><div><br></div><div>Best,</div><div>Stephen</div></div></=
div></div>
--f46d0444812b92eb3805148e5573--
|
