BIP draft: Hard fork opt-in mechanism for SPV nodes

> 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