From: Sancho Panza <sanch0panza@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Cc: "luke_bipeditor@dashjr•org" <luke_bipeditor@dashjr•org>
Subject: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
Date: Mon, 03 Apr 2017 05:06:02 -0400 [thread overview]
Message-ID: <PU5yHaeZtxR5ManpM0q7ZIN1pElEorBfO09u7ZIC-h81mQizYCZ5qNv89Tb2ZLNHbCktmV65q2Xkm1K3UckvVZLOWBMW7-riWYRY4HtFe1A=@protonmail.com> (raw)
[-- 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 --]
next reply other threads:[~2017-04-03 9:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 9:06 Sancho Panza [this message]
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
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='PU5yHaeZtxR5ManpM0q7ZIN1pElEorBfO09u7ZIC-h81mQizYCZ5qNv89Tb2ZLNHbCktmV65q2Xkm1K3UckvVZLOWBMW7-riWYRY4HtFe1A=@protonmail.com' \
--to=sanch0panza@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke_bipeditor@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