summaryrefslogtreecommitdiff
path: root/5d/f03b894b10f5f1ed0cab35c99baff907da14c1
blob: 91e924fffeb802428658b3a3f4da39f97ad75b89 (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephencalebmorse@gmail.com>) id 1Z14fA-0007MW-JD
	for bitcoin-development@lists.sourceforge.net;
	Sat, 06 Jun 2015 03:20:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.51 as permitted sender)
	client-ip=209.85.216.51;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-vn0-f51.google.com; 
Received: from mail-vn0-f51.google.com ([209.85.216.51])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z14f9-0003nE-Fe
	for bitcoin-development@lists.sourceforge.net;
	Sat, 06 Jun 2015 03:20:48 +0000
Received: by vnbg7 with SMTP id g7so5308932vnb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 05 Jun 2015 20:20:42 -0700 (PDT)
X-Received: by 10.52.174.48 with SMTP id bp16mr11675833vdc.35.1433560841993;
	Fri, 05 Jun 2015 20:20:41 -0700 (PDT)
Received: from [192.168.0.2] (cpe-76-179-51-147.maine.res.rr.com.
	[76.179.51.147])
	by mx.google.com with ESMTPSA id qj9sm10463943vdb.9.2015.06.05.20.20.41
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 05 Jun 2015 20:20:41 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-C514C442-008D-4833-9E35-01E9235278EC
Mime-Version: 1.0 (1.0)
From: Stephen <stephencalebmorse@gmail.com>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <CAGH37SK0k1YUvadetyHcBGjzW+OHNFRmRwqsUDeHBGejUacigQ@mail.gmail.com>
Date: Fri, 5 Jun 2015 23:20:38 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <44BE16F9-AB24-4A8E-BC7F-03A6C590FCE7@gmail.com>
References: <CAGH37SK0k1YUvadetyHcBGjzW+OHNFRmRwqsUDeHBGejUacigQ@mail.gmail.com>
To: Kristov Atlas <kristovatlas.lists@gmail.com>
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
	(stephencalebmorse[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
	-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: 1Z14f9-0003nE-Fe
Cc: Bitcoin development mailing list
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Lexicographical Indexing of Transaction
	Inputs and Outputs
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 03:20:48 -0000


--Apple-Mail-C514C442-008D-4833-9E35-01E9235278EC
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Kristov,

I like the idea. Mainly because having a standard reminds developers to cons=
ider this issue. In addition, we would have visibility into the portion of t=
he network that adopts this strategy to enhance privacy. A few points of fee=
dback:

 - I think your explanation of sorting could be significantly shortened and c=
larified by simply saying that the TXIDs of inputs should be compared as uin=
t256 integers.=20
 - The malleability of input TXIDs, as mentioned in the proposal, could caus=
e inputs to be ordered in a non-standard way. Reordering then them would inv=
alidate the signatures (assuming SIGHASH_ALL), so the transaction would be l=
eft with improperly ordered inputs. While not a huge issue, it's not ideal. I=
 think the best way to get around this would be to use normalized TXIDs, but=
 you might also be able to sort based on the previous outputs that each of t=
he inputs are spending? These both require information that may not be readi=
ly available, however, and use of normalized transaction IDs is not fully de=
veloped yet.=20

Best,
Stephen=20



> On Jun 5, 2015, at 8:12 PM, Kristov Atlas <kristovatlas.lists@gmail.com> w=
rote:
>=20
> Hello all,
>=20
> I have written a draft of a BIP to standardize the sorting of tx inputs an=
d outputs for privacy and security reasons. A few colleagues have reviewed t=
his and provided feedback privately, but now it's ready for feedback from a w=
ider audience.
>=20
> If there is positive sentiment about the proposal after feedback is integr=
ated, I aim for a bip number to be assigned and have it accepted into https:=
//github.com/bitcoin/bips=20
>=20
> Link: https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediaw=
iki
>=20
> For your convenience, here's the abstract:
>=20
> "Currently there is no standard for bitcoin wallet clients when ordering t=
ransaction inputs and outputs. As a result, wallet clients often have a disc=
ernible blockchain fingerprint, and can leak private information about their=
 users. By contrast, a standard for non-deterministic sorting could be diffi=
cult to audit. This document proposes deterministic lexicographical sorting,=
 using hashes of previous transactions and output indices to sort transactio=
n inputs, as well as value and locking scripts to sort transaction outputs."=

>=20
> Thanks,
>=20
> Kristov Atlas
> Open Bitcoin Privacy Project Contributor, Blockchain.info Security Enginee=
r, etc.
> Twitter: @kristovatlas
> Blog: kristovatlas.com
> --------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--Apple-Mail-C514C442-008D-4833-9E35-01E9235278EC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Hi Kristov,</div><div><br></div><div>I=
 like the idea. Mainly because having a standard reminds developers to consi=
der this issue. In addition, we would have visibility into the portion of th=
e network that adopts this strategy to enhance privacy. A few points of feed=
back:</div><div><br></div><div>&nbsp;- I think your explanation of sorting c=
ould be significantly shortened and clarified by simply saying that the TXID=
s of inputs should be compared as uint256 integers.&nbsp;</div><div>&nbsp;- T=
he malleability of input TXIDs, as mentioned in the proposal, could cause in=
puts to be ordered in a non-standard way. Reordering then them would invalid=
ate the signatures (assuming SIGHASH_ALL), so the transaction would be left w=
ith improperly ordered inputs. While not a huge issue, it's not ideal. I thi=
nk the best way to get around this would be to use normalized TXIDs, but you=
 might also be able to sort based on the previous outputs that each of the i=
nputs are spending? These both require information that may not be readily a=
vailable, however, and use of normalized transaction IDs is not fully develo=
ped yet.&nbsp;</div><div><br></div><div>Best,</div><div>Stephen&nbsp;</div><=
div><br><br></div><div><br>On Jun 5, 2015, at 8:12 PM, Kristov Atlas &lt;<a h=
ref=3D"mailto:kristovatlas.lists@gmail.com">kristovatlas.lists@gmail.com</a>=
&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><di=
v><div><div><div><div><div><div><div>Hello all,<br><br></div>I have written a=
 draft of a BIP to standardize the sorting of tx inputs and outputs for priv=
acy and security reasons. A few colleagues have reviewed this and provided f=
eedback privately, but now it's ready for feedback from a wider audience.<br=
><br></div>If there is positive sentiment about the proposal after feedback i=
s integrated, I aim for a bip number to be assigned and have it accepted int=
o <a href=3D"https://github.com/bitcoin/bips">https://github.com/bitcoin/bip=
s</a> <br><br>Link: <a href=3D"https://github.com/kristovatlas/rfc/blob/mast=
er/bips/bip-li01.mediawiki">https://github.com/kristovatlas/rfc/blob/master/=
bips/bip-li01.mediawiki</a><br><br></div>For your convenience, here's the ab=
stract:<br><br>"Currently there is no standard for bitcoin wallet clients wh=
en ordering transaction inputs and outputs. As a result, wallet clients ofte=
n have a discernible blockchain fingerprint, and can leak private informatio=
n about their users. By contrast, a standard for non-deterministic sorting c=
ould be difficult to audit. This document proposes deterministic lexicograph=
ical sorting, using hashes of previous transactions and output indices to so=
rt transaction inputs, as well as value and locking scripts to sort transact=
ion outputs."<br><br></div>Thanks,<br><br></div>Kristov Atlas<br></div>Open B=
itcoin Privacy Project Contributor, Blockchain.info Security Engineer, etc.<=
br></div>Twitter: @kristovatlas<br></div>Blog: <a href=3D"http://kristovatla=
s.com">kristovatlas.com</a><br></div>
</div></blockquote><blockquote type=3D"cite"><div><span>--------------------=
----------------------------------------------------------</span><br></div><=
/blockquote><blockquote type=3D"cite"><div><span>___________________________=
____________________</span><br><span>Bitcoin-development mailing list</span>=
<br><span><a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitco=
in-development@lists.sourceforge.net</a></span><br><span><a href=3D"https://=
lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development</a></span><br></div></blockqu=
ote></body></html>=

--Apple-Mail-C514C442-008D-4833-9E35-01E9235278EC--