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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D1FA31045
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 23:25:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 29C8519F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Feb 2016 23:25:37 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 7A9CE38A9783;
Fri, 5 Feb 2016 23:25:17 +0000 (UTC)
X-Hashcash: 1:25:160205:bitcoin-dev@lists.linuxfoundation.org::JzGryT90ea8d5pMw:akoi0
X-Hashcash: 1:25:160205:jl2012@xbt.hk::YpRVJYR+odDwYTxm:a2NnE
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
jl2012 <jl2012@xbt.hk>
Date: Fri, 5 Feb 2016 23:25:14 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <5e8eb817e242e59260703a4d1505252f@xbt.hk>
In-Reply-To: <5e8eb817e242e59260703a4d1505252f@xbt.hk>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602052325.16472.luke@dashjr.org>
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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 23:25:37 -0000
Soft-hardforks have the same behaviour for both SPV and full nodes.
I don't see the point in making this SPV-only "middle layer"...
On Friday, February 05, 2016 6:40:57 PM jl2012 via bitcoin-dev wrote:
> 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#motivat
> ion [2]
> https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#specifi
> cation [3]
> https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#rationa
> le [4] https://github.com/jl2012/bips/blob/merkleroot/bip-0050.mediawiki
> [5]
> https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#compati
> bility [6]
> https://github.com/jl2012/bips/blob/merkleroot/spvoptinhf.mediawiki#copyrig
> ht
|
