Skip to content

Instantly share code, notes, and snippets.

@ajtowns
Last active July 11, 2017 22:55
Show Gist options
  • Save ajtowns/914cf2309822bff357cda4ab3f48a966 to your computer and use it in GitHub Desktop.
Save ajtowns/914cf2309822bff357cda4ab3f48a966 to your computer and use it in GitHub Desktop.
hard fork proposals guide/timeline
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
------------
...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment