From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YEjmF-0005bn-B4 for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 19:20:19 +0000 X-ACL-Warn: Received: from mail-ig0-f172.google.com ([209.85.213.172]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YEjmC-00088N-Dv for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 19:20:17 +0000 Received: by mail-ig0-f172.google.com with SMTP id l13so3578845iga.5 for ; Fri, 23 Jan 2015 11:20:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=PVHo9YdGO9birKDVCf7oSYynnFeixfkkx32MI0U+rOY=; b=nMIWLBFTnVJLSow/HbTnxa2efZ6+EWGZw+qY92W64P1lB2AT61pbkeCNvb/qprwk98 e7cL73r0PZirS36Oci3Q46o1njWUIcY/iT11t3Ih+dLniqTGw8D1CI1MqVEtgrpxLt+s IBvvZTjIwII3bg70VcuOfa0So4PDgZPDzi8brS4SKquKtZk/0r3LoQ+9gjA6dqseQQzn XjlSyMAa149AX4SxyBVFteNfgQvglGOQabynANWQAx3NGuYA+425k3XHCzaxUPp2sa36 teSSCHnGnWyqE3acTEw1Q8NWgtMEVGbCHQ/SfVTpzzcj4efTtsJEn1sFUukUmDX+yeOb HbZQ== X-Gm-Message-State: ALoCoQlw/paBtfHx+sbkz+zWqGCUn3x9cI8BMIe5XwdUjJPRPFB1ujwuKO+lLUw3G+dg0+Kk24ue X-Received: by 10.50.118.97 with SMTP id kl1mr3641409igb.23.1422040811739; Fri, 23 Jan 2015 11:20:11 -0800 (PST) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 11:19:40 -0800 (PST) In-Reply-To: References: <54C267A1.8090208@gmail.com> From: slush Date: Fri, 23 Jan 2015 20:19:40 +0100 X-Google-Sender-Auth: 195LquVRSxDyFjpcQsCLTGfjnaE Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e013a111870d9fb050d56ad35 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YEjmC-00088N-Dv Cc: Bitcoin Development Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 19:20:19 -0000 --089e013a111870d9fb050d56ad35 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > On Fri, Jan 23, 2015 at 5:40 PM, slush 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). > --089e013a111870d9fb050d56ad35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You're right, there can be done some optimizations. Wo= rkarounds of workaround. All this adds complexity, which reduces the securi= ty.

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". D= ynamic 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_WITHINPUTVALU= E or
> similar we may cut hardware cost significantly.

I'm quite familiar with embedded development :), and indeed trez= or 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<= br> 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).

--089e013a111870d9fb050d56ad35--