Sancho Panza via bitcoin-dev

2017-04-03 09:06:02 UTC

¡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 <***@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 ---

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 <***@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 ---