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
217
218
219
220
221
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kristovatlas.lists@gmail.com>) id 1Z25ve-0000eo-Tf
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:54:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.182 as permitted sender)
client-ip=209.85.217.182;
envelope-from=kristovatlas.lists@gmail.com;
helo=mail-lb0-f182.google.com;
Received: from mail-lb0-f182.google.com ([209.85.217.182])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z25vd-0005Bm-I3
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Jun 2015 22:54:02 +0000
Received: by lbbqq2 with SMTP id qq2so841456lbb.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 08 Jun 2015 15:53:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.201.74 with SMTP id jy10mr19429838lbc.94.1433804035165;
Mon, 08 Jun 2015 15:53:55 -0700 (PDT)
Received: by 10.152.163.98 with HTTP; Mon, 8 Jun 2015 15:53:54 -0700 (PDT)
In-Reply-To: <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>
<20150607023523.GB1570@savin.petertodd.org>
Date: Mon, 8 Jun 2015 18:53:54 -0400
Message-ID: <CAGH37SLyG-g54-gGU5ZrmQsiogOqWNW1iiayHii1nWiWh+Nk=w@mail.gmail.com>
From: Kristov Atlas <kristovatlas.lists@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c36c963194ab05180984f5
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
(kristovatlas.lists[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Z25vd-0005Bm-I3
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: Mon, 08 Jun 2015 22:54:02 -0000
--001a11c36c963194ab05180984f5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hey Peter, thanks for your experienced feedback.
On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete@petertodd.org> wrote:
> 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.
>
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.
"Applicability: This BIP applies to all transactions of signature hash type
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"
> 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)
>
Thanks for the heads-up; removed.
> Do you have a patch implementing deterministic tx ordering for Bitcoin
> Core yet?
>
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.
-Kristov
--001a11c36c963194ab05180984f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Peter, thanks for your experienced feedback.<br><div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jun 6, 201=
5 at 10:35 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@pete=
rtodd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Why mention SIGHASH_SINGLE =
at all? Its use-case is highly specialized<br>
protocols; you haven't taken into account the needs of those protocols.=
<br>
For BIP's it's better to stick to the use-cases where the need is c=
lear<br>
and there exists running code that to speculate too much on future uses.<br=
>
With signature hashing in particular it's not yet clear at all what<br>
future OP_CHECKSIG's will look like, let alone the various ways people<=
br>
will use sighash for smart contract type stuff.<br>
<br>
You'd be better off presenting the BIP in terms of a generic statement<=
br>
that "except when otherwise prevented by advanced signature hashing<br=
>
requirements, wallet software must emit transactions sorted according to<br=
>
the following" You can then specify the two common cases in detail:<br=
>
<br>
1) SIGHASH_ALL: input and output order signed, so sort appropriately<br>
<br>
2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit<br=
>
=C2=A0 =C2=A0transactions sorted, recognising that the actual mined order m=
ay be<br>
=C2=A0 =C2=A0changed.<br></blockquote><div><br></div><div>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.<br><br>"<span s=
tyle=3D"font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-c=
olor:transparent;font-weight:normal;font-style:normal;font-variant:normal;t=
ext-decoration:none;vertical-align:baseline" id=3D"docs-internal-guid-b79d8=
ec4-d55b-e25c-cd64-cbdd8f842cf6">Applicability: This BIP applies to all tra=
nsactions of signature hash type SIGHASH_ALL. Additionally, =C2=A0software =
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_ANYO=
NECANPAY) should emit lexicographically sorted inputs and outputs, although=
they may later be modified. Transactions that have index dependencies betw=
een transactions or within the same transaction are covered under the secti=
on of this BIP entitled =E2=80=9CHandling Input/Output Dependencies.=E2=80=
=9D"</span></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
As for IsStandard() rules - let alone soft forks - better to leave<br>
discussion of them out for now. In particular, for the soft-fork case<br>
mandating certain transaction orders will very likely cause problems in<br>
the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it<br=
>
might be appropriate for nodes to enforce a certain ordering, but that<br>
can be a separate BIP. (actually implementing that in Bitcoin Core would<br=
>
be annoying and ugly right now; without replace-by-fee ANYONECANPAY has<br>
a silly DoS attack (adding low-fee inputs) so I can't recommend wallets=
<br>
use it in the general case yet)<br>
<br>
"and a sequence number currently set to 0xFFFFFFFF." <- Actual=
ly, this<br>
will be changed in Bitcoin Core as of v0.11.0, which implements<br>
anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP<br>
describing it)<br></blockquote><div><br></div><div>Thanks for the heads-up;=
removed.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
Do you have a patch implementing deterministic tx ordering for Bitcoin<br>
Core yet?<br></blockquote><div><br></div><div>I'm not a frequent C prog=
rammer, so I'd prefer to let someone else take care of it, as a frequen=
t committer of code would do a faster and more stylistically consistent job=
of it. If no one else will, however, I will. <br><br></div><div>-Kristov</=
div></div><br></div></div></div>
--001a11c36c963194ab05180984f5--
|
