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
127
|
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 1YEgwy-0003NB-7K
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:19:12 +0000
X-ACL-Warn:
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEgww-0000tO-FW
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:19:12 +0000
Received: by mail-ie0-f173.google.com with SMTP id tr6so7945100ieb.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 08:19:04 -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=6I8Lnnf5IVkuC31QTmUopnAyh5YSdQbzYFw6+IaI3iQ=;
b=jTJLX4R7OPTtkgF3kexMjIhybHkJIrVbLQen8Y8He9gI6JPgxgqhnlGp5f9Mp7G1xt
Or4GpLYHaMQ0YQ9/xT0f7gPqvN8L719dNOvqe6w9mAhgEOzeBPr8o3cid0+8t4/0Z60x
+GDHC+bWITjZve9q3lHA3XA8J+jsA8uDzzfiMW/SCTokH0YMw9Slsha9hj2ymNwIaAAL
31e19UduuoJ5LOPvp7ByF0XUr1at+67oKTbj4xYXf3JRDWq7BoXjd+t5soUOHQOWqh6p
rEmnfGYiL4K8yGu93r+yYPjxRz2qiTFyGHlECDQKTjvp9p1b9privFYpoDdFP6PkDQs4
8gGw==
X-Gm-Message-State: ALoCoQnFCFUC60XSW+YRCf75CFm9jlpmErn+JmXENR7Q+5esUPQXJsRBM4mSHP3rZGduvfrk/IPM
X-Received: by 10.107.150.6 with SMTP id y6mr4508140iod.22.1422029944775; Fri,
23 Jan 2015 08:19:04 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 08:18:34 -0800 (PST)
In-Reply-To: <CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<54C267A1.8090208@gmail.com>
<CAAS2fgQSAj=YHhtvy=MY9GvbEZNxtLUwzfrdPnSQBUKZYdj4oA@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 23 Jan 2015 17:18:34 +0100
X-Google-Sender-Auth: WWYJlbqudk-Yt0t94x-o6KHFqNw
Message-ID: <CAJna-HgL_-PTfmS-kA00DfZiZ8uPFqQTytihY6o8De5KVvDThw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140bf9ab80ba7050d542568
X-Spam-Score: 1.7 (+)
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.7 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YEgww-0000tO-FW
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 16:19:12 -0000
--001a1140bf9ab80ba7050d542568
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new signature type...
Can you send me any reference about this? Of course if that solves the
problem, hard fork would not be necessary anymore. I'm just not aware of
any.
Can you help me understand whats taking 40 minutes here? Thats a
> surprisingly high number, and so I'm wondering if I'm not missing
> something there.
>
>
To sign transaction with hundreds of inputs on device with limited memory
capabilities, I need to stream all previous transactions into device, for
every signed input.
That means roughly 200^2 transaction verifications for 200 inputs to sign.
Very slow, but does not limit the device for any particular size of signed
transaction.
Marek
--001a1140bf9ab80ba7050d542568
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell <span dir=3D"ltr"><=
<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is unr=
easonable. There is a straight-forward soft-fork<br>
approach which is safe (e.g. no risk of invalidating existing<br>
transactions). Yes, it means that you need to use newly created<br>
addresses to get coins that use the new signature type...</blockquote><div>=
<br></div><div>Can you send me any reference about this? Of course if that =
solves the problem, hard fork would not be necessary anymore. I'm just =
not aware of any.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can yo=
u help me understand whats taking 40 minutes here? Thats a<br>
surprisingly high number, and so I'm wondering if I'm not missing<b=
r>
something there.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>To sign transaction with hundreds of inputs on device with li=
mited memory capabilities, I need to stream all previous transactions into =
device, for every signed input.</div><div><br></div><div>That means roughly=
200^2 transaction verifications for 200 inputs to sign. Very slow, but doe=
s not limit the device for any particular size of signed transaction.</div>=
<div><br></div><div>Marek</div></div></div></div>
--001a1140bf9ab80ba7050d542568--
|
