Add case study: BIP110 (Reduced Data Temporary Softfork) - #81
Conversation
|
|
||
| The claimed temporary nature of the soft fork is highly contested. Critics argue that consensus rules cannot meaningfully bind future behavior, and that any node that continues enforcing past expiry will treat the reversion as a rule-loosening event (a hard fork from its perspective). Proponents claimed that the expiry is encoded as part of the BIP110 soft fork, so enforcing nodes can relax the rules in lockstep in a manner that is not a hard fork. | ||
|
|
||
| The activation mechanism, implemented in a fork of Bitcoin Knots and later shipped in Bitcoin Knots [^35] combines features of BIP8 and BIP9. Miners signal via BIP9-style version bits (bit 4), but there is no timeout and no FAILED state; instead a BIP8-like max_activation_height guarantees activation (for enforcing nodes only). Should the threshold not be reached earlier, mandatory signaling is enforced from block 961,632 to 963,647, during which enforcing nodes reject non-signaling blocks. |
There was a problem hiding this comment.
is it worthwhile to mention consensusrules=rdts in bitcoin.conf being an explicit confirmation?
|
|
||
| The activation mechanism, implemented in a fork of Bitcoin Knots and later shipped in Bitcoin Knots [^35] combines features of BIP8 and BIP9. Miners signal via BIP9-style version bits (bit 4), but there is no timeout and no FAILED state; instead a BIP8-like max_activation_height guarantees activation (for enforcing nodes only). Should the threshold not be reached earlier, mandatory signaling is enforced from block 961,632 to 963,647, during which enforcing nodes reject non-signaling blocks. | ||
|
|
||
| Unlike standard BIP9's 95% threshold, BIP110 requires only 55% (1,109 of 2,016 blocks). The authors stated rationale is that rejecting data storage is "a matter of urgency" and that a temporary, expiring soft fork justifies a lower bar.[^36] This threshold measures miner signaling only, which as mentioned previously can be spoofed. This would leave enforcing hashrate in the minority at the moment enforcement begins. |
There was a problem hiding this comment.
it can be viewed that the 55% threshold if hit is a technical simple majority, more precision for what is "enforcing"?
|
|
||
| The claimed temporary nature of the soft fork is highly contested. Critics argue that consensus rules cannot meaningfully bind future behavior, and that any node that continues enforcing past expiry will treat the reversion as a rule-loosening event (a hard fork from its perspective). Proponents claimed that the expiry is encoded as part of the BIP110 soft fork, so enforcing nodes can relax the rules in lockstep in a manner that is not a hard fork. | ||
|
|
||
| The activation mechanism, implemented in a fork of Bitcoin Knots and later shipped in Bitcoin Knots [^35] combines features of BIP8 and BIP9. Miners signal via BIP9-style version bits (bit 4), but there is no timeout and no FAILED state; instead a BIP8-like max_activation_height guarantees activation (for enforcing nodes only). Should the threshold not be reached earlier, mandatory signaling is enforced from block 961,632 to 963,647, during which enforcing nodes reject non-signaling blocks. |
There was a problem hiding this comment.
is this accurate?
The activation mechanism, initially implemented in a fork of Bitcoin Knots and later included (subject to explicit user confirmation) in Bitcoin Knots, modifies BIP9 with BIP8-like height-based forced activation. Miners signal using BIP9 version bit 4. The deployment uses NO_TIMEOUT and therefore cannot enter FAILED, instead, max_activation_height forces activation on any advancing chain accepted by enforcing nodes. If the threshold has not produced earlier lock-in, those nodes require valid version-bit-4 signaling in every block from heights 961,632 through 963,647, rejecting non-signaling blocks regardless of whether their transactions would satisfy the eventual reduced-data rules. The deployment then enters LOCKED_IN at 963,648 and ACTIVE at 965,664.
|
|
||
| In late 2025 a UASF was proposed which was assigned BIP110 in December 2025. The aim of the UASF was to "temporarily limit the size of data fields at the consensus level" in order to correct what the author described as "distorted incentives caused by standardizing support for arbitrary data".[^34] The soft fork rules invalidate transactions with several data-carrying constructions for 52,416 blocks (roughly one year). UTXOs created before activation are exempt, and once the deployment expires all UTXOs are intended to be unrestricted. At the time of writing, the outcome is unresolved, however miner signaling remains far below threshold ahead of the mandatory signaling window. | ||
|
|
||
| The claimed temporary nature of the soft fork is highly contested. Critics argue that consensus rules cannot meaningfully bind future behavior, and that any node that continues enforcing past expiry will treat the reversion as a rule-loosening event (a hard fork from its perspective). Proponents claimed that the expiry is encoded as part of the BIP110 soft fork, so enforcing nodes can relax the rules in lockstep in a manner that is not a hard fork. |
There was a problem hiding this comment.
footnotes here would help, one for the critics, one for the proponents
|
|
||
| Proponents have cited this to argue that enforcing BIP110 is the safer choice for miners and node operators, but the argument inverts when enforcing hashrate is a minority. The enforcing chain is then expected to remain the less-work chain, non-enforcing miners face little expected reorg risk from it, and enforcing nodes, which reject the most-work chain as invalid, fork themselves onto a low-hashrate minority chain, producing a persistent split rather than a resolution by work. | ||
|
|
||
| A BIP110 Fork Simulator was developed which explains the potential fork points, and models this fork race under configurable hashrate assumptions.[^37] |
There was a problem hiding this comment.
do you want to also mention the other stakeholder types that are part of the simulation?
|
thank you for putting this together! i had a chance to read through it, overall seems like a great addition to the paper! just wanted the language to be a bit more precise around the stages of the activation mechanism, but overall great addition |
|
will see if @moneyball and @jaybeddict1 have a chance to weigh in this week as well |
|
great to see this case study, have't read yet. suggestion: consider hosting case studies in a separate location than bcap/bcap@main. perhaps they can be hosted, say, in a separate case studies repo or even just a separate branch? Rationale:
That said, the above rationale might have other solutions too, so this is a just a soft suggestion. |
|
Given how close we are to mandatory signalling starting I think it makes sense to wait until the dust settles at this point, after which I will update with more information and incorporate the suggested changes. |
3 participants
No description provided.