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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z2Pv9-0003vT-9F
for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 20:14:51 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z2Pv7-0007zf-Fe for bitcoin-development@lists.sourceforge.net;
Tue, 09 Jun 2015 20:14:51 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t59KEfFE050338;
Tue, 9 Jun 2015 21:14:41 +0100 (BST)
Received: from muck (bas3-cooksville17-1176330008.dsl.bell.ca [70.29.95.24])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t59KEahj072965
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 9 Jun 2015 21:14:38 +0100 (BST)
Date: Tue, 9 Jun 2015 16:14:36 -0400
From: Peter Todd <pete@petertodd.org>
To: Kristov Atlas <kristovatlas.lists@gmail.com>
Message-ID: <20150609201436.GD28093@muck>
References: <CAGH37SK0k1YUvadetyHcBGjzW+OHNFRmRwqsUDeHBGejUacigQ@mail.gmail.com>
<44BE16F9-AB24-4A8E-BC7F-03A6C590FCE7@gmail.com>
<CAGH37SL3TA7BXd3Y+4F1Fd5N3ZW+LRLvkfppPsPn61ZVbZJOnQ@mail.gmail.com>
<CAGH37SLCc-aEG0t0H7fsUZOv_h+Fiw4xoonmfwNaFWBin_7HcQ@mail.gmail.com>
<20150607023523.GB1570@savin.petertodd.org>
<CAGH37SLyG-g54-gGU5ZrmQsiogOqWNW1iiayHii1nWiWh+Nk=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="GpGaEY17fSl8rd50"
Content-Disposition: inline
In-Reply-To: <CAGH37SLyG-g54-gGU5ZrmQsiogOqWNW1iiayHii1nWiWh+Nk=w@mail.gmail.com>
X-Server-Quench: 28688a9b-0ee4-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgsUEkAaAgsB AmMbWVVeUVl7Wmo7 bApPbwxDa09QXQF1
VUBOXVMcUABhemlQ XkQeVRt7cQAIenZx bU4sXHhdVEwrfBRg
QhsBEXAHZDJldWlJ V0RFdwNWdQpKLx5G bwR8GhFYa3VsFCMk
FAgyOXU9MCtSLCNN RwwLMWdaZUsbHzU7 SAoLBTUuFkQBDwQ1
IxE2K1gTVEEfenko OF06UFkEMhgUaEV/ GVlQHDQRLl8NDw02 ERtHQVV2
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 70.29.95.24/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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_PASS SPF: sender matches SPF record
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z2Pv7-0007zf-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: Tue, 09 Jun 2015 20:14:51 -0000
--GpGaEY17fSl8rd50
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
Two other things:
> On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> > protocols; you haven't taken into account the needs of those protocols.
> > For BIP's it's better to stick to the use-cases where the need is clear
> > and there exists running code that to speculate too much on future uses.
> > With signature hashing in particular it's not yet clear at all what
> > future OP_CHECKSIG's will look like, let alone the various ways people
> > will use sighash for smart contract type stuff.
> >
> > You'd be better off presenting the BIP in terms of a generic statement
> > that "except when otherwise prevented by advanced signature hashing
> > requirements, wallet software must emit transactions sorted according to
> > the following" You can then specify the two common cases in detail:
> >
> > 1) SIGHASH_ALL: input and output order signed, so sort appropriately
> >
> > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit
> > transactions sorted, recognising that the actual mined order may be
> > changed.
> >
>=20
> That makes sense. I updated the language as follows -- your thoughts? Keep
> in mind this BIP is informational, and so people are free to ignore it.
>=20
> "Applicability: This BIP applies to all transactions of signature hash ty=
pe
> SIGHASH_ALL. Additionally, software compliant with this BIP that allows
> later parties to update the transaction (e.g. using signature hash types
> SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
> lexicographically sorted inputs and outputs, although they may later be
> modified. Transactions that have index dependencies between transactions =
or
> within the same transaction are covered under the section of this BIP
> entitled =E2=80=9CHandling Input/Output Dependencies.=E2=80=9D"
I'd keep it even simpler than that, and just say for now that such
use-cases are out of the scope of this BIP, however those standards
should come up with some kind of deterministic standard that meets the
needs of the protocol. Again, there's a bunch of possible use-cases here
and we just can't predict them; focus on the fact that the *spirit* of
what this BIP is about is applicable and future standards should be
developed.
So I'd change the "Applicability" section to:
This BIP applies to all transactions where the order of inputs and
outputs does not matter. This is true for the vast majority of
transactions as they simply move funds from one place to another.
Currently this generally refers to transactions where SIGHASH_ALL is
used, in which case the signatures commit to the exact order of input
and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE
has been used (e.g. crowdfunds) the order of inputs and/or outputs may
not be signed, however compliant software should still emit transactions
with sorted inputs and outputs, even though they may later be modified
by others.
In the event that future protocol upgrades introduce new signature hash
types, compliant software should apply the lexographic ordering
principle analogously.
While out of scope of this BIP, protocols that do require a specified
order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should
consider the goals of this BIP and how best to adapt them to the
specifics needs of those protocols.
Then remove the "handling input/output deps" section.
> > Do you have a patch implementing deterministic tx ordering for Bitcoin
> > Core yet?
> >
>=20
> I'm not a frequent C programmer, so I'd prefer to let someone else take
> care of it, as a frequent committer of code would do a faster and more
> stylistically consistent job of it. If no one else will, however, I will.
re: the actual ordering algorithm, having txids be sorted by with the
hex-based algorithm is odd. I'd simply say they're sorted as
little-endian byte arrays, or in other words, with the bytearr_cmp()
function, but with the order of bytes reversed. You also should say that
we're doing that to make the user see them in visually sorted order to
match expectations because txids are displayed as little-endian.
For outputs, don't say "locking script", say "scriptPubKey". Secondly,
scriptPubKeys are not in little-endian representation - they have no
endianness to them. With output amount, there's no need to say that
they're unsigned or little-endian satoshies, just say they're sorted
largest/smallest amount first.
"For the sake of efficiency, amounts will be considered first for
sorting, since they contain fewer bytes of information (7 bytes)
compared to a standard P2PKH locking script (800 bytes)." <- where the
heck did you get these numbers from? Amounts are 8 bytes, and P2PKH
scriptPubKeys are 25 bytes.
"Backwards Compatibility" <- I'd just remove this whole section; we're
unlikely to make this an IsStandard() rule anytime soon.
--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
--GpGaEY17fSl8rd50
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVd0kpXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyLeAf/enae2UIoQSANKPtvVBqJLiZB
hGQmjaDTfjDEcq0Gae+xqtOc7wUAGWejUzTo5nVy8VcmcbsbQ370Hjgz5BxfgYit
H1X4BQvxULBpsSoa6TeMairyRNf17fKdm106QeXDZBrAa9tE7y+XKfsfeQMaOu9L
MJ/eSxTZuC6+qpnSolperUN86vog+MR5026iT/hn3grP9xWnqkVu22zizKub9SLc
lL3+pk6qf2HfcS0NR7rAS9/Ukr9SkIWYKQLXF1OvzRbyseBnsWPpYijT4/hRCyIA
XjV3s/c1/ZfqSfGUUw7YltW/U+Eed+9TATzGhf0MqoPJSXBcopJJgztRePjLgA==
=lQ+z
-----END PGP SIGNATURE-----
--GpGaEY17fSl8rd50--
|
