Why Nostr? What is Njump?
2023-06-07 17:59:00
in reply to

Sancho Panza [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-03 📝 Original message:¡Hola! Please find below ...

📅 Original date posted:2017-04-03
📝 Original message:¡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 at 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 ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170403/fe041087/attachment.html>;
Author Public Key
npub1489wmpkjrv7vvdtv9z0d9t4jcgvm78tts5j4ex9fxh2nksmhausqnvlgku