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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <kristovatlas.lists@gmail.com>) id 1Z1O7E-0008Fn-N0
for bitcoin-development@lists.sourceforge.net;
Sun, 07 Jun 2015 00:07:04 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.65 as permitted sender)
client-ip=209.85.215.65;
envelope-from=kristovatlas.lists@gmail.com;
helo=mail-la0-f65.google.com;
Received: from mail-la0-f65.google.com ([209.85.215.65])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z1O7D-0004as-CI
for bitcoin-development@lists.sourceforge.net;
Sun, 07 Jun 2015 00:07:04 +0000
Received: by lams18 with SMTP id s18so2273800lam.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 06 Jun 2015 17:06:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.225.166 with SMTP id rl6mr9762273lac.36.1433635616964;
Sat, 06 Jun 2015 17:06:56 -0700 (PDT)
Received: by 10.152.163.98 with HTTP; Sat, 6 Jun 2015 17:06:56 -0700 (PDT)
In-Reply-To: <CAGH37SL3TA7BXd3Y+4F1Fd5N3ZW+LRLvkfppPsPn61ZVbZJOnQ@mail.gmail.com>
References: <CAGH37SK0k1YUvadetyHcBGjzW+OHNFRmRwqsUDeHBGejUacigQ@mail.gmail.com>
<44BE16F9-AB24-4A8E-BC7F-03A6C590FCE7@gmail.com>
<CAGH37SL3TA7BXd3Y+4F1Fd5N3ZW+LRLvkfppPsPn61ZVbZJOnQ@mail.gmail.com>
Date: Sat, 6 Jun 2015 20:06:56 -0400
Message-ID: <CAGH37SLCc-aEG0t0H7fsUZOv_h+Fiw4xoonmfwNaFWBin_7HcQ@mail.gmail.com>
From: Kristov Atlas <kristovatlas.lists@gmail.com>
To: Stephen <stephencalebmorse@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134986cafc4270517e24da1
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: 1Z1O7D-0004as-CI
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 00:07:04 -0000
--001a1134986cafc4270517e24da1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:
Handling Input/Output Dependencies
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 the=
output indices
that depend on the input order, and sort the remaining outputs around them.
If there are no outputs that do not depend on input order, then all outputs
will simply be ordered based on the expected scheme. The following are the
known cases of input/output dependency that must be handled specially:
* SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI01 compliance
for a transaction must inspect the last byte of the scriptSig of each input
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.
https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
I'm satisfied with this adjustment, as it is unlikely that any software
that wants to verify compliance with the BIP will not have access to the
scriptSig of each input.
-Kristov
On Sat, Jun 6, 2015 at 2:24 AM, Kristov Atlas <kristovatlas.lists@gmail.com=
>
wrote:
> Hey Stephen,
>
> Thanks for your feedback
>
> On Fri, Jun 5, 2015 at 11:20 PM, Stephen <stephencalebmorse@gmail.com>
> wrote:
>
>> - I think your explanation of sorting could be significantly shortened
>> and clarified by simply saying that the TXIDs of inputs should be compar=
ed
>> as uint256 integers.
>>
>
> I considered defining the comparison of txids in terms of integers;
> however, I am concerned that this definition may be ambiguous when applie=
d
> to a variety of languages and platforms without a similar amount of
> explanation as currently exists. For example, if a web wallet uses an API
> to receive transaction information, this is traditionally expressed in
> terms tx id strings rather than 256-bit integers. My intent is that walle=
ts
> can implement the algorithm however they wish, but should ensure that the=
ir
> output is compliant with the BIP definition. IMHO the algorithm stated in
> the BIP should target test cases rather than implementation, and should
> leave as little room for ambiguity as possible.
>
--001a1134986cafc4270517e24da1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>I've updated the draft BIP in two ways:=
<br></div>-Making it clear that sorting is algorithmically agnostic, but sh=
ould conform to the output of the example algorithms written in python<br><=
/div>-The BIP now handles schemes that create an input/output dependency, s=
uch as SIGHASH_SINGLE:<br><br>Handling Input/Output Dependencies<br><br>Som=
e uncommon forms of transactions create an ordering dependency between inpu=
ts 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 the outpu=
t indices that depend on the input order, and sort the remaining outputs ar=
ound them. If there are no outputs that do not depend on input order, then =
all outputs will simply be ordered based on the expected scheme. The follow=
ing are the known cases of input/output dependency that must be handled spe=
cially:<br><br>* SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI=
01 compliance for a transaction must inspect the last byte of the scriptSig=
of each input 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 th=
at output =E2=80=9Cn=E2=80=9D will be fixed when considering output orderin=
g.<br><br><a href=3D"https://github.com/kristovatlas/rfc/blob/master/bips/b=
ip-li01.mediawiki">https://github.com/kristovatlas/rfc/blob/master/bips/bip=
-li01.mediawiki</a><br><br></div><div>I'm satisfied with this adjustmen=
t, as it is unlikely that any software that wants to verify compliance with=
the BIP will not have access to the scriptSig of each input.<br></div><div=
><br></div>-Kristov<br></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Sat, Jun 6, 2015 at 2:24 AM, Kristov Atlas <span dir=3D"ltr"=
><<a href=3D"mailto:kristovatlas.lists@gmail.com" target=3D"_blank">kris=
tovatlas.lists@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Hey Stephen,<br><br></div>Thanks for your feedb=
ack<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D=
"">On Fri, Jun 5, 2015 at 11:20 PM, Stephen <span dir=3D"ltr"><<a href=
=3D"mailto:stephencalebmorse@gmail.com" target=3D"_blank">stephencalebmorse=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto"><div>=C2=A0- I think your explanation of sorting could be signifi=
cantly shortened and clarified by simply saying that the TXIDs of inputs sh=
ould be compared as uint256 integers.=C2=A0</div></div></blockquote><div><b=
r></div></span><div>I considered defining the comparison of txids in terms =
of integers; however, I am concerned that this definition may be ambiguous =
when applied to a variety of languages and platforms without a similar amou=
nt of explanation as currently exists. For example, if a web wallet uses an=
API to receive transaction information, this is traditionally expressed in=
terms tx id strings rather than 256-bit integers. My intent is that wallet=
s can implement the algorithm however they wish, but should ensure that the=
ir output is compliant with the BIP definition. IMHO the algorithm stated i=
n the BIP should target test cases rather than implementation, and should l=
eave as little room for ambiguity as possible. <br></div></div></div></div>
</blockquote></div><br></div>
--001a1134986cafc4270517e24da1--
|