public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Multi-Stage Merge-Mine Headers Hard-Fork BIP
@ 2016-02-24  5:52 James Hilliard
  2016-02-24 10:58 ` Tier Nolan
  0 siblings, 1 reply; 3+ messages in thread
From: James Hilliard @ 2016-02-24  5:52 UTC (permalink / raw)
  To: bitcoin-dev

https://github.com/bitcoin/bips/pull/340

BIP: ?
Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
Author: James Hilliard <james.hilliard1@gmail.com>
Status: Draft
Type: Standards Track
Created: 2016-02-23

==Abstract==

Use a staged hard fork to implement a headers format change that is
merge mine incompatible along with a timewarp to kill the previous
chain.

==Specification==

We use a block version flag to activate this fork when 3900 out of the
previous 4032 blocks have this the version flag set. This flag locks
in both of the below stages at the same time.

Merge Mine Stage: The initial hard fork is implemented using a merge
mine which requires that the original pre-fork chain be mined with a
generation transaction that creates no new coins in addition to not
containing any transactions. Additionally we have a consensus rule
that requires that ntime be manipulated on the original chain to
artificially increase difficulty and hold back the original chain so
that all non-upgraded clients can never catch up with current time.
The artificial ntime is implemented as a consensus rule for blocks in
the new chain.

Headers Change Stage: This is the final stage of the hard fork where
the header format is made incompatible with merge mining, this is
activated ~50,000 blocks after the Merge Mine Stage and only at the
start of the 2016 block difficulty boundary.

==Motivation==

There are serious issues with pooled mining such as block withhold
attacks that can only be fixed by making major changes to the headers
format.

There are a number of other desirable header format changes that can
only be made in a non-merge mine compatible way.

There is a high risk of there being two viable chains if we don't have
a way to permanently disable the original chain.

==Rationale==

Our solution is to use a two stage hard fork with a single lock in period.

The first stage is designed to kill off the previous chain by holding
back ntime to artificially increase network difficulty on the original
chain to the point where it would be extremely difficult to mine the
2016 blocks needed to trigger a difficulty adjustment. This also makes
it obvious to unupgraded clients that they are not syncing properly
and need to upgrade.

By locking in both stages at the same time we ensure that any clients
merge mining are also locked in for the headers change stage so that
the original chain is dead by the time the headers change takes place.

We timewarp over a year of merge mining to massively increase the
difficulty on the original chain to the point that it would be
incredibly expensive to reduce the difficulty enough that the chain
would be able to get caught up to current time.

==Backward Compatibility==

This hardfork will permanently disable all nodes, both full and light,
which do not explicitly add support for it.
However, their security will not be compromised due to the implementation.
To migrate, all nodes must choose to upgrade, and miners must express
supermajority support.

==Reference Implementation==

TODO


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-02-24 11:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-24  5:52 [bitcoin-dev] Multi-Stage Merge-Mine Headers Hard-Fork BIP James Hilliard
2016-02-24 10:58 ` Tier Nolan
2016-02-24 11:37   ` James Hilliard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox