From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org, jl2012 <jl2012@xbt•hk>
Subject: Re: [bitcoin-dev] BIP draft: Hard fork opt-in mechanism for SPV nodes
Date: Fri, 5 Feb 2016 23:25:14 +0000 [thread overview]
Message-ID: <201602052325.16472.luke@dashjr.org> (raw)
In-Reply-To: <5e8eb817e242e59260703a4d1505252f@xbt.hk>
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
prev parent reply other threads:[~2016-02-05 23:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 18:40 jl2012
2016-02-05 23:25 ` Luke Dashjr [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201602052325.16472.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox