On Fri, Jan 23, 2015 at 5:40 PM, slush <sl...@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). ------------------------------------------------------------------------------ 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
