From: slush <slush@centrum.cz>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Date: Fri, 23 Jan 2015 18:40:54 +0100 [thread overview]
Message-ID: <CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgSKBS9zCQqp+hJUF2Ro8LNw4s0=J08M=76sOJmNfpLptQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
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@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?
>
[-- Attachment #2: Type: text/html, Size: 1486 bytes --]
next prev parent reply other threads:[~2015-01-23 17:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 14:51 [Bitcoin-development] SIGHASH_WITHINPUTVALUE slush
2015-01-23 15:24 ` Alan Reiner
2015-01-23 15:40 ` slush
2015-01-23 16:05 ` Gregory Maxwell
2015-01-23 16:18 ` slush
2015-01-23 16:52 ` Gregory Maxwell
2015-01-23 17:40 ` slush [this message]
2015-01-23 18:51 ` Gregory Maxwell
2015-01-23 19:19 ` slush
2015-01-23 16:23 ` Alan Reiner
2015-01-23 16:27 ` Alan Reiner
2015-01-23 16:33 ` Alan Reiner
2015-01-23 16:35 ` slush
2015-01-23 17:49 ` Peter Todd
2015-01-23 15:31 ` Tamas Blummer
2015-01-23 15:42 ` Alan Reiner
2015-01-23 15:47 ` slush
2015-01-23 16:08 ` Tamas Blummer
2015-01-23 16:12 ` Adam Back
2015-01-23 16:17 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com' \
--to=slush@centrum.cz \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gmaxwell@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox