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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kristovatlas.lists@gmail.com>) id 1Z4Lah-00072x-WA
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 04:01:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.179 as permitted sender)
client-ip=209.85.217.179;
envelope-from=kristovatlas.lists@gmail.com;
helo=mail-lb0-f179.google.com;
Received: from mail-lb0-f179.google.com ([209.85.217.179])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4Lag-0006m5-My
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 04:01:43 +0000
Received: by lblr1 with SMTP id r1so19183843lbl.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 14 Jun 2015 21:01:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.122.43 with SMTP id lp11mr5504332lbb.9.1434340896312;
Sun, 14 Jun 2015 21:01:36 -0700 (PDT)
Received: by 10.152.163.98 with HTTP; Sun, 14 Jun 2015 21:01:36 -0700 (PDT)
In-Reply-To: <CAAS2fgRgWZX_O_2O1bgdFd_04xVp5Lnpw4hf=v6RSTXmsbdzPQ@mail.gmail.com>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
<CAAS2fgRgWZX_O_2O1bgdFd_04xVp5Lnpw4hf=v6RSTXmsbdzPQ@mail.gmail.com>
Date: Mon, 15 Jun 2015 00:01:36 -0400
Message-ID: <CAGH37S+674cAVC7=WvST_SPkXjfNkzbj7Y_me_M6C+ieHX6EAA@mail.gmail.com>
From: Kristov Atlas <kristovatlas.lists@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bf0c7e29c94310518868368
X-Spam-Score: -0.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
(kristovatlas.lists[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Z4Lag-0006m5-My
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering
in transactions
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: Mon, 15 Jun 2015 04:01:44 -0000
--047d7bf0c7e29c94310518868368
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 14, 2015 at 7:02 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> I'm not a great fan of this proposal for two reasons: The first is
> that the strict ordering requirements is incompatible with future
> soft-forks that may expose additional ordering constraints. Today we
> have _SINGLE, which as noted this interacts with poorly, but there
> have been other constraints proposed that this would also interact
> with poorly.
>
I'm not clear on why this is a problem, so long as the canonical ordering
BIP is *optional*. Unless there is a specific plan to soft fork a change
that would break the BIP and it is fairly imminent, I see this only as a
reason not to integrate it into isStandard().
> The second is that even absent consensus rules there may be invisible
> constraints in systems-- e.g. hardware wallets that sign top down, or
> future transaction covenants that have constraints about ordering, or
> proof systems that use (yuck) midstate compression for efficiency. Right
> now, with random ordering these applications are fairly
> indistinguishable from other random uses (since their imposed order
> could come about by chance) but if everyone else was ordered, even if
> wasn't enforced.. these would be highly distinguishable. Which would
> be unfortunate.
Maybe they shouldn't be doing that. :-P
> I think perhaps the motivations here are understated. We have not seen
> any massive deployments of accidentally broken ordering that I'm aware
> of-- and an implementation that got this wrong in a harmful way would
> likely make far more fatal mistakes (e.g. non random private keys).
>
In my reading of various wallet client sources, it is common that wallet
clients will use cryptographically weak sources of randomness to sort
outputs -- that is, the ones that actually bother to randomly sort. I can
hunt down some examples if this would substantially contribute to the
discussion.
As an alternative to this proposal the ordering can be privately
> derandomized in the same way DSA is, to avoid the need for an actual
> number source. If getting the randomness right were really the only
> motivation, I'd suggest we propose a simple derandomized randomization
> algorithm--- e.g. take the order from (H(input ids||client secret)).
>
This sounds similar to an idea that Sergio pitched to me privately, which
was for wallets to have a private sorting key that they can use to sort
inputs and outputs. However, I suspect that adding yet another key which
will necessarily require special key rotation rules and maybe special
backup procedures will mean that this standard will not be widely adopted
any time soon. Ideally, I'd like to see someone write a different BIP with
the sorting key idea and let them compete in the wallet client market
rather than trying to anticipate what is best for all clients and
distilling two good ideas into one artificially.
-Kristov
--047d7bf0c7e29c94310518868368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jun 14, 2015 at 7:02 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:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not a great fan of this proposal for two reasons: The first is<br>
that the strict ordering requirements is incompatible with future<br>
soft-forks that may expose additional ordering constraints. Today we<br>
have _SINGLE, which as noted this interacts with poorly, but there<br>
have been other constraints proposed that this would also interact<br>
with poorly.<br></blockquote><div><br></div><div>I'm not clear on why t=
his is a problem, so long as the canonical ordering BIP is *optional*. Unle=
ss there is a specific plan to soft fork a change that would break the BIP =
and it is fairly imminent, I see this only as a reason not to integrate it =
into isStandard().<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
The second is that even absent consensus rules there may be invisible<br>
constraints in systems-- e.g. hardware wallets that sign top down, or<br>
future transaction covenants that have constraints about ordering,=C2=A0 or=
<br>
proof systems that use (yuck) midstate compression for efficiency. Right no=
w, with random ordering these applications are fairly<br>
indistinguishable from other random uses (since their imposed order<br>
could come about by chance) but if everyone else was ordered, even if<br>
wasn't enforced.. these would be highly distinguishable. Which would<br=
>
be unfortunate.</blockquote><div><br></div><div>Maybe they shouldn't be=
doing that. :-P<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
I think perhaps the motivations here are understated. We have not seen<br>
any massive deployments of accidentally broken ordering that I'm aware<=
br>
of-- and an implementation that got this wrong in a harmful way would<br>
likely make far more fatal mistakes (e.g. non random private keys).<br></bl=
ockquote><div><br></div><div>In my reading of various wallet client sources=
, it is common that wallet clients will use cryptographically weak sources =
of randomness to sort outputs -- that is, the ones that actually bother to =
randomly sort. I can hunt down some examples if this would substantially co=
ntribute to the discussion.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
As an alternative to this proposal the ordering can be privately<br>
derandomized in the same way DSA is, to avoid the need for an actual<br>
number source.=C2=A0 If getting the randomness right were really the only<b=
r>
motivation, I'd suggest we propose a simple derandomized randomization<=
br>
algorithm--- e.g. take the order from (H(input ids||client secret)).<br></b=
lockquote><div><br></div><div>This sounds similar to an idea that Sergio pi=
tched to me privately, which was for wallets to have a private sorting key =
that they can use to sort inputs and outputs. However, I suspect that addin=
g yet another key which will necessarily require special key rotation rules=
and maybe special backup procedures will mean that this standard will not =
be widely adopted any time soon. Ideally, I'd like to see someone write=
a different BIP with the sorting key idea and let them compete in the wall=
et client market rather than trying to anticipate what is best for all clie=
nts and distilling two good ideas into one artificially.<br><br></div><div>=
-Kristov<br></div></div><br></div></div>
--047d7bf0c7e29c94310518868368--
|
