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
|
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 <etotheipi@gmail.com>) id 1YEg64-0004Mr-QU
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 15:24:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.45 as permitted sender)
client-ip=209.85.216.45; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f45.google.com;
Received: from mail-qa0-f45.google.com ([209.85.216.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEg60-0007jf-GM
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 15:24:32 +0000
Received: by mail-qa0-f45.google.com with SMTP id n8so6219442qaq.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 07:24:23 -0800 (PST)
X-Received: by 10.140.28.54 with SMTP id 51mr14406267qgy.6.1422026658351;
Fri, 23 Jan 2015 07:24:18 -0800 (PST)
Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net.
[69.143.204.74])
by mx.google.com with ESMTPSA id r16sm1727340qay.10.2015.01.23.07.24.17
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 23 Jan 2015 07:24:17 -0800 (PST)
Message-ID: <54C267A1.8090208@gmail.com>
Date: Fri, 23 Jan 2015 10:24:17 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
In-Reply-To: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------010609060202080009000300"
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
(etotheipi[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: 1YEg60-0007jf-GM
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:24:32 -0000
This is a multi-part message in MIME format.
--------------010609060202080009000300
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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.=20
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?=20
>
> https://bitcointalk.org/index.php?topic=3D181734.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
> (=3Dsecurity 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 Ashbur=
n.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant=
=2E
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------010609060202080009000300
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#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. 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.<br>
<br>
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.<br>
<br>
I <b>strongly</b> 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). <br>
<br>
-Alan<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/23/2015 09:51 AM, slush wrote:<br>
</div>
<blockquote
cite="mid:CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com"
type="cite">
<div dir="ltr"><span style="font-size:13px">Hi,</span>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">is any progress or even discussion
in this area? </div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px"><a moz-do-not-send="true"
href="https://bitcointalk.org/index.php?topic=181734.0"
target="_blank">https://bitcointalk.org/index.php?topic=181734.0</a><br>
</div>
<div style="font-size:13px"><br>
</div>
<div style="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 40
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="font-size:13px"><br>
</div>
<div style="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 (=security
FTW), because 50% of actual codebase is solving this
particular downside of Bitcoin protocol.</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">So, there's real world problem. On
which solution can we as a community find a wide agreement?</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Best,</div>
<div style="font-size:13px">Marek</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
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 class="moz-txt-link-freetext" href="http://p.sf.net/sfu/gigenet">http://p.sf.net/sfu/gigenet</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------010609060202080009000300--
|
