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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z1QQy-00036Y-Ql
for bitcoin-development@lists.sourceforge.net;
Sun, 07 Jun 2015 02:35:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.108 as permitted sender)
client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
helo=outmail148108.authsmtp.net;
Received: from outmail148108.authsmtp.net ([62.13.148.108])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z1QQx-00008g-2L for bitcoin-development@lists.sourceforge.net;
Sun, 07 Jun 2015 02:35:36 +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 t572ZSLj023588;
Sun, 7 Jun 2015 03:35:28 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t572ZNsI046322
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 7 Jun 2015 03:35:26 +0100 (BST)
Date: Sat, 6 Jun 2015 22:35:23 -0400
From: Peter Todd <pete@petertodd.org>
To: Kristov Atlas <kristovatlas.lists@gmail.com>
Message-ID: <20150607023523.GB1570@savin.petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK"
Content-Disposition: inline
In-Reply-To: <CAGH37SLCc-aEG0t0H7fsUZOv_h+Fiw4xoonmfwNaFWBin_7HcQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: db0171c6-0cbd-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgUUEkAaAgsB AmMbW1deU1h7W2U7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRkG BHRgEWBycwNFenw+ Z0drXnQVCBZ6dEF8
EUhJFT5UMXphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOjMs RhsFEi8mBU0ETCw3
Zz0gJlMMHUAeekI8 eWc7UFQDOhQOCwpY fQlsBjdEO0JJTiwn RSRHQVYDDCY1
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/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
X-Headers-End: 1Z1QQx-00008g-2L
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: Sun, 07 Jun 2015 02:35:36 -0000
--/NkBOFFp2J2Af1nK
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 06, 2015 at 08:06:56PM -0400, Kristov Atlas wrote:
In general I think this is a good idea, and should be implemented; we've
had a depressing number of wallets fail to implement randomization
properly, if at all.
> I've updated the draft BIP in two ways:
> -Making it clear that sorting is algorithmically agnostic, but should
> conform to the output of the example algorithms written in python
> -The BIP now handles schemes that create an input/output dependency, such
> as SIGHASH_SINGLE:
>=20
> Handling Input/Output Dependencies
>=20
> Some uncommon forms of transactions create an ordering dependency between
> inputs and outputs of a transaction. Wallets forming these transactions
> should first sort inputs according to the methodology outlined in section
> =E2=80=9CTransaction Inputs=E2=80=9D of this BIP. Then, they should fix t=
he output indices
> that depend on the input order, and sort the remaining outputs around the=
m.
> If there are no outputs that do not depend on input order, then all outpu=
ts
> will simply be ordered based on the expected scheme. The following are the
> known cases of input/output dependency that must be handled specially:
>=20
> * SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI01 compliance
> for a transaction must inspect the last byte of the scriptSig of each inp=
ut
> to determine the signature hash type. In the case of SIGHASH_SINGLE (0x03)
> for input =E2=80=9Cn=E2=80=9D, the verifier should expect that output =E2=
=80=9Cn=E2=80=9D will be fixed
> when considering output ordering.
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.
As for IsStandard() rules - let alone soft forks - better to leave
discussion of them out for now. In particular, for the soft-fork case
mandating certain transaction orders will very likely cause problems in
the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it
might be appropriate for nodes to enforce a certain ordering, but that
can be a separate BIP. (actually implementing that in Bitcoin Core would
be annoying and ugly right now; without replace-by-fee ANYONECANPAY has
a silly DoS attack (adding low-fee inputs) so I can't recommend wallets
use it in the general case yet)
"and a sequence number currently set to 0xFFFFFFFF." <- Actually, this
will be changed in Bitcoin Core as of v0.11.0, which implements
anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP
describing it)
Do you have a patch implementing deterministic tx ordering for Bitcoin
Core yet?
1) https://github.com/bitcoin/bitcoin/pull/2340
--=20
'peter'[:-1]@petertodd.org
0000000000000000079693d8d175b476081a04af9c1d00ea2dbe0efb011bd79e
--/NkBOFFp2J2Af1nK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVc63lXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOWJiMjc0NTJhMGM5ZmQ2YWYzYmNhZDJlMjA0MjJlNjA3
MDUxMTI4NDg2MDcwMjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsStggAqZLEovRLRcQ2UUL+lWDQYT51
5hDt5HAgL/oUaPjjwomevmsBq69MCqyparHM8Qp2ZYjBa4UpM6K46wW+KXqqPW6q
SyQ7XMc5moiTPe9tGKMhWZiL3Q07oKb5hzoM8Cf3X1unimQTdA5ZulY3WmpcsLMu
n1rkg6IwFhBEC9KxErGzlHUGgJjbQUcNEVXsqyTjBIesvemF/3Pw5+ZzyyXieRJb
Gj4YkazkjfyhCvx1ScC4HFnEFUff+b8wjDuNeBoHdL2OUYZAX6R6ef2njlGeOvKH
KthREehR7EzafXKPqRdPzaiE1EpF4WSicwPPGaTcSbkMUVVNns3V9C2AhebEmg==
=sEyk
-----END PGP SIGNATURE-----
--/NkBOFFp2J2Af1nK--
|
