hard fork proposals guide/timeline

BIP-hardfork-changes.txt

Hard-forking Changes to Bitcoin Core
====================================

A hard-fork change to the Bitcoin consensus validation rules is one that
treats previously invalid blocks as valid. (Such a change may additionally
include soft-forking changes, treating previously valid blocks as invalid)

In order to safely deploy a change of this type, the following process
should be followed:

 * An informal but clear description of this changes to be made
   should be presented to the public in a technical forum. This
   description should be sufficient for technical analysis to be begun
   and experimental coding to take place.

   The results of this technical analysis and any experiments should
   be incorporated into the proposal.

   This phase is expected to take at least six months of real time.

 * A draft formal proposal and an initial implementation should be
   published, via the BIP process and as a pull request following the
   CONTRIBUTING guidelines. Wide scale testing should be untertaken at
   this point, with unit and functional tests included in the example
   implementation, integration tests against other bitcoin software,
   and the use of one or more feature specific testnets.

   It is expected significant technical peer review will be undertaken
   during this phase, and both the proposal and implementation will
   likely require substantial revision as a result.

   As changes are adopted to address concerns raised in review, it is
   expected that the proposal will solidify and the implementation will
   mature to the point it is acceptable for inclusion in the next update
   of Bitcoin core. This phase concludes when the change is included in
   the current Bitcoin core release, not just the master branch.

   This phase is expected to take at least three months of real time.

 * Rule changes may be included in Bitcoin core without being active;
   and may be activated by a variety of mechanisms. Example mechanisms
   include:

     - Activation by software update at a particular block height
       or time
     - Activation by miner signalling
     - Activation by transaction signalling (weighted by fee or btc-days
       destroyed)

   Each of these mechanisms require some coordination time -- whether
   that be simply time to deploy updated software or time for enough
   blocks or transactions that signal support to be published.

   This phase will be determined as part of the proposal and
   implementation, and is expected to require a minimum of three to nine
   months of real time.

 * Finally, because hard fork changes require validating software to be
   upgraded in order to follow the new chain, time must be allowed for
   these upgrades to take place. Deployment timelines should take into
   consideration that upgrades may require significant effort on the part
   of users: eg,

     - Business may wish to undertake additional testing of releases
       before deploying them, beyond the functional and unit tests
       included in the code base

     - Applications built on bitcoin may need additional development to
       correctly cope with any changed behaviour or assumptions in the
       new release

     - Because of the (hopefully low) risk of a chain split cannot
       be reduce to zero when a hard fork is undertaken, businesses
       may need to spend additional effort on contingency plans for
       this scenario.

   Further, in order to minimise wasted effort due to uncertainty,
   some businesses may not begin these activities until after the
   changes have been locked in.
   
   Rough timeframes for updates:
     - Compatibility review, integration and deployment of software changes: six months
     - Compulsory updates to light wallets, and deployment to users: twelve months
     - Hardware updates to account for mining incompatability: two years

   As a result, a further grace period is required between consensus
   on the new rules being achieved and validation actually switching to
   the new rules. This phase is expected to last between six months and
   two years.

Timeline Summary
----------------

The minimum timeline is thus:

 * Concept: 6 months
 * Proposal and implementation review: 3 months
 * Activation: 3 to 9 months
 * Grace: 6 months to 2 years

The minimum total timeline for responsibly deploying a hard-fork change
to consensus rules is thus 18 months to 3.5 years.

Note that this is the *minimum* viable path for safe deployment of
hard-forking changes. This assumes full engagement with the technical
community, in public, at all times. If proposals or code are kept private
for a time, or implementors are not responsive to peer review or are not
willing and able to adapt the proposal and implementation to concerns
raised, then additional delays will occur. This also does not take into
account the liklihood of implementation bugs causing delays, or of delays
due to unexpected events arising and taking priority.

Factors to Address
------------------

Proposals for a hard-fork should explicitly consider the following factors:

 * Establishing consensus for activation of the changes:

     - How will it be established that the proposed changes should
       be deployed?

 * Grace period:

     - How long is the grace period expected to be, and what precisely
       will trigger the end of the grace period?

     - Will delays in establishing consensus for activation change the
       length of the grace period?

 * Effect on light ("SPV") clients:

     - Will light clients require updates to make correct use of the
       new features?

 * Effect on miners:

     - How will pool software need to be updated?

     - Will existing mining hardware be compatible with the changes? If
       not, the grace period schedule should perhaps be lengthened to
       allow for development and distribution of a new generation miners
       compatible with the new system.

 * Peer-to-peer network partitions:

     - How will old clients behave when presented with blocks conforming to
       the new rules? In many possible hard-fork implementations,
       this will result in a network partition, where old nodes do not
       recognise the new blocks and ban updated peers that pass them on
       as valid.

     - In the event of a partition, what proportion of the network needs
       to have upgraded to the new rules in order for the upgraded nodes
       to be strongly connected?

 * Scenarios related to a chain split:

   Anyone who does not upgrade to the new software will be unable to
   follow the new chain becaue of the nature of hard-forks. This raises
   some straightforward questions that should be addressed:

     - To what degree will it be possible/practical for a legacy chain
       to continue progressing after the hard-fork rules are active?

     - If a split occurs, and at some point the legacy chain has a majority
       of hashpower, to what degree is it possible that upgraded noded
       will reorg to the legacy chain?

     - If a split occurs, can light clients easily differentiate the
       two chains?

     - If a split occurs, what mechanisms are supported to limit
       transactions to one chain or the other?

Irresponsible Changes
---------------------

Implementations that shortcut this process are, of course, entirely
possible in the real world.

In order to ensure the bitcoin software and protocol are reliable and
robust, Bitcoin Core maintainers and developers are recommended not
to accept or endorse proposals, implementations or pull requests that
shortcut this process.

In order to ensure that the bitcoin industry and ecosystem remains
reliable, and to enhance trust in the bitcoin brand, it is recommended
that any hard-fork proposal or implementation that shortcuts this process
be called and treated as an altcoin, rather than an upgrade to bitcoin.

Updates to this document
------------------------

Some of the recommendations in this document may need to change over
time. For example, it may becomes clear that some time estimates are
too optimistic, or more experience or better techniques may allows high
quality code to be developed and reviewed more quickly. Additionally,
there may be additional aspects that hard-fork proposals should explicitly
cover, or it may become clear that there are standard best-practices
answers to some issues, that all proposals should simply adopt.

Developers and industry participants who are willing to support the
reliability and robustness of the bitcoin software and ecosystem by
following these recommendations are asked to endorse this document below.

Endorsements
------------

 ...