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
|
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 <rusty@ozlabs.org>) id 1Z15wB-0002oU-Rh
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 04:42:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of ozlabs.org
designates 103.22.144.67 as permitted sender)
client-ip=103.22.144.67; envelope-from=rusty@ozlabs.org;
helo=ozlabs.org;
Received: from ozlabs.org ([103.22.144.67])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z15wA-0004Pc-0N
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 04:42:27 +0000
Received: by ozlabs.org (Postfix, from userid 1011)
id 9257214027F; Sat, 6 Jun 2015 14:42:18 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
(x86_64-pc-linux-gnu)
Date: Sat, 06 Jun 2015 14:12:10 +0930
Message-ID: <87k2vhfnx9.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.8 (/)
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 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.8 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z15wA-0004Pc-0N
Subject: [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:42:27 -0000
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
|
