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>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602052325.16472.luke@dashjr.org>
Subject: Re: [bitcoin-dev] BIP draft: Hard fork opt-in mechanism for SPV
	nodes
Precedence: list

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