MIME-Version: 1.0
Sender: marek@palatinus.cz
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
Message-ID: <CAJna-Hi3Q8vxFXRemmdnd131Bcq7RYrdfizbOt0oGXuDQFW3pw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013a111870d9fb050d56ad35
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Precedence: list

--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&#39;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">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">=
gmaxwell@gmail.com</a>&gt;</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 &lt;<a href=3D"mail=
to:slush@centrum.cz">slush@centrum.cz</a>&gt; wrote:<br>
&gt; Yes, the step you&#39;re missing is &quot;and build the table&quot;. D=
ynamic memory<br>
&gt; allocation is something you want to avoid, as well as any artifical<br=
>
&gt; restrictions to number of inputs or outputs. Current solution is slow,=
 but<br>
&gt; there&#39;s really no limitation on tx size.<br>
&gt;<br>
&gt; Plus there&#39;re significant restrictions to memory in embedded world=
. Actually<br>
&gt; TREZOR uses pretty powerful (and expensive) MCU just because it needs =
to do<br>
&gt; such validations and calculate such hashes. With SIGHASH_WITHINPUTVALU=
E or<br>
&gt; similar we may cut hardware cost significantly.<br>
<br>
</span>I&#39;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&#39;m certainly not expecting you to<b=
r>
perform dynamic allocation... but wasn&#39;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&#39;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&#39;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&#39;t another thing that I was missing).<br>
</blockquote></div><br></div>

--089e013a111870d9fb050d56ad35--