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 <jl2...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
