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).
>