public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
@ 2017-04-03  9:06 Sancho Panza
  2017-04-04 11:16 ` Tom Zander
  2017-04-04 18:01 ` Luke Dashjr
  0 siblings, 2 replies; 9+ messages in thread
From: Sancho Panza @ 2017-04-03  9:06 UTC (permalink / raw)
  To: bitcoin-dev; +Cc: luke_bipeditor

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 2625 bytes --]

¡Hola!

Please find below a proposal [resubmission] 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
Replaces: 9
License: CC0-1.0
GNU-All-Permissive

==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,
lead 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 ---

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-04-08 21:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2017-04-05 10:08   ` Tom Zander
2017-04-05 14:09     ` Thomas Kerin
2017-04-08 21:58       ` Sancho Panza

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox