<div dir="ltr"><div><div><div>You need more detail for it to be a BIP.<br><br></div><div></div><div>New Header<br><br></div><div>new_header.prev = hash of previous header's bitcoin header<br></div><div>new_header.small_nonce = 4 byte nonce<br></div><div>new_header.big_nonce = 8 byte nonce<br><br>new_header.... (Can contain any new fields desired)<br></div><div><br></div><div>Fake Block<br></div><div><br></div><div>block.version = 4<br></div><div>block.prev = new_header.prev<br></div><div>block.merkle = calculate_merkle(coinbase)<br></div><div>block.timestamp = block.getPreviousBlock().median_time_past + 1<br></div><div>block.bits = calculate_bits()<br></div><div>block.nonce = new_header.small_nonce<br></div><div>block.tx_count = 1<br></div><div><br></div><div>Coinbase<br></div><div><br></div><div>coinbase.version = 1<br></div><div>coinbase.tx_in_count = 0<br></div><div>coinbase.tx_out_count = 1<br></div><div>coinbase.tx_out[0].value = 0<br>coinbase.tx_out[0].pk_script = "OP_RETURN"<br></div><div><br></div></div>This is a "nuclear option" attack that knocks out the main chain. The median time past will increase very slowly. It only needs to increase by 1 every 6th blocks. That gives an increase of 336 seconds for every difficulty update. This will cap the update rate, so give an increase of 4X every doubling.<br><br></div><div>The new headers will end up not meeting the difficulty, so they will presumably just repeat the last header?<br></div><div><br></div><div>If the bitcoin chain stays at constant difficulty, then each quadrupling will take more time.<br><br></div><div>After 2 weeks: 4XDiff (2 weeks per diff period)<br></div><div>After 10 weeks: 16XDiff (8 weeks per diff period)<br></div><div>After 42 weeks: 256XDiff (32 weeks per diff period)<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://github.com/bitcoin/bips/pull/340" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/pull/340</a><br>
<br>
BIP: ?<br>
Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork<br>
Author: James Hilliard <<a href="mailto:james.hilliard1@gmail.com">james.hilliard1@gmail.com</a>><br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2016-02-23<br>
<br>
==Abstract==<br>
<br>
Use a staged hard fork to implement a headers format change that is<br>
merge mine incompatible along with a timewarp to kill the previous<br>
chain.<br>
<br>
==Specification==<br>
<br>
We use a block version flag to activate this fork when 3900 out of the<br>
previous 4032 blocks have this the version flag set. This flag locks<br>
in both of the below stages at the same time.<br>
<br>
Merge Mine Stage: The initial hard fork is implemented using a merge<br>
mine which requires that the original pre-fork chain be mined with a<br>
generation transaction that creates no new coins in addition to not<br>
containing any transactions. Additionally we have a consensus rule<br>
that requires that ntime be manipulated on the original chain to<br>
artificially increase difficulty and hold back the original chain so<br>
that all non-upgraded clients can never catch up with current time.<br>
The artificial ntime is implemented as a consensus rule for blocks in<br>
the new chain.<br>
<br>
Headers Change Stage: This is the final stage of the hard fork where<br>
the header format is made incompatible with merge mining, this is<br>
activated ~50,000 blocks after the Merge Mine Stage and only at the<br>
start of the 2016 block difficulty boundary.<br>
<br>
==Motivation==<br>
<br>
There are serious issues with pooled mining such as block withhold<br>
attacks that can only be fixed by making major changes to the headers<br>
format.<br>
<br>
There are a number of other desirable header format changes that can<br>
only be made in a non-merge mine compatible way.<br>
<br>
There is a high risk of there being two viable chains if we don't have<br>
a way to permanently disable the original chain.<br>
<br>
==Rationale==<br>
<br>
Our solution is to use a two stage hard fork with a single lock in period.<br>
<br>
The first stage is designed to kill off the previous chain by holding<br>
back ntime to artificially increase network difficulty on the original<br>
chain to the point where it would be extremely difficult to mine the<br>
2016 blocks needed to trigger a difficulty adjustment. This also makes<br>
it obvious to unupgraded clients that they are not syncing properly<br>
and need to upgrade.<br>
<br>
By locking in both stages at the same time we ensure that any clients<br>
merge mining are also locked in for the headers change stage so that<br>
the original chain is dead by the time the headers change takes place.<br>
<br>
We timewarp over a year of merge mining to massively increase the<br>
difficulty on the original chain to the point that it would be<br>
incredibly expensive to reduce the difficulty enough that the chain<br>
would be able to get caught up to current time.<br>
<br>
==Backward Compatibility==<br>
<br>
This hardfork will permanently disable all nodes, both full and light,<br>
which do not explicitly add support for it.<br>
However, their security will not be compromised due to the implementation.<br>
To migrate, all nodes must choose to upgrade, and miners must express<br>
supermajority support.<br>
<br>
==Reference Implementation==<br>
<br>
TODO<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>