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
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CD122D56
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 18:41:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6741F17D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 18:40:58 +0000 (UTC)
Received: from [::1] (port=33569 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.86)
(envelope-from <jl2012@xbt.hk>) id 1aRlJR-0025Lk-9L
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 05 Feb 2016 13:40:57 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_ce64c5bf1024ca3af083e9d210b0fbc9"
Date: Fri, 05 Feb 2016 13:40:57 -0500
From: jl2012 <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <5e8eb817e242e59260703a4d1505252f@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.6
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] BIP draft: Hard fork opt-in mechanism for SPV nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 18:41:00 -0000
--=_ce64c5bf1024ca3af083e9d210b0fbc9
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
BIP draft: Hard fork opt-in mechanism for SPV nodes:
https://github.com/bitcoin/bips/pull/320
This is a supplement, instead of a replacement, of the hardfork bit BIP:
https://github.com/bitcoin/bips/pull/317
They solves different problems:
The hardfork bit tells full and SPV that a planned hardfork (instead of
a softfork) has happened.
This BIP makes sure SPV nodes won't lose any money in a hardfork, even
if they do not check the hardfork bit.
---------------------
BIP: ?
Title: Hard fork opt-in mechanism for SPV nodes
Author: Johnson Lau <jl2012@xbt.hk>
Status: Draft
Type: Standard Track
Created: 2016-02-05
ABSTRACT
This document specifies a new algorithm for the transaction commitment
in block header, to ensure that SPV nodes will not automatically follow
a planned hard fork without explicit opt-in consent.
[1]MOTIVATION
A hard fork in Bitcoin is a consensus rule change where previously
invalid blocks become valid. For the operators of fully validating
nodes, migration to the new fork requires conscious actions. However,
this may not be true for SPV node, as many consensus rules are
transparent to them. SPV nodes may follow the chain with most
proof-of-work, even if the operators do not agree with the economical or
ideological properties of the chain.
By specifying a new algorithm for the transaction commitment in block
header, migration to the new fork requires explicit opt-in consent for
SPV nodes. It is expected that this proposal will be implemented with
other backward-incompatible consensus rule changes at the same time.
[2]SPECIFICATION
The calculation of Merkle root remains unchanged. Instead of directly
committing the Merkle root to the header, we commit
Double-SHA256(zero|merkle_root|zero)
where zero is 0x0000....0000 with 32 bytes.
[3]RATIONALE
Since the header structure is not changed, non-upgraded SPV nodes will
still be able to verify the proof-of-work of the new chain, and they
will follow the new chain if it has most proof-of-work. However, they
will not be able to the accept any incoming transactions on the new
chain since they cannot verify them with the new commitment format. At
the same time, SPV nodes will not accept any new transactions on the old
chain, as they find it has less proof-of-work. Effectively, SPV nodes
stop accepting any transactions, until their operators take further
actions.
Zero-padding is applied before and after the merkle_root, so it is not
possible to circumvent the rule change with any current implementations,
even for faulty ones.
A future hard fork should change the padding value to stop non-upgraded
SPV nodes from processing new transactions.
Hard forks may sometimes be totally uncontroversial and make barely
noticeable change (BIP50 [4], for example). In such cases, changing the
padding value may not be needed as it may cause unnecessary disruption.
The risk and benefit should be evaluated case-by-case.
[5]COMPATIBILITY
As a mechanism to indicate hard fork deployment, this BIP breaks
backward compatibility intentionally. However, without further changes
in the block header format, non-upgraded full nodes and SPV nodes could
still verify the proof-of-work of upgraded blocks.
INTERACTION WITH FRAUD PROOF SYSTEM A fraud proof system is full nodes
that will generate compact proofs to testify invalid blocks on the
blockchain, verifiable by SPV nodes. Hard forks without any malicious
intention may also be considered as a "fraud" among non-upgraded nodes.
This may not be desirable, as the SPV node may accept devalued tokens on
the old chain with less proof-of-work. With this BIP, non-upgraded SPV
nodes will always believe the new chain is valid (since they cannot
verify any fraud proof), while cannot be defrauded as they will not see
any incoming transactions.
[6]COPYRIGHT
This document is placed in the public domain.
Links:
------
[1]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#motivation
[2]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specification
[3]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationale
[4] https://github.com/jl2012/bips/blob/merkleroot/bip-0050.mediawiki
[5]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compatibility
[6]
https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyright
--=_ce64c5bf1024ca3af083e9d210b0fbc9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri=
f'>
<pre>BIP draft: Hard fork opt-in mechanism for SPV nodes: https://github.co=
m/bitcoin/bips/pull/320
This is a supplement, instead of a replacement, of the hardfork bit BIP: ht=
tps://github.com/bitcoin/bips/pull/317
They solves different problems:<br /><br />The hardfork bit tells full and =
SPV that a planned hardfork (instead of a softfork) has happened.<br /><br =
/>This BIP makes sure SPV nodes won't lose any money in a hardfork, even if=
they do not check the hardfork bit.<br />
---------------------</pre>
<pre>BIP: ?
Title: Hard fork opt-in mechanism for SPV nodes
Author: Johnson Lau <jl2012@xbt.hk>
Status: Draft
Type: Standard Track
Created: 2016-02-05
</pre>
<p> </p>
<p><a name=3D"user-content-Abstract"></a></p>
<h2>Abstract</h2>
<p>This document specifies a new algorithm for the transaction commitment i=
n block header, to ensure that SPV nodes will not automatically follow a pl=
anned hard fork without explicit opt-in consent.</p>
<h2><a id=3D"user-content-motivation" class=3D"anchor" href=3D"https://gith=
ub.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#motivation"></a><a =
name=3D"user-content-Motivation"></a>Motivation</h2>
<p>A hard fork in Bitcoin is a consensus rule change where previously inval=
id blocks become valid. For the operators of fully validating nodes, migrat=
ion to the new fork requires conscious actions. However, this may not be tr=
ue for SPV node, as many consensus rules are transparent to them. SPV nodes=
may follow the chain with most proof-of-work, even if the operators do not=
agree with the economical or ideological properties of the chain.</p>
<p>By specifying a new algorithm for the transaction commitment in block he=
ader, migration to the new fork requires explicit opt-in consent for SPV no=
des. It is expected that this proposal will be implemented with other backw=
ard-incompatible consensus rule changes at the same time.</p>
<h2><a id=3D"user-content-specification" class=3D"anchor" href=3D"https://g=
ithub.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specification"><=
/a><a name=3D"user-content-Specification"></a>Specification</h2>
<p>The calculation of Merkle root remains unchanged. Instead of directly co=
mmitting the Merkle root to the header, we commit</p>
<p> </p>
<pre> Double-SHA256(zero|merkle_root|zero)
</pre>
<p> </p>
<p>where <code>zero</code> is <code>0x0000....0000</code>&nb=
sp;with 32 bytes.</p>
<h2><a id=3D"user-content-rationale" class=3D"anchor" href=3D"https://githu=
b.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationale"></a><a na=
me=3D"user-content-Rationale"></a>Rationale</h2>
<p>Since the header structure is not changed, non-upgraded SPV nodes will s=
till be able to verify the proof-of-work of the new chain, and they will fo=
llow the new chain if it has most proof-of-work. However, they will not be =
able to the accept any incoming transactions on the new chain since they ca=
nnot verify them with the new commitment format. At the same time, SPV node=
s will not accept any new transactions on the old chain, as they find it ha=
s less proof-of-work. Effectively, SPV nodes stop accepting any transaction=
s, until their operators take further actions.</p>
<p>Zero-padding is applied before and after the <code>merkle_root</cod=
e>, so it is not possible to circumvent the rule change with any current im=
plementations, even for faulty ones.</p>
<p>A future hard fork should change the padding value to stop non-upgraded =
SPV nodes from processing new transactions.</p>
<p>Hard forks may sometimes be totally uncontroversial and make barely noti=
ceable change (<a href=3D"https://github.com/jl2012/bips/blob/merkleroot/bi=
p-0050.mediawiki">BIP50</a>, for example). In such cases, changing the padd=
ing value may not be needed as it may cause unnecessary disruption. The ris=
k and benefit should be evaluated case-by-case.</p>
<h2><a id=3D"user-content-compatibility" class=3D"anchor" href=3D"https://g=
ithub.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compatibility"><=
/a><a name=3D"user-content-Compatibility"></a>Compatibility</h2>
<p>As a mechanism to indicate hard fork deployment, this BIP breaks backwar=
d compatibility intentionally. However, without further changes in the bloc=
k header format, non-upgraded full nodes and SPV nodes could still verify t=
he proof-of-work of upgraded blocks.</p>
<p><strong>Interaction with fraud proof system</strong> A fraud proof =
system is full nodes that will generate compact proofs to testify invalid b=
locks on the blockchain, verifiable by SPV nodes. Hard forks without any ma=
licious intention may also be considered as a “fraud” among non=
-upgraded nodes. This may not be desirable, as the SPV node may accept deva=
lued tokens on the old chain with less proof-of-work. With this BIP, non-up=
graded SPV nodes will always believe the new chain is valid (since they can=
not verify any fraud proof), while cannot be defrauded as they will not see=
any incoming transactions.</p>
<h2><a id=3D"user-content-copyright" class=3D"anchor" href=3D"https://githu=
b.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyright"></a><a na=
me=3D"user-content-Copyright"></a>Copyright</h2>
<p>This document is placed in the public domain.</p>
</body></html>
--=_ce64c5bf1024ca3af083e9d210b0fbc9--
|
