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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
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 <marek@palatinus.cz>) id 1YEiEe-0007qM-9a
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 17:41:32 +0000
X-ACL-Warn:
Received: from mail-ig0-f173.google.com ([209.85.213.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEiEb-0004Fr-ER
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 17:41:30 +0000
Received: by mail-ig0-f173.google.com with SMTP id a13so3136425igq.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 09:41:25 -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=rTI+uxT1F4CNS+iVAc7xiz5nxsPuqZgLGwBwcKvkQHU=;
b=fuq7OGQIZ1iQOe1Mfxg28YDsnpd2R8QOCCTwacnmPqjrSNqXxwHoHnUOVybUSs/WzN
bQ8kv94MXo2TO/uLv5YHFyQuJmxo3hCIiUyM2THAgqZ0g39wvcrwW0kAETbcoqa8Ta9C
yLO64UuyFuql6U8g2iQWOjWSA7J3/jWnCtdzF0Rzzlf8MWKgR5c9BJRCnKAF5SaNPQ9c
qgteSHHpWW8EwZIXqr3WxGMzt7h73t2b/CHnJs+pthVs78tPXXxOIjqEiwb/xyHDWX9c
WrTOO2sf6fbcPV6E01Lwf8tlc7Y1s9dcPaVzQ8S/D4kVA6jWA/u/zamclCKb1AfUEmfc
Dv7A==
X-Gm-Message-State: ALoCoQl5wCMdAIFTzWjJp+p7WqL5slSc8XhfIF1XPuBpJ7kd4zi4r0ytIEl3krXksGFBkKvaXo0J
X-Received: by 10.50.83.10 with SMTP id m10mr3147386igy.23.1422034884929; Fri,
23 Jan 2015 09:41:24 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 09:40:54 -0800 (PST)
In-Reply-To: <CAAS2fgSKBS9zCQqp+hJUF2Ro8LNw4s0=J08M=76sOJmNfpLptQ@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>
From: slush <slush@centrum.cz>
Date: Fri, 23 Jan 2015 18:40:54 +0100
X-Google-Sender-Auth: 3fa-xArn-8B-a5X6IbhZKf-3taI
Message-ID: <CAJna-Hi1PaJ-Xxr+quubtOVrhv-KPxkbC=jhNU5cm43GOnb67A@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122acca2ce45a050d554c6b
X-Spam-Score: 1.4 (+)
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.4 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YEiEb-0004Fr-ER
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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 17:41:32 -0000
--089e0122acca2ce45a050d554c6b
Content-Type: text/plain; charset=ISO-8859-1
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?
>
--089e0122acca2ce45a050d554c6b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, the step you're missing is "and build the ta=
ble". Dynamic memory allocation is something you want to avoid, as wel=
l as any artifical restrictions to number of inputs or outputs. Current sol=
ution is slow, but there's really no limitation on tx size.<div><br></d=
iv><div>Plus there're significant restrictions to memory in embedded wo=
rld. Actually TREZOR uses pretty powerful (and expensive) MCU just because =
it needs to do such validations and calculate such hashes. With SIGHASH_WIT=
HINPUTVALUE or similar we may cut hardware cost significantly.<br></div><di=
v><br></div><div>Marek</div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell <span dir=
=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwe=
ll@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'=
m not sure where the ^2 is coming from.=A0 So what I'd understand that<=
br>
you'd do is stream in the input txid:vouts which you spend, then you=
9;d<br>
stream the actual inputs which would just be hashed and value<br>
extracted (but no other verification), and you'd build a table of<br>
txid:vout->value, then the actual transaction to be signed.<br>
<br>
This should have O(inputs) hashing and communications overhead. Is<br>
there a step I'm missing?<br>
</blockquote></div><br></div></div></div>
--089e0122acca2ce45a050d554c6b--
|
