BIP9+ : Generalized version bits voting (bip-genvbvoting)

[SanchoPanza]

EDIT (8 May 2017): This has now become BIP135 . I left the title to preserve the history.

¡Hola!

[ Por favor considéralo como una vista previa ]

Please find below a proposal for a new informational BIP provisionally named 'bip-genvbvoting'.
I present it here in rough draft for your esteemed consideration and as a basis for discussion.

Best regards,
Sancho

--- begin draft of bip-genvbvoting ---

Preamble

BIP: ?
Title: Generalized version bits voting
Author: Sancho Panza <sanch0panza@protonmail.com>
Status: Draft
Type: Informational
Created: 2017-03-29
License: CC0-1.0, GNU-All-Permissive
Replaces: 9

Abstract

This document describes a generalized version bits voting scheme based
on and intended to replace BIP9.

The generalization consists of allowing each version bit to be treated
individually using a configurable percentage threshold and window size,
instead of the fixed 95% (mainnet) and 2016 block window specified in
BIP9.

The state machine and governing parameters (name, bit, starttime,
timeout) remain as is, but additional parameters called 'threshold' and
'windowsize' are added to the per-bit set.

As before, a set of per-chain parameters will exist for the version bits
governed by BIP9.

Motivation

The Bitcoin protocol requires a flexible consensus-finding scheme
to ensure that it can adapt to the needs of the market (its users) and
remain competitive as an electronic payment system.

While BIP9 has served the community reasonably well until now, the
author remarks several shortcomings in its approach:

• it limits itself to backward-compatible changes, precluding its applicability to hard forks
• a fixed 95% threshold is not flexible enough to allow for a 'spectrum of contentiousness' to be represented
• the 95% threshold allows small minorities to veto proposed changes, leading to stagnation (viz. current standoffs)

A more generalized implementation of voting on changes using version bits
can address these issues in a way that can satisfy the needs of both soft
and hard forks, as well as represent varying degrees of contentiousness.

Specification

To be elaborated.

It is thought that only cosmetic changes are needed to generalize from
only soft forks to 'soft or hard forks', and to add the additional
per-bit parameters 'threshold' and 'windowsize'

References to fixed values will need to be eliminated and replaced
by respective parameters.

The design of the state machine is envisioned to remain unchanged.

Implementation

A reference implementation can be constructed after elaboration of
the specification.

Copyright

This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal
and GNU All-Permissive licenses.

--- end draft of bip-genvbvoting ---

 

[SanchoPanza]

I tried to explain more about the "why?" and benefits in this Reddit post:
https://np.reddit.com/r/btc/comments/6287pu/i_am_sancho_panza_author_of_the_recent/

Not everyone here uses Reddit, so let me quote the relevant parts so we can get some discussion and feedback going here - I would much appreciate it.

---

You may not have seen the proposal, because my posting to bitcoin-dev seems stuck in some moderation queue. And I guess the post on /r/Bitcoin never made it past the automod. Here's an uncensored link to the original post:


TL;DR?

Replace BIP9 by something that lets us configure voting threshold and other parameter for each version bit representing a proposed change.

What is this proposal useful for?

BIP9 used a fixed 95% threshold and 2016 block window for all the version bit. We know that didn't turn out well for some soft-forks who miscalculated their support level badly.

Of course not every change proposal (whether soft- or hard-fork) is equally contentious, so it just makes sense to be able to configure a 75% threshold for something like BIP101 without having to change the voting machinery each time, while maybe keeping a 95% or 90% threshold for other things going on.

Other benefits are that one could easily relax the threshold of a fork if the initial 'guesstimate' of the required degree of consensus turns out to be way too high.

The window size would also become configurable per bit, adding the option of better reactivity, if a change requires a shorter voting period.

I'm also thinking about making the LOCKED_IN period configurable per bit too, since not every change needs the same kind of grace period in the ecosystem.

The end result, hopefully, will be that those 29 versionbits allocated to BIP9 can be put to better and more flexible use in the future.

The goal is to make protocol upgrades less dramatic and thereby keep Bitcoin more competitive.

