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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <danny.thorpe@gmail.com>) id 1Z24YF-0001OG-60
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 21:25:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.48 as permitted sender)
client-ip=209.85.220.48; envelope-from=danny.thorpe@gmail.com;
helo=mail-pa0-f48.google.com;
Received: from mail-pa0-f48.google.com ([209.85.220.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z24YD-0002cV-RE
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 21:25:47 +0000
Received: by padev16 with SMTP id ev16so48065445pad.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 08 Jun 2015 14:25:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.66.90.166 with SMTP id bx6mr32847715pab.76.1433798740128;
Mon, 08 Jun 2015 14:25:40 -0700 (PDT)
Received: by 10.70.13.133 with HTTP; Mon, 8 Jun 2015 14:25:40 -0700 (PDT)
In-Reply-To: <87k2vhfnx9.fsf@rustcorp.com.au>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
Date: Mon, 8 Jun 2015 14:25:40 -0700
Message-ID: <CAJN5wHVSK-oW+zVZmEMfyFkd+GUHRhFHEjEmKrdvqas3LzY0zw@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=001a113838a895ba6705180848f4
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
(danny.thorpe[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: 1Z24YD-0002cV-RE
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, 08 Jun 2015 21:25:47 -0000
--001a113838a895ba6705180848f4
Content-Type: text/plain; charset=UTF-8
FWIW, The Open Assets colored coin protocol (CoinPrism) places special
significance on the zeroth input and the position of the OP_RETURN colored
coin marker output to distinguish colored coin issuance outputs from
transfer outputs. Reordering the inputs or the outputs breaks the colored
coin representation.
Recommending sorting of the inputs and outputs as a best practice is fine
(and better than random, IMO), but not as part of IsStandard() or consensus
rules. There are cases where the order of the inputs and outputs is
significant.
-Danny
On Fri, Jun 5, 2015 at 9:42 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell <rusty@rustcorp.com.au>
> Discussions-To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs when
> creating transactions.
>
> Motivation
>
> Most bitcoin wallet implementations randomize the outputs of
> transactions they create to avoid trivial linkage analysis (especially
> change outputs), however implementations have made mistakes in this area
> in the past.
>
> Using a canonical ordering has the same effect, but is simpler, more
> obvious if incorrect, and can eventually be enforced by IsStandard() and
> even a soft-fork to enforce it.
>
> Specification
>
> Inputs should be ordered like so:
> index (lower value first)
> txid (little endian order, lower byte first)
>
> Outputs should be ordered like so:
> amount (lower value first)
> script (starting from first byte, lower byte first, shorter wins)
>
> Rationale
>
> Any single wallet is already free to implement this, but if other
> wallets do not it would reduce privacy by making those transactions
> stand out. Thus a BIP is appropriate, especially if this were to
> become an IsStandard() rule once widely adopted.
>
> Because integers are fast to compare, they're sorted first, before the
> lexographical ordering.
>
> The other input fields do not influence the sort order, as any valid
> transactions cannot have two inputs with the same index and txid.
>
> Reference Implementation
>
> https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a113838a895ba6705180848f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">FWIW, The Open Assets colored coin protocol (CoinPrism) pl=
aces special significance on the zeroth input and the position of the OP_RE=
TURN colored coin marker output to distinguish colored coin issuance output=
s from transfer outputs. Reordering the inputs or the outputs breaks the co=
lored coin representation.<div><br></div><div>Recommending sorting of the i=
nputs and outputs as a best practice is fine (and better than random, IMO),=
but not as part of IsStandard() or consensus rules.=C2=A0 There are cases =
where the order of the inputs and outputs is significant.</div><div><br></d=
iv><div>-Danny</div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Fri, Jun 5, 2015 at 9:42 PM, Rusty Russell <span dir=3D"ltr">&l=
t;<a href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp=
.com.au</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Title: Cano=
nical Input and Output Ordering<br>
Author: Rusty Russell <<a href=3D"mailto:rusty@rustcorp.com.au">rusty@ru=
stcorp.com.au</a>><br>
Discussions-To: "Bitcoin Dev" <<a href=3D"mailto:bitcoin-devel=
opment@lists.sourceforge.net">bitcoin-development@lists.sourceforge.net</a>=
><br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2015-06-06<br>
<br>
Abstract<br>
<br>
This BIP provides a canonical ordering of inputs and outputs when<br>
creating transactions.<br>
<br>
Motivation<br>
<br>
Most bitcoin wallet implementations randomize the outputs of<br>
transactions they create to avoid trivial linkage analysis (especially<br>
change outputs), however implementations have made mistakes in this area<br=
>
in the past.<br>
<br>
Using a canonical ordering has the same effect, but is simpler, more<br>
obvious if incorrect, and can eventually be enforced by IsStandard() and<br=
>
even a soft-fork to enforce it.<br>
<br>
Specification<br>
<br>
Inputs should be ordered like so:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 index (lower value first)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txid (little endian order, lower byte first)<br=
>
<br>
Outputs should be ordered like so:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 amount (lower value first)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 script (starting from first byte, lower byte fi=
rst, shorter wins)<br>
<br>
Rationale<br>
<br>
Any single wallet is already free to implement this, but if other<br>
wallets do not it would reduce privacy by making those transactions<br>
stand out.=C2=A0 Thus a BIP is appropriate, especially if this were to<br>
become an IsStandard() rule once widely adopted.<br>
<br>
Because integers are fast to compare, they're sorted first, before the<=
br>
lexographical ordering.<br>
<br>
The other input fields do not influence the sort order, as any valid<br>
transactions cannot have two inputs with the same index and txid.<br>
<br>
Reference Implementation<br>
<br>
<a href=3D"https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering=
" target=3D"_blank">https://github.com/rustyrussell/bitcoin/tree/bip-in-out=
-ordering</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>
--001a113838a895ba6705180848f4--
|
