slush [ARCHIVE] on Nostr: 📅 Original date posted:2015-01-23 📝 Original message:Yes, the step you're ...
📅 Original date posted:2015-01-23
📝 Original message: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.
Marek
On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/20ba09ee/attachment.html>;
📝 Original message: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.
Marek
On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/20ba09ee/attachment.html>;