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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1YEjmF-0005bn-B4
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 19:20:19 +0000
X-ACL-Warn:
Received: from mail-ig0-f172.google.com ([209.85.213.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEjmC-00088N-Dv
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 19:20:17 +0000
Received: by mail-ig0-f172.google.com with SMTP id l13so3578845iga.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 11:20:11 -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:to:cc:content-type;
bh=PVHo9YdGO9birKDVCf7oSYynnFeixfkkx32MI0U+rOY=;
b=nMIWLBFTnVJLSow/HbTnxa2efZ6+EWGZw+qY92W64P1lB2AT61pbkeCNvb/qprwk98
e7cL73r0PZirS36Oci3Q46o1njWUIcY/iT11t3Ih+dLniqTGw8D1CI1MqVEtgrpxLt+s
IBvvZTjIwII3bg70VcuOfa0So4PDgZPDzi8brS4SKquKtZk/0r3LoQ+9gjA6dqseQQzn
XjlSyMAa149AX4SxyBVFteNfgQvglGOQabynANWQAx3NGuYA+425k3XHCzaxUPp2sa36
teSSCHnGnWyqE3acTEw1Q8NWgtMEVGbCHQ/SfVTpzzcj4efTtsJEn1sFUukUmDX+yeOb
HbZQ==
X-Gm-Message-State: ALoCoQlw/paBtfHx+sbkz+zWqGCUn3x9cI8BMIe5XwdUjJPRPFB1ujwuKO+lLUw3G+dg0+Kk24ue
X-Received: by 10.50.118.97 with SMTP id kl1mr3641409igb.23.1422040811739;
Fri, 23 Jan 2015 11:20:11 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 11:19:40 -0800 (PST)
In-Reply-To: <CAAS2fgThuM90uy7fUKxTY_h==S6VwEnYE5m3NBPJZEUtVjAK0w@mail.gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<54C267A1.8090208@gmail.com>
<CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
<CAJna-HgL_-PTfmS-kA00DfZiZ8uPFqQTytihY6o8De5KVvDThw@mail.gmail.com>
<CAAS2fgSKBS9zCQqp+hJUF2Ro8LNw4s0=J08M=76sOJmNfpLptQ@mail.gmail.com>
<CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com>
<CAAS2fgThuM90uy7fUKxTY_h==S6VwEnYE5m3NBPJZEUtVjAK0w@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 23 Jan 2015 20:19:40 +0100
X-Google-Sender-Auth: 195LquVRSxDyFjpcQsCLTGfjnaE
Message-ID: <CAJna-Hi3Q8vxFXRemmdnd131Bcq7RYrdfizbOt0oGXuDQFW3pw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013a111870d9fb050d56ad35
X-Spam-Score: 1.3 (+)
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.0 HTML_MESSAGE BODY: HTML included in message
0.3 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YEjmC-00088N-Dv
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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 19:20:19 -0000
--089e013a111870d9fb050d56ad35
Content-Type: text/plain; charset=ISO-8859-1
You're right, there can be done some optimizations. Workarounds of
workaround. All this adds complexity, which reduces the security.
Marek
On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 5:40 PM, slush <slush@centrum.cz> wrote:
> > Yes, the step you're missing is "and build the table". Dynamic memory
> > allocation is something you want to avoid, as well as any artifical
> > restrictions to number of inputs or outputs. Current solution is slow,
> but
> > there's really no limitation on tx size.
> >
> > Plus there're significant restrictions to memory in embedded world.
> Actually
> > TREZOR uses pretty powerful (and expensive) MCU just because it needs to
> do
> > such validations and calculate such hashes. With SIGHASH_WITHINPUTVALUE
> or
> > similar we may cut hardware cost significantly.
>
> I'm quite familiar with embedded development :), and indeed trezor MCU
> is what I would generally consider (over-)powered which is why I was
> somewhat surprised by the numbers; I'm certainly not expecting you to
> perform dynamic allocation... but wasn't clear on how 40 minutes and
> was I just trying to understand. Using a table to avoid retransmitting
> reused transactions is just an optimization and can be done in
> constant memory (e.g. falling back to retransmission if filled).
>
> So what I'm understanding now is that you stream the transaction along
> with its inputs interleaved in order to reduce the memory requirement
> to two midstates and a value accumulator; requiring resending the
> transaction... so in the worst case transaction (since you can't get
> in more than about 800 inputs at the maximum transaction size) each
> input spending from (one or more, since even one would be repeated)
> 100kb input transactions you might send about 800MBytes of data, which
> could take a half an hour if hashing runs at 45KB/s or slower?
>
> (If so, okay then there isn't another thing that I was missing).
>
--089e013a111870d9fb050d56ad35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You're right, there can be done some optimizations. Wo=
rkarounds of workaround. All this adds complexity, which reduces the securi=
ty.<div><br></div><div>Marek</div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell <sp=
an dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">=
gmaxwell@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"">On Fri, Jan 23, 2015 at 5:40 PM, slush <<a href=3D"mail=
to:slush@centrum.cz">slush@centrum.cz</a>> wrote:<br>
> Yes, the step you're missing is "and build the table". D=
ynamic memory<br>
> allocation is something you want to avoid, as well as any artifical<br=
>
> restrictions to number of inputs or outputs. Current solution is slow,=
but<br>
> there's really no limitation on tx size.<br>
><br>
> Plus there're significant restrictions to memory in embedded world=
. Actually<br>
> TREZOR uses pretty powerful (and expensive) MCU just because it needs =
to do<br>
> such validations and calculate such hashes. With SIGHASH_WITHINPUTVALU=
E or<br>
> similar we may cut hardware cost significantly.<br>
<br>
</span>I'm quite familiar with embedded development :), and indeed trez=
or MCU<br>
is what I would generally consider (over-)powered which is why I was<br>
somewhat surprised by the numbers; I'm certainly not expecting you to<b=
r>
perform dynamic allocation... but wasn't clear on how 40 minutes and<br=
>
was I just trying to understand. Using a table to avoid retransmitting<br>
reused transactions is just an optimization and can be done in<br>
constant memory (e.g. falling back to retransmission if filled).<br>
<br>
So what I'm understanding now is that you stream the transaction along<=
br>
with its inputs interleaved in order to reduce the memory requirement<br>
to two midstates and a value accumulator; requiring resending the<br>
transaction... so in the worst case transaction (since you can't get<br=
>
in more than about 800 inputs at the maximum transaction size) each<br>
input spending from (one or more, since even one would be repeated)<br>
100kb input transactions you might send about 800MBytes of data, which<br>
could take a half an hour if hashing runs at 45KB/s or slower?<br>
<br>
(If so, okay then there isn't another thing that I was missing).<br>
</blockquote></div><br></div>
--089e013a111870d9fb050d56ad35--
|
