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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1Z1604-00018Y-7e
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 04:46:28 +0000
X-ACL-Warn:
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z15zz-00026c-LI
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 04:46:28 +0000
Received: by iebmu5 with SMTP id mu5so35088300ieb.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 05 Jun 2015 21:46:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=FXnM1gFVrGfUh3/u7exlMvWfbvWxC8PZ5vuKE4x6hYM=;
b=OpM4vXp/TTiSyt+k94qlW6BPzEOCIjajD5USboGDIAUSd1m3ib2eSjHW3q43DKFa0V
mIJeeFuyvc2toeDWJ1+Ftl70cwvZTaHtX7O5l5Q2Fs5+keJGEVNQpHAVn+ZUe5Hn9fvl
q1PnGokOPlieH71LOnvOwVJSSo08RXoi13U1NZUOp5z+Rx9axgYN27wWUs4alCddC6+9
NYbcjO9IpPcIBFLVnM8uY8WA3LTUok3LNc2vZkNJJ+ZLhRGQtjztIIBmPw2M8ATRl6Oa
B+e3fUMwn+E6VZ9Ef5W/cBqxjxIgcYk/nLXnscd/f4QQeZ5NRxlFrxfdauC3FZEAu7f7
ka8g==
X-Gm-Message-State: ALoCoQluttPp5e1+6dj5Asui+CznTLuiv5VaghAYZl0A48AvXvNgbuCdQPUldST4iWkz6b3Vj3Nz
MIME-Version: 1.0
X-Received: by 10.42.176.8 with SMTP id bc8mr13778268icb.22.1433565978088;
Fri, 05 Jun 2015 21:46:18 -0700 (PDT)
Received: by 10.107.10.197 with HTTP; Fri, 5 Jun 2015 21:46:17 -0700 (PDT)
X-Originating-IP: [172.56.17.6]
Received: by 10.107.10.197 with HTTP; Fri, 5 Jun 2015 21:46:17 -0700 (PDT)
In-Reply-To: <87k2vhfnx9.fsf@rustcorp.com.au>
References: <87k2vhfnx9.fsf@rustcorp.com.au>
Date: Fri, 5 Jun 2015 21:46:17 -0700
Message-ID: <CAOG=w-sfpgciy9AzmtjEU5-uZY5KCAuS-SGsbff81w1dGVyBPg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary=90e6ba6e8642e2ede90517d216a6
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z15zz-00026c-LI
Cc: Bitcoin Development <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: Sat, 06 Jun 2015 04:46:28 -0000
--90e6ba6e8642e2ede90517d216a6
Content-Type: text/plain; charset=UTF-8
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 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
>
--90e6ba6e8642e2ede90517d216a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Rusty, this doesn't play well with SIGHASH_SINGLE which =
is used in assurance contracts among other things. Sometimes the ordering i=
s set by the signing logic itself...</p>
<div class=3D"gmail_quote">On Jun 5, 2015 9:43 PM, "Rusty Russell"=
; <<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>>=
; wrote:<br type=3D"attribution"><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>
--90e6ba6e8642e2ede90517d216a6--
|
