<div>¡Hola!<br></div><div><br></div><div>Please find below a proposal [resubmission] for a new informational BIP<br></div><div>&nbsp;provisionally named 'bip-genvbvoting'.<br></div><div><br></div><div>I present it here in rough draft for your esteemed consideration and as<br></div><div>a basis for discussion.<br></div><div><br></div><div>Best regards,<br></div><div>Sancho<br></div><div><br></div><div>--- begin draft of bip-genvbvoting ---<br></div><div><br></div><div>==Preamble==<br></div><div><br></div><div>BIP: ?<br></div><div>Title: Generalized version bits voting<br></div><div>Author: Sancho Panza &lt;<a href="mailto:sanch0panza@protonmail.com">sanch0panza@protonmail.com</a>&gt;<br></div><div>Status: Draft<br></div><div>Type: Informational<br></div><div>Created: 2017-03-29<br></div><div>Replaces: 9<br></div><div>License: CC0-1.0<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GNU-All-Permissive<br></div><div><br></div><div><br></div><div>==Abstract==<br></div><div><br></div><div>This document describes a generalized version bits voting scheme based<br></div><div>on and intended to replace BIP9.<br></div><div><br></div><div>The generalization consists of allowing each version bit to be treated<br></div><div>individually using a configurable percentage threshold and window size,<br></div><div>instead of the fixed 95% (mainnet) and 2016 block window specified in<br></div><div>BIP9.<br></div><div><br></div><div>The state machine and governing parameters (name, bit, starttime, <br></div><div>timeout) remain as is, but additional parameters called 'threshold' and<br></div><div>'windowsize' are added to the per-bit set.<br></div><div><br></div><div>As before, a set of per-chain parameters will exist for the version bits<br></div><div>governed by BIP9.<br></div><div><br></div><div><br></div><div>==Motivation==<br></div><div><br></div><div>The Bitcoin protocol requires a flexible consensus-finding scheme<br></div><div>to ensure that it can adapt to the needs of the market (its users) and<br></div><div>remain competitive as an electronic payment system.<br></div><div><br></div><div>While BIP9 has served the community reasonably well until now, the<br></div><div>author remarks several shortcomings in its approach:<br></div><div><br></div><div>- it limits itself to backward-compatible changes, precluding its<br></div><div>&nbsp; applicability to hard forks<br></div><div><br></div><div>- a fixed 95% threshold is not flexible enough to allow for a 'spectrum<br></div><div>&nbsp; of contentiousness' to be represented<br></div><div>&nbsp; <br></div><div>- the 95% threshold allows small minorities to veto proposed changes,<br></div><div>&nbsp; lead to stagnation (viz. current standoffs)<br></div><div><br></div><div>A more generalized implementation of voting on changes using version bits<br></div><div>can address these issues in a way that can satisfy the needs of both soft<br></div><div>and hard forks, as well as represent varying degrees of contentiousness.<br></div><div><br></div><div><br></div><div>==Specification==<br></div><div><br></div><div>To be elaborated.<br></div><div><br></div><div>It is thought that only cosmetic changes are needed to generalize from<br></div><div>only soft forks to 'soft or hard forks', and to add the additional<br></div><div>per-bit parameters 'threshold' and 'windowsize'<br></div><div><br></div><div>References to fixed values will need to be eliminated and replaced<br></div><div>by respective parameters.<br></div><div><br></div><div>The design of the state machine is envisioned to remain unchanged.<br></div><div><br></div><div><br></div><div>==Implementation==<br></div><div><br></div><div>A reference implementation can be constructed after elaboration of<br></div><div>the specification.<br></div><div><br></div><div><br></div><div>==Copyright==<br></div><div><br></div><div>This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal<br></div><div>and GNU All-Permissive licenses.<br></div><div><br></div><div>--- end draft of bip-genvbvoting ---<br></div>