public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, jl2012 <jl2012@xbt.hk>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Date: Thu, 4 Feb 2016 18:29:11 +0000	[thread overview]
Message-ID: <201602041829.13459.luke@dashjr.org> (raw)
In-Reply-To: <f225318eddd0aadc71861f988f2f4674@xbt.hk>

On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> ABSTRACT
> 
> This document specifies a proposed change to the semantics of the sign
> bit of the "version" field in Bitcoin block headers, as a mechanism to
> indicate a hardfork is deployed.

Disagree with treating the "version" field as a number, in BIP 9 or this BIP 
which reinterpret it as a bit vector.

> Among the 640 bits in the block header, this is the only one which is
> fixed and serves no purpose, ...

Minor nit (not relevant to actual proposal): This is not true. There are over 
32 other bits (part of the "previous-block" field) which also serve no 
purpose.

> FLAG BLOCK Any planned hardfork must have one and only one flag block
> which is the "point of no return". To ensure monotonicity, flag block
> should be determined by block height, or as the first block with
> GetMedianTimePast() greater than a threshold. Other mechanisms could be
> difficult for SPV nodes to follow. The height/time threshold could be a
> predetermined value or relative to other events (e.g. 10000 blocks / 100
> days after 95% of miner support). The exact mechanism is out of the
> scope of this BIP. No matter what mechanism is used, the threshold is
> consensus critical. It must be publicly verifiable with only blockchain
> data, and preferably SPV-friendly (i.e. verifiable with block headers
> only, without downloading any transaction).

With the current codebase, it is significantly easier to trigger on the block 
timestamp rather than its height or median-time-past. Using either of the 
latter would require refactoring of CBlockIndex. As a hard-fork, even if the 
rules are ineffective for a few blocks following the forking point, using the 
hardfork version bit in this BIP would still ensure a clean break. While I 
agree that median-time-past and height are superior methods that ought to be 
used for hardforks, an emergency hardfork may need to avoid them for 
simplicity, and I don't think they need to be mandated as such in this BIP.

> Although a hardfork is officially deployed when flag block is generated, ...

I would avoid implying the hardfork can be "officially deployed" without 
actual adoption.

> AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
> found on the network, full nodes and SPV nodes should alert their users
> and/or stop accepting/sending transactions. It should be noted that the
> warning system could become a denial-of-service vector if the attacker
> is willing to give up the block reward. Therefore, the warning may be
> issued only if a few blocks are built on top of the flag block in a
> reasonable time frame. This will in turn increase the risk in case of a
> real planned hardfork so it is up to the wallet programmers to decide
> the optimal strategy. Human warning system (e.g. the emergency alert
> system in Bitcoin Core) could fill the gap.

This seems vulnerable to DoS attacks by rejected hardforks.

> VERSION BITS This proposal is also compatible with the BIP9. The version
> bits mechanism could be employed to measure miner support towards a
> hardfork proposal, and to determine the height or time threshold of the
> flag block. Also, miners of the flag block may still cast votes for
> other concurrent softfork or hardfork proposals as normal.

Rather not imply BIP 9 should be used for hardforks, or that miners have any 
voice in the decision. This is already a serious misconception.

> POINT OF NO RETURN After the flag block is generated, a miner may
> support either the original rules or the new rules, but not both. It is
> not possible for miners in one fork to attack or overtake the other fork
> without giving up the mining reward of their preferred fork.

This is not actually desirable, and would suggest a possible reason *not* to 
comply with this BIP. A legitimate hardfork would never have two continued 
sets of rules for miners to choose from.

Luke


  parent reply	other threads:[~2016-02-04 18:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04 17:14 [bitcoin-dev] Hardfork bit BIP jl2012
2016-02-04 17:36 ` Gavin Andresen
2016-02-04 17:56   ` jl2012
2016-02-04 18:00     ` Bryan Bishop
2016-02-04 18:24     ` Tier Nolan
2016-02-04 18:19   ` Peter Todd
2016-02-04 18:29 ` Luke Dashjr [this message]
2016-02-05 10:20   ` Jorge Timón
2016-02-04 19:36 ` Gregory Maxwell
2016-02-04 22:15   ` Gavin Andresen
2016-02-05  9:58     ` Jorge Timón
2016-02-07 19:27     ` jl2012
2016-02-07 20:20       ` Gavin
2016-02-08  2:44         ` Anthony Towns

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=201602041829.13459.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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