From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D1FA31045 for ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org, jl2012 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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