1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YEjK5-0004K5-64
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 18:51:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.178 as permitted sender)
client-ip=209.85.212.178; envelope-from=gmaxwell@gmail.com;
helo=mail-wi0-f178.google.com;
Received: from mail-wi0-f178.google.com ([209.85.212.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEjK3-0004ki-UE
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 18:51:13 +0000
Received: by mail-wi0-f178.google.com with SMTP id em10so4817535wid.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 10:51:06 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.84.240 with SMTP id c16mr17138916wjz.74.1422039066613;
Fri, 23 Jan 2015 10:51:06 -0800 (PST)
Received: by 10.27.11.170 with HTTP; Fri, 23 Jan 2015 10:51:06 -0800 (PST)
In-Reply-To: <CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<54C267A1.8090208@gmail.com>
<CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
<CAJna-HgL_-PTfmS-kA00DfZiZ8uPFqQTytihY6o8De5KVvDThw@mail.gmail.com>
<CAAS2fgSKBS9zCQqp+hJUF2Ro8LNw4s0=J08M=76sOJmNfpLptQ@mail.gmail.com>
<CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com>
Date: Fri, 23 Jan 2015 18:51:06 +0000
Message-ID: <CAAS2fgThuM90uy7fUKxTY_h==S6VwEnYE5m3NBPJZEUtVjAK0w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: slush <slush@centrum.cz>,
Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YEjK3-0004ki-UE
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 23 Jan 2015 18:51:13 -0000
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).
|
