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. http://p.sf.net/sfu/gigenet _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
