Hello Bitcoin Protocol Discussion Mailing List,
The binary presented by "Lock on Timeout" or LOT; is inherently divisive.
Hence, after taking some time to meditate; please consider the following as an
overview, and a possible solution:
---
The lingering bad-taste from the drama surrounding the activation of SegWit
(Using, BIP9, BIP91, and BIP148) lead to the development of the very reasonable
activation protocol: BIP8.
The BIP8 protocol includes an optional feature, called "Lock on Timeout", that
is essentially a technically improved version of the flag-day activation
proposed in BIP148.
Many in the Bitcoin Community find the use of blind flag-day activations
needlessly divisive and dangerous. In particular:
# A flag-day activation imposes itself on the network, without consideration of
the deployment concerns that the miners may have when implementing the network
upgrade on their unique infrastructure; and risks decreasing the good-will
between users and miners.
# A flag-day activation proceeds, even if, before activation, a critical bug in
the design is found in the process of doing the miner software upgrades. There
is no back-out path for the community and miners alike.
# A flag-day activation can have wide-reaching damaging effects if activated
with only a small amount of the miners in active support.
Others in the Bitcoin Community, however do not find these concerns weighty
enough to override the certainty and reliability that a flag-day activation
provides. Hence, this binary-option of using a flag-day activation, or not, is
always going to be divisive for the community.
---
The activation procedure for new consensus rules should be empowering for both
the users and the miners alike. It should respect the reality that the proposed
network upgrade (Taproot: BIP340, 341, and 342) has already completed its
consensus building process within the Bitcoin Community.
This proposal decides against using a blind flag-day activation; instead it
uses a more nuanced approach. It allows a majority of the miners to block
deployment (if they maintain consensus to postpone the deployment for at least
half of the activation period) and it also allows a minority of the miners to
temporarily delay the deployment.
Signaling "readiness" for a consensus change has been confused with implying
political support of this change. This proposal addresses this confusion by
inverting the meaning of the "Version Bit". Now miners will signal they are
"not-ready", instead of the previously used behavior of signaling when they are
"ready".
After a lengthy pre-starting period of 6 months, an upgrade may be further
delayed, or be postponed by miners signaling. In the default case, where the
vast majority of the miners have successfully upgraded within the pre-starting
period, the first 2016 block period will lock-in the upgrade without any delay
or postponement.
This is far more accurately resolving the primary worry of both the Bitcoin
users and Bitcoin miners, that is to allow an upgrade to proceed too-quickly
while some lag behind with difficulties. Miners who are having difficulties can
explicitly notify the community through signaling their lack of readiness, and
thus triggering a delay, or entirely postponing the deployment.
---
Please find following a rough, and incomplete, draft of the proposal written in
BIP form. If the community finds this approach conceptually sound, this BIP
will be completed to a high-standard and hopefully be considered to be used for
the activation of Taproot.
Lovely Regards,
Efaula.
BIP: scheduled-activation-delay
Title: Scheduled Activation with Potential Miner-Signaled Delay
Author: Efaula Prafbodous
Created: 2021-02-26
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies an alternative to [[bip-0008.mediawiki|BIP8]], where
the signalling intention is inverted, and the activation may be delayed a
limited number of times, or postponed (and ultimately fail deployment).
Unlike previous proposals, where miners signaled that they are '''ready''' for
the consensus change. This proposal has miners signal that they are
'''not-ready''', and proceeds with the upgrade in the default case.
The core assumption within this proposal is that it is far easier and faster
for a miner to adjust the signaling within the blocks they produce, than to
certify and validate new software that enforces advanced new consensus rules.
Hence, miners will quickly signal they are '''not-ready''', and once upgraded;
they will remove this signal; allowing the upgrade to proceed.
The authors of this proposal suggest this is more appropriate, as it directly
focuses on the core issue: allowing miners to delay the activation of new
consensus rules until they have solved their technological and validation
issues.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
==Motivation==
Flag-day activations are the simplest way to introduce consensus changes to the
Bitcoin Network. However, without overwhelming miner support, a flag-day
activation can cause a damaging chain split to occur.
Since [[bip-0016.mediawiki|BIP16]], the Bitcoin Community has used
miner-signaling (where miners place a specific flag in the blocks they produce)
to trigger the activation of a consensus change. This has worked to assure that
the network remains in good consensus throughout the activation period.
However, in the case of [[bip-0141.mediawiki|BIP141]], this activation process
of signaling '''readiness''' resulted in confusion between signaling readiness
of the miner software; and signaling political support of the consensus change.
This lead to much drama; and a strong movement within the users to move back to
using flag-day style activations.
In this proposal we address this issue by requiring miners to explicitly signal
that they are '''not-ready''' for the proposed network upgrade. This removes a
great amount of the political confusion, as the default behavior is now
ambiguous:
# A miner chooses to enforce the new consensus rules.
# A miner may choose not to upgrade; and not enforce the new consensus rules.
In a soft-fork this behavior is acceptable; except for the loss of funds and
disruption caused by mining on-top of other invalid blocks without detection.
In the case of signaling '''not-ready''', the miner is simply referencing the
technological reality of their lack-of-readiness. This allows the Bitcoin
Community to focus on the miners who have signaled that they are not-yet-ready,
and build support with them. Thus, helping the miners implement the
technological aspects of this network upgrade.
==Specification==
This proposal uses 2016 block intervals; using the same set of intervals as
used for difficulty adjustment calculations.
# The '''start_height''' should be 13 x 2016 block intervals (approximately six
months) after the release of the software that implements this upgrade.
# The '''stop_height''' should be 26 x 2016 block intervals (approximately one
year) after the '''start_height'''.
--
There will be exactly 26 intervals, to attempt activation:
'''LOCKED_IN''' becomes activated IF:
# Less than 126 blocks signal '''not-ready'''. In any interval. OR
# Less than 1008 blocks, but 126 or more blocks signal '''not-ready'''. For a
total of 14 intervals.
'''FAILED''', i.e. activation failed IF:
# 1008 or more blocks signal '''not-ready'''. For a total of 13 intervals. AND
# 126 or more blocks signal '''not-ready'''. In all remaining intervals.
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0
Universal.
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
