From: "Jorge Timón" <jtimon@jtimon•cc>
To: Luke-Jr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
Date: Fri, 5 Feb 2016 11:20:28 +0100 [thread overview]
Message-ID: <CABm2gDp+mm75+g2gvZmzO_+BP1+qG0yo9Y80tTdNxAsxNE6j_Q@mail.gmail.com> (raw)
In-Reply-To: <201602041829.13459.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 4526 bytes --]
On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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.
I don't interpret this as "treating version bits as a number" it is just
being explained which bit we're talking about. Could you propose some
concrete rephrasing instead of leaving the task of somehow solving this
vague and subtle concern to the author?
> > 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.
I very much disagree with "significant" and in any case it depends on the
hardfork: the changes required can still be quite minimal in all cases and
it should never be a problem, even for emergency hardforks. In emergency,
we could for example just a new global (we have many already anyway),
although activeChain.tip () is already there and one can simply get the
last height or median time from there.
> > 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.
This is consistent with bip99, which recommends bip9 for deploying
uncontroversial hardforks.
> > 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.
Controversial hardforks (as defined bip9) always have the potential to
create two chains that survive for unbounded amounts of time (maybe
forever) as discussed in one of the few threads of the bitcoin discuss
mailing list.
Of course, BIP99 cannot say anything general about the "legitimacy" of all
controversial hardforks since ASIC-reset hardforks, for example, are
controversial hardforks by definition in the context of bip99 (and the
definitions in bip99 seem to apply to this bip). BIP99 can only warn about
the dangers and risks of controversial hardforks but at some point (let's
hope never) a controversial hardfork may be required to save the system
from some evil (say, evil miners blacklisting via softforking out the
miners that don't blacklist or something) and that controversial hardfork
would be legitimate (at least to the eyes of some).
[-- Attachment #2: Type: text/html, Size: 5258 bytes --]
next prev parent reply other threads:[~2016-02-05 10:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 17:14 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
2016-02-05 10:20 ` Jorge Timón [this message]
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=CABm2gDp+mm75+g2gvZmzO_+BP1+qG0yo9Y80tTdNxAsxNE6j_Q@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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