On Fri, Jan 23, 2015 at 4:18 PM, slush <sl...@centrum.cz> wrote:
> Can you send me any reference about this? Of course if that solves the
> problem, hard fork would not be necessary anymore. I'm just not aware of
> any.

Sure; will aggregate up the citations when I'm not travling later today.

> To sign transaction with hundreds of inputs on device with limited memory
> capabilities, I need to stream all previous transactions into device, for
> every signed input.
> That means roughly 200^2 transaction verifications for 200 inputs to sign.
> Very slow, but does not limit the device for any particular size of signed
> transaction.

I'm not sure where the ^2 is coming from.  So what I'd understand that
you'd do is stream in the input txid:vouts which you spend, then you'd
stream the actual inputs which would just be hashed and value
extracted (but no other verification), and you'd build a table of
txid:vout->value, then the actual transaction to be signed.

This should have O(inputs) hashing and communications overhead. Is
there a step I'm missing?

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.
Bitcoin-development mailing list

Reply via email to