Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2015-01-23 📝 Original message:On Fri, Jan 23, 2015 at ...
📅 Original date posted:2015-01-23
📝 Original message:On Fri, Jan 23, 2015 at 4:18 PM, slush <slush at 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?
📝 Original message:On Fri, Jan 23, 2015 at 4:18 PM, slush <slush at 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?