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 20:19:40 +0100 [thread overview]
Message-ID: <CAJna-Hi3Q8vxFXRemmdnd131Bcq7RYrdfizbOt0oGXuDQFW3pw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgThuM90uy7fUKxTY_h==S6VwEnYE5m3NBPJZEUtVjAK0w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]
You're right, there can be done some optimizations. Workarounds of
workaround. All this adds complexity, which reduces the security.
Marek
On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Fri, Jan 23, 2015 at 5:40 PM, slush <slush@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).
>
[-- Attachment #2: Type: text/html, Size: 2529 bytes --]
next prev parent reply other threads:[~2015-01-23 19:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 14:51 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
2015-01-23 18:51 ` Gregory Maxwell
2015-01-23 19:19 ` slush [this message]
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-Hi3Q8vxFXRemmdnd131Bcq7RYrdfizbOt0oGXuDQFW3pw@mail.gmail.com \
--to=slush@centrum$(echo .)cz \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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