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
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1YEgMQ-0005aQ-6g
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 15:41:26 +0000
X-ACL-Warn:
Received: from mail-ig0-f176.google.com ([209.85.213.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEgMM-0001zw-Kj
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 15:41:26 +0000
Received: by mail-ig0-f176.google.com with SMTP id hl2so2513465igb.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 07:41:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:cc:content-type;
bh=w4wa1HrLWWqQQOIQjj8wdfu9HqJD1I5+XNnDWUar0qk=;
b=CCIbpSmKUuLquMLn2JI9U4Y+t6PS9z/HsN5+3ClISXCwmd0DRpW6iM1BxoH3jO4ogJ
4PXGU/jbV7D97DQDBvXbCIgLsyoVXJGg12dLV6PTi1bDg8NjTDlYBZmPRC4gft066e2J
qtf5PkPLHh7XwN2G3SqBaAKoeCYUDzSp7M2axdwxr+J7pTs2bumipTa8mhd3U0Gmifwz
7TPHmI07O/qToOeOEALf8mRH1QjWLDo2Koc8hLgL3IAiKehPH2G97ADeIxb6Qn3m7paF
V2wVg24fcwNm0fUPX0A0sctwz7a9iwG5QkXbYUh6hlcYBqNVULX8qkhCLyzyO0NbUbpO
OBCA==
X-Gm-Message-State: ALoCoQlSxeB1WsDZe9pGutyvVbpiCZwcddsP0w+IMo89iI9kDQEtmLQNpsOrQIqAzWenXVU8Oa+J
X-Received: by 10.50.108.83 with SMTP id hi19mr2540738igb.8.1422027669772;
Fri, 23 Jan 2015 07:41:09 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 07:40:39 -0800 (PST)
In-Reply-To: <54C267A1.8090208@gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<54C267A1.8090208@gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 23 Jan 2015 16:40:39 +0100
X-Google-Sender-Auth: RAY-L56umuFGS0LJDI8QlQ24rdU
Message-ID: <CAJna-Hj1UrMx5bHmN2DXm2U-9uEmw2GN3z=SeF0oevibCV6zvw@mail.gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e01494c2a1e3896050d539e1d
X-Spam-Score: 3.0 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
2.8 MALFORMED_FREEMAIL Bad headers on message from free email service
-2.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YEgMM-0001zw-Kj
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
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, 23 Jan 2015 15:41:26 -0000
--089e01494c2a1e3896050d539e1d
Content-Type: text/plain; charset=ISO-8859-1
> I *strongly* encourage this to be considered for inclusion at some point.
Thanks Alan for a nice summary. I also agree that such stuff should be
implemented at some point. Anyway, I would probably not vote for doing hard
fork *just* for this change, but if I remember well, there're other ideas
flying around in the air and waiting for hardfork...
Marek
On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
> non-intrusive, doesn't change any TxOut scripts, doesn't change any
> tx/block parsing (besides verification), it works with all existing coins
> in the network, and existing software doesn't have to use it if they don't
> want to upgrade their signers. The proposal simply provides a way to
> optionally sign the input values with the TxOut scripts. In other words a
> signature right now says "I sign this transaction using these inputs,
> whatever value they are." With this SIGHASH type, the signature says "I
> sign this transaction assuming that input 0 is X BTC, input 1 is Y
> BTC,....". If the online computer providing the data to be signed lies
> about the value of any input, the resulting signature will be invalid.
>
> Unfortunately, it seems that there was no soft-fork way to achieve this
> benefit, at least not one that had favorable properties. Most of the
> soft-fork variations of it required the coins being spent to have been
> originated in a special way. In other words, it would only work if the
> coins had entered the wallet with some special, modified TxOut script. So
> it wouldn't work with existing coins, and would require senders to update
> their software to reshape the way they send transactions to be compatible
> with our goals.
>
> I *strongly* encourage this to be considered for inclusion at some
> point. Not only does it simplify HW as Marek suggested, it increases the
> options for online-offline communication channels, which is also a win for
> security. Right now, QR codes don't work because of the possibility of
> having to transfer megabytes over the channel, and no way to for the signer
> to control that size. With this change, it's possible for the signer to
> control the size of each chunk of data to guarantee it fits in, say, a QR
> code (even if it means breaking it up into a couple smaller transactions).
>
> -Alan
>
>
>
>
> On 01/23/2015 09:51 AM, slush wrote:
>
> Hi,
>
> is any progress or even discussion in this area?
>
> https://bitcointalk.org/index.php?topic=181734.0
>
> I don't insist on any specific solution, but this is becoming a real
> issue as hardware wallets are more widespread. I'm sitting next to TREZOR
> for 40 minutes already, because it streams and validate some complex
> transaction. By using proposed solution, such signature would be a matter
> of few seconds.
>
> That's also not just about time/resource/hw cost optimization. I'm
> talking about possibility of huge simplification of the firmware (=security
> FTW), because 50% of actual codebase is solving this particular downside of
> Bitcoin protocol.
>
> So, there's real world problem. On which solution can we as a community
> find a wide agreement?
>
> Best,
> Marek
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.http://p.sf.net/sfu/gigenet
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> T
--089e01494c2a1e3896050d539e1d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> I=A0<b>strongly</b>=A0encourage this to be consi=
dered for inclusion at some point.</div><div><br></div><div>Thanks Alan for=
a nice summary. I also agree that such stuff should be implemented at some=
point. Anyway, I would probably not vote for doing hard fork *just* for th=
is change, but if I remember well, there're other ideas flying around i=
n the air and waiting for hardfork...</div><div><br></div><div>Marek</div><=
div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri,=
Jan 23, 2015 at 4:24 PM, Alan Reiner <span dir=3D"ltr"><<a href=3D"mail=
to:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a>></span=
> wrote:<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">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change=
any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it
if they don't want to upgrade their signers. =A0 The proposal simpl=
y
provides a way to optionally sign the input values with the TxOut
scripts.=A0 In other words a signature right now says "I sign this
transaction using these inputs, whatever value they are."=A0 With =
this
SIGHASH type, the signature says "I sign this transaction assuming
that input 0 is X BTC, input 1 is Y BTC,....".=A0 If the online
computer providing the data to be signed lies about the value of any
input, the resulting signature will be invalid.<br>
<br>
Unfortunately, it seems that there was no soft-fork way to achieve
this benefit, at least not one that had favorable properties.=A0 Most
of the soft-fork variations of it required the coins being spent to
have been originated in a special way.=A0 In other words, it would
only work if the coins had entered the wallet with some special,
modified TxOut script.=A0 So it wouldn't work with existing coins, =
and
would require senders to update their software to reshape the way
they send transactions to be compatible with our goals.<br>
<br>
I <b>strongly</b> encourage this to be considered for inclusion at
some point.=A0 Not only does it simplify HW as Marek suggested, it
increases the options for online-offline communication channels,
which is also a win for security.=A0 Right now, QR codes don't work
because of the possibility of having to transfer megabytes over the
channel, and no way to for the signer to control that size.=A0 With
this change, it's possible for the signer to control the size of
each chunk of data to guarantee it fits in, say, a QR code (even if
it means breaking it up into a couple smaller transactions). <br>
<br>
-Alan<div><div><br>
<br>
<br>
<br>
<div>On 01/23/2015 09:51 AM, slush wrote:<br>
</div>
</div></div><blockquote type=3D"cite"><div><div>
<div dir=3D"ltr"><span style=3D"font-size:13px">Hi,</span>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px">is any progress or even discussion
in this area?=A0</div>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px"><a href=3D"https://bitcointalk.org/in=
dex.php?topic=3D181734.0" target=3D"_blank">https://bitcointalk.org/index.p=
hp?topic=3D181734.0</a><br>
</div>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px">I don't insist on any specific
solution, but this is becoming a real issue as hardware
wallets are more widespread. I'm sitting next to TREZOR for 4=
0
minutes already, because it streams and validate some complex
transaction. By using proposed solution, such signature would
be a matter of few seconds.</div>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px">That's also not just about
time/resource/hw cost optimization. I'm talking about
possibility of huge simplification of the firmware (=3Dsecurity
FTW), because 50% of actual codebase is solving this
particular downside of Bitcoin protocol.</div>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px">So, there's real world problem. O=
n
which solution can we as a community find a wide agreement?</div>
<div style=3D"font-size:13px"><br>
</div>
<div style=3D"font-size:13px">Best,</div>
<div style=3D"font-size:13px">Marek</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>----------------------------------------------------=
--------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
<a href=3D"http://p.sf.net/sfu/gigenet" target=3D"_blank">http://p.sf.net/s=
fu/gigenet</a></pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>
</pre>
</blockquote>
<br>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.<br>
GigeNET is offering a free month of service with a new server in Ashburn.<b=
r>
Choose from 2 high performing configs, both with 100TB of bandwidth.<br>
Higher redundancy.Lower latency.Increased capacity.Completely compliant.<br=
>
<a href=3D"http://p.sf.net/sfu/gigenet" target=3D"_blank">http://p.sf.net/s=
fu/gigenet</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
T</blockquote></div><br></div></div>
--089e01494c2a1e3896050d539e1d--
|
