Soft Fork

Basics

• A soft fork is a change to a blockchain protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a soft fork is backward-compatible. This kind of fork requires only a majority of the miners upgrading to enforce the new rules.
• New transaction types can often be added as soft forks, requiring only that the participants (sender and receiver) and miners understand the new transaction type. This is done by having the new transaction appear to older clients as a "pay-to-anybody" transaction (of a special form), and getting the miners to agree to reject blocks including these transaction unless the transaction validates under the new rules. This is how P2SH was added to Bitcoin.

Discussion of soft fork activation mechanisms in Bitcoin

• From Bitcoin Optech #80 (15-1-2020):

"Matt Corallo started a discussion on the Bitcoin-Dev mailing list about what attributes are desirable in a soft fork activation method and submitted a proposal for a mechanism that contains those attributes. In short, the attributes are:

1. The ability to abort if a serious objection to the proposed consensus rules changes is encountered
2. The allocation of enough time after the release of updated software to ensure that most economic nodes are upgraded to enforce those rules
3. The expectation that the network hash rate will be roughly the same before and after the change, as well as during any transition
4. The prevention, as much as possible, of the creation of blocks that are invalid under the new rules, which could lead to false confirmations in non-upgraded nodes and SPV clients
5. The assurance that the abort mechanisms can’t be misused by griefers or partisans to withhold a widely desired upgrade with no known problems

Corallo believes that a well-crafted soft fork using the BIP9 versionbits activation mechanism and surrounded with good community engagement fulfills the first four criteria—but not the fifth. Alternatively, a BIP8 flag-day soft fork fulfills the fifth criteria but encounters challenges fulfilling the other four criteria. Corallo also worries that using BIP8 from the start of a soft fork deployment gives the impression that the developers of node software get to decide the rules of the system.

As an alternative to either BIP9 or BIP8 alone, Corallo proposes a three-step process: use BIP9 to allow a proposal to be activated within a one-year window; pause for a six-month discussion period if the proposal is not activated; and—if it’s clear that the community still wants the proposal activated—force activation using a BIP8 flag day set to two years in the future (with faster activation possible using versionbits signaling). Node software can prepare for this maximum 42-month process by including, even in its initial versions, a configuration option that users can manually enable to enforce the BIP8 flag day if necessary. If the first 18 months of the activation period passes without activation (but also without any blocking problems being discovered), new releases can enable this option by default for the remaining 24 months of the activation period.

In the responses to the post, Jorge Timón and Luke Dashjr both proposed that any BIP8-like mechanism use mandatory versionbits signaling leading up to the flag day (similar to how BIP148 proposed to activate segwit); Corallo notes that this conflicts with the third and fourth goals. Jeremy Rubin provides a quick analysis of his previous spork proposal (see Newsletter #32) in the context of the five goals. Anthony Towns provides lucid commentary on several aspects of Corallo’s proposal and Timón’s response.

No clear conclusion was reached in the thread and we expect to see continued discussion."