If you have any ideas or suggestions, this is a good place to discuss while I wait for the BIP editor to get back to me on the status of the mailing list submission.

Another good place to discuss and provide feedback is here:

https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/ [ this post - ignore the link ]

Thanks in advance!

 

[theZerg]

I think that you are absolutely right BIP9 is pretty useless as defined due to the hard coded 95% threshold. Different features may require different thresholds.

The problem is that there isn't a place to store the thresholds in a block.
So when a bit is utilized to signal some feature, the threshold will need to be defined

This has one negative consequence in today's client, if an old client is still running an a feature is activated, it will say "WARNING: unknown feature activated (bit 5)"
This specificity is actually pretty useless because its just another way of saying "upgrade your client".
So the BIP could issue a log at different activation thresholds, and be just as effective:
"warning: voting started on unknown feature" "warning: voting on unknown feature reached X%"

where X is 25,50,75,95 or maybe every 5%, just reduce the spam. this might actually be a LOT more useful than the log we have today
actually, an RPC call that prints out the % would be most useful, because scripts shouldn't be parsing thru the human readable logs -- there already is one, I think. If it doesn't already it would just need to be updated to print the current % voting yes on every nonzero bit.

 

[SanchoPanza]

Thank you for the feedback!

Yes, I don't think log output should enable anything but traces for the signaling bits that the user might want to see. At least it should allow turning off logging for all bits that the software knows about but the user may not be interested in. And it should have a low "noise level" on bits about which the software knows little.
A log message like you said about warning when signaling is detected for unknown bits still sounds useful.
For concise output, an RPC interface (and maybe some events) for key transitions on known bits.

I don't think there is a need for storing threshold data in blocks. That can be adequately encoded in the software (or preferably, a signaling configuration file which can be maintained more easily). There should be enough bits to allow deconflicting of proposed deployments among the developer community. 29 parallel proposed change deployments sounds like quite a large number, to me anyway.

"warning: voting on unknown feature reached X%"

If the proposal were to include configurable tallying windows per bit, the percentage (relative to activation) would also be unknown. So such a message could be formulated over the last 100 blocks maybe, or some other fixed default, just to get an idea of the signaling frequency.

I had a conversation with a Core developer today, who suggested to me that perhaps I should rather raise this proposal as a BUIP than attempt to discuss it on the bitcoin-dev mailing list.
I am more than willing to open a BUIP if there is interest in pursuing this topic, after further discussion.

 

[SanchoPanza]

I have published an initial draft of the full specification.

https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki

Review comments are most welcome!

I am specifically most interested if you find something that would result in an incompatibility to existing BIP9.

 

[SanchoPanza]

A link to a proposed configuration file format for versionbit-deployed forks is contained in this posting:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014137.html

Comments welcome here too, and feel free to raise issues on the linked Github.

 

[SanchoPanza]

I have constructed a reference implementation, which I submit as a work-in-progress PR to Bitcoin Unlimited:

https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458

Looking forward to your review and feedback!

Reddit discussion thread:
https://www.reddit.com/r/btc/comments/66oene/reference_implementation_of_generalized/

 

[SanchoPanza]

Submitted to BIP repository to request review and a number assignment:
https://github.com/bitcoin/bips/pull/532

 

[Dustinsoing]

This is a grievous milieu I'm happy I found it I wishes inflict this spot more commonly

https://privnote.com/WtZ6nfv9

login password: ois!EiduR!49

 

[jakabasej4]

This is a grievous milieu I'm happy I found it I wishes inflict this spot more commonly
fantasy miniature war game
https://privnote.com/WtZ6nfv9
Nakiri knives
login password: ois!EiduR!49

thanks

 

[jakabasej4]

Buying cryptocurrency and holding is old news. With copy trading, you can profit from the experience of seasoned traders by copying their moves. Learn the ropes of the market without the stress of making every decision yourself. Click and start copying their trades to earn profits. Interested to know more? Comment below and let's discuss. Remember, investing in cryptocurrencies carries risks, which is why it's always important to do your own research and consult with a financial advisor if needed. C d 1 9 2 2 1 @ g m a i l . c o m Nakiri knives

Thanks for sharing this insight