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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YsdFR-0006FD-9V
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 20:27:21 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.171 as permitted sender)
client-ip=209.85.220.171; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f171.google.com;
Received: from mail-qk0-f171.google.com ([209.85.220.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsdFQ-0003Wb-AF
for bitcoin-development@lists.sourceforge.net;
Wed, 13 May 2015 20:27:21 +0000
Received: by qkgy4 with SMTP id y4so36646655qkg.2
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 13:27:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.217.17 with SMTP id n17mr998385qhb.69.1431548834931;
Wed, 13 May 2015 13:27:14 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 13:27:14 -0700 (PDT)
In-Reply-To: <CAE-z3OV1WEDEV+X7gNVx+qBMt4jpSHFKXm3dxUrUyBEJrCNDSQ@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
<CAPg+sBggj382me1ATDx4SS9KHVfvX5KH7ZhLHN6B+2_a+Emw1Q@mail.gmail.com>
<CAE-z3OV1WEDEV+X7gNVx+qBMt4jpSHFKXm3dxUrUyBEJrCNDSQ@mail.gmail.com>
Date: Wed, 13 May 2015 21:27:14 +0100
Message-ID: <CAE-z3OU-fdTrKRkni4xmmY5uBVWS0KJ_2NVh6k1tcMSGTPp+4Q@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1139b816c8e8d80515fc6f82
X-Spam-Score: 2.3 (++)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
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
1.9 MALFORMED_FREEMAIL Bad headers on message from free email service
-0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YsdFQ-0003Wb-AF
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
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: Wed, 13 May 2015 20:27:21 -0000
--001a1139b816c8e8d80515fc6f82
Content-Type: text/plain; charset=UTF-8
After more thought, I think I came up with a clearer description of the
recursive version.
The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning. All txids in the entire blockchain should be replaced with the
"correct" values.
This requires a full re-index of the blockchain. You can't work out what
the TXID-N of a transaction is without knowning the TXID-N of its parents,
in order to do the replacement.
The non-recursive version can only handle refunds one level deep.
A:
from: IN
sigA: based on hash(...)
B:
from A
sig: based on hash(from: TXID-N(A) | "") // sig removed
C:
from B
sig: based on hash(from: TXID-N(B) | "") // sig removed
If A is mutated before being added into the chain, then B can be modified
to a valid transaction (B-new).
A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation
B has to be modified to B-new to make it valid.
B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")
Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.
Howver, C-new cannot be created.
C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")
TXID-N(B-new) is not the same as TXID-N(B). Since the from field is not
removed by the TXID-N operation, differences in that field mean that the
TXIDs are difference.
This means that the signature for C is not valid for C-new.
The recursive version repairs this problem.
Rather than simply delete the scriptSig from the transaction. All txids
must also be replaced with their TXID-N versions.
Again, A is mutated before being added into the chain and B-new is produced.
A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation
TXID-N: TXID-N(A)
B has to be modified to B-new to make it valid.
B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")
TXID-N: TXID-N(B)
Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.
Likewise the TXID-N(B-new) is equal to TXID-N(B).
The from field is replaced by the TXID-N from A-mutated which is equal to
TXID-N(A) and the sig is the same.
C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")
The signature is still valid, since TXID-N(B-new) is the same as TXID-N(B).
This means that multi-level refunds are possible.
--001a1139b816c8e8d80515fc6f82
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>After more thought, I think I came up with a clearer =
description of the recursive version.<br><br>The simple definition is that =
the hash for the new signature opcode should simply assume that the normali=
zed txid system was used since the beginning.=C2=A0 All txids in the entire=
blockchain should be replaced with the "correct" values.<br><br>=
This requires a full re-index of the blockchain.=C2=A0 You can't work o=
ut=20
what the TXID-N of a transaction is without knowning the TXID-N of its=20
parents, in order to do the replacement.<br><br>The non-recursive version c=
an only handle refunds one level deep.<br><br>A:<br>from: IN<br>sigA: based=
on hash(...)<br><br>B:<br>from A<br>sig: based on hash(from: TXID-N(A) | &=
quot;")=C2=A0 // sig removed<br><br>C:<br>from B<br>sig: based on hash=
(from: TXID-N(B) | "")=C2=A0 // sig removed<br><br>If A is mutate=
d before being added into the chain, then B can be modified to a valid tran=
saction (B-new).<br><br>A-mutated:<br>from: IN<br>sig_mutated: based on has=
h(...) with some mutation<br><br>B has to be modified to B-new to make it v=
alid.<br><br>B-new:<br>from A-mutated<br>sig: based on hash(from: TXID-N(A-=
mutated), "")<br><br>Since TXID-N(A-mutated) is equal to TXID-N(A=
), the signature from B is still valid.<br><br>Howver, C-new cannot be crea=
ted.<br><br>C-new:<br>from B-new<br>sig: based on hash(from: TXID-N(B-new),=
"")<br><br>TXID-N(B-new) is not the same as TXID-N(B).=C2=A0 Sin=
ce the from field is not removed by the TXID-N operation, differences in th=
at field mean that the TXIDs are difference.<br><br>This means that the sig=
nature for C is not valid for C-new.<br><br>The recursive version repairs t=
his problem.=C2=A0 <br><br>Rather than simply delete the scriptSig from the=
transaction.=C2=A0 All txids must also be replaced with their TXID-N versi=
ons.<br><br>Again, A is mutated before being added into the chain and B-new=
is produced.<br><br>A-mutated:<br>from: IN<br>sig_mutated: based on hash(.=
..) with some mutation<br>TXID-N: TXID-N(A)<br><br>B has to be modified to =
B-new to make it valid.<br><br>B-new:<br>from A-mutated<br>sig: based on ha=
sh(from: TXID-N(A-mutated), "")<br>TXID-N: TXID-N(B)<br><br>Since=
TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is still val=
id.<br><br>Likewise the TXID-N(B-new) is equal to TXID-N(B).<br><br>The fro=
m field is replaced by the TXID-N from A-mutated which is equal to TXID-N(A=
) and the sig is the same.<br><br>C-new:<br>from B-new<br>sig: based on has=
h(from: TXID-N(B-new), "")<br><br>The signature is still valid, s=
ince TXID-N(B-new) is the same as TXID-N(B).<br><br></div>This means that m=
ulti-level refunds are possible.<br></div>
--001a1139b816c8e8d80515fc6f82--
|
