public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sancho Panza <sanch0panza@protonmail.com>
To: Luke Dashjr <luke@dashjr.org>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>,
	"luke_bipeditor@dashjr.org" <luke_bipeditor@dashjr.org>
Subject: Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
Date: Tue, 04 Apr 2017 15:28:38 -0400	[thread overview]
Message-ID: <dij0O5yPt02UZsM0a08JAe17rK2Ttr4-Ox-KpiPQ577ltpXLrhqanNgsvTIpLJ1I9QQMVIy1Brngg5GtTt6OrgtEqbJ9HlO-e9odjEpsXeU=@protonmail.com> (raw)
In-Reply-To: <201704041801.51655.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

> BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it
> not being applicable to hardforks. BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process smoother
> this way. But the same is not true of hardforks: miners are essentially
> irrelevant to them, and cannot make the process any smoother.

I accept that BIP9 is inherently concerned only with softforks, as it is explicit about this in every instance.
However, I see no fundamental distinction between the 'royal privilege' assigned to miners w.r.t. softfork activation and the role they would play in properly coordinated hardforks.
In either case, the majority of miners would hopefully want to wait for the right conditions to create the fork block, whether that block be the first one to contain SegWit transactions or the first one to be larger than 1MB (to give two current examples).
The advance coordination with the rest of the users in the system seems important in either case.

This is a big motivator for this BIP: the versionbits can be used as a coordination mechanism for hardforks just as much as softforks.
With the added flexibility offered by this BIP, miners could use these bits to make the process smoother for softforks as well as hardforks.

For example (this is an idea I did not write in the initial BIP draft), the period for which a fork on a particular bit remains LOCKED_IN could be made customizable too, instead of one single retargeting period.
This would allow fork implementors to specify a longer adaptation period suitable to the impacts of the feature they are planning to deploy.

> Therefore, BIP 9 and any miner signalling in general is not very useful
> for deploying these.

I think BIP9 is a very useful tool that allows a decent determination of how much of the hashing power supports a particular fork proposal.

My view is that both soft and hard forks without support from the majority of miners place themselves at high risk.
In general every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it.

It seems to me that this somewhat balances out the (dis)advantages and effectively puts these fork types on a similar footing.
This is a rationale for generalizing the signaling mechanism introduced by BIP9.

In practice, developers will still need to choose whether their feature is best deployed by softfork or hardfork. This proposal affords them that choice, and does not propose any arbitrary conditions (e.g. a predefined split of the versionbits range into particular categories of forks or activation levels).

> Softforks are not required to use BIP 9, and even if they do, they are not
> required to use the recommended thresholds.

This is true, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork which was on the Core roadmap to accomodate certain wishlist items that cannot easily be addressed by softforks.

[-- Attachment #2: Type: text/html, Size: 3652 bytes --]

  reply	other threads:[~2017-04-04 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-03  9:06 [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting) Sancho Panza
2017-04-04 11:16 ` Tom Zander
2017-04-04 16:41   ` Sancho Panza
2017-04-04 16:49   ` Sancho Panza
2017-04-04 18:01 ` Luke Dashjr
2017-04-04 19:28   ` Sancho Panza [this message]
2017-04-05 10:08   ` Tom Zander
2017-04-05 14:09     ` Thomas Kerin
2017-04-08 21:58       ` Sancho Panza

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='dij0O5yPt02UZsM0a08JAe17rK2Ttr4-Ox-KpiPQ577ltpXLrhqanNgsvTIpLJ1I9QQMVIy1Brngg5GtTt6OrgtEqbJ9HlO-e9odjEpsXeU=@protonmail.com' \
    --to=sanch0panza@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    --cc=luke_bipeditor@dashjr.org \
    /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