📅 Original date posted:2016-02-24
📝 Original message:You need more detail for it to be a BIP.
New Header
new_header.prev = hash of previous header's bitcoin header
new_header.small_nonce = 4 byte nonce
new_header.big_nonce = 8 byte nonce
new_header.... (Can contain any new fields desired)
Fake Block
block.version = 4
block.prev = new_header.prev
block.merkle = calculate_merkle(coinbase)
block.timestamp = block.getPreviousBlock().median_time_past + 1
block.bits = calculate_bits()
block.nonce = new_header.small_nonce
block.tx_count = 1
Coinbase
coinbase.version = 1
coinbase.tx_in_count = 0
coinbase.tx_out_count = 1
coinbase.tx_out[0].value = 0
coinbase.tx_out[0].pk_script = "OP_RETURN"
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.
The new headers will end up not meeting the difficulty, so they will
presumably just repeat the last header?
If the bitcoin chain stays at constant difficulty, then each quadrupling
will take more time.
After 2 weeks: 4XDiff (2 weeks per diff period)
After 10 weeks: 16XDiff (8 weeks per diff period)
After 42 weeks: 256XDiff (32 weeks per diff period)
On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> https://github.com/bitcoin/bips/pull/340
>
> BIP: ?
> Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
> Author: James Hilliard <james.hilliard1 at 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160224/a97dd885/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 17:49:14
in reply to nevent1q…z0j7
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 17:49:14Event JSON
{
"id": "30c966f2d618400c008a487551a15f67a0d823fce6a4ff54f25ae5306dbe7a4a",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686160154,
"kind": 1,
"tags": [
[
"e",
"e16f57bf73363668305a2848aa12b28440f8b2d57a3787b96a0ba30c05ca2da5",
"",
"root"
],
[
"e",
"c196c52ae9296535deb1fe90e49a29a5fc29fa18aa2808b0413ed8f1f957aa18",
"",
"reply"
],
[
"p",
"78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394"
]
],
"content": "📅 Original date posted:2016-02-24\n📝 Original message:You need more detail for it to be a BIP.\n\nNew Header\n\nnew_header.prev = hash of previous header's bitcoin header\nnew_header.small_nonce = 4 byte nonce\nnew_header.big_nonce = 8 byte nonce\n\nnew_header.... (Can contain any new fields desired)\n\nFake Block\n\nblock.version = 4\nblock.prev = new_header.prev\nblock.merkle = calculate_merkle(coinbase)\nblock.timestamp = block.getPreviousBlock().median_time_past + 1\nblock.bits = calculate_bits()\nblock.nonce = new_header.small_nonce\nblock.tx_count = 1\n\nCoinbase\n\ncoinbase.version = 1\ncoinbase.tx_in_count = 0\ncoinbase.tx_out_count = 1\ncoinbase.tx_out[0].value = 0\ncoinbase.tx_out[0].pk_script = \"OP_RETURN\"\n\nThis is a \"nuclear option\" attack that knocks out the main chain. The\nmedian time past will increase very slowly. It only needs to increase by 1\nevery 6th blocks. That gives an increase of 336 seconds for every\ndifficulty update. This will cap the update rate, so give an increase of\n4X every doubling.\n\nThe new headers will end up not meeting the difficulty, so they will\npresumably just repeat the last header?\n\nIf the bitcoin chain stays at constant difficulty, then each quadrupling\nwill take more time.\n\nAfter 2 weeks: 4XDiff (2 weeks per diff period)\nAfter 10 weeks: 16XDiff (8 weeks per diff period)\nAfter 42 weeks: 256XDiff (32 weeks per diff period)\n\n\nOn Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e https://github.com/bitcoin/bips/pull/340\n\u003e\n\u003e BIP: ?\n\u003e Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork\n\u003e Author: James Hilliard \u003cjames.hilliard1 at gmail.com\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2016-02-23\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e Use a staged hard fork to implement a headers format change that is\n\u003e merge mine incompatible along with a timewarp to kill the previous\n\u003e chain.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e We use a block version flag to activate this fork when 3900 out of the\n\u003e previous 4032 blocks have this the version flag set. This flag locks\n\u003e in both of the below stages at the same time.\n\u003e\n\u003e Merge Mine Stage: The initial hard fork is implemented using a merge\n\u003e mine which requires that the original pre-fork chain be mined with a\n\u003e generation transaction that creates no new coins in addition to not\n\u003e containing any transactions. Additionally we have a consensus rule\n\u003e that requires that ntime be manipulated on the original chain to\n\u003e artificially increase difficulty and hold back the original chain so\n\u003e that all non-upgraded clients can never catch up with current time.\n\u003e The artificial ntime is implemented as a consensus rule for blocks in\n\u003e the new chain.\n\u003e\n\u003e Headers Change Stage: This is the final stage of the hard fork where\n\u003e the header format is made incompatible with merge mining, this is\n\u003e activated ~50,000 blocks after the Merge Mine Stage and only at the\n\u003e start of the 2016 block difficulty boundary.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e There are serious issues with pooled mining such as block withhold\n\u003e attacks that can only be fixed by making major changes to the headers\n\u003e format.\n\u003e\n\u003e There are a number of other desirable header format changes that can\n\u003e only be made in a non-merge mine compatible way.\n\u003e\n\u003e There is a high risk of there being two viable chains if we don't have\n\u003e a way to permanently disable the original chain.\n\u003e\n\u003e ==Rationale==\n\u003e\n\u003e Our solution is to use a two stage hard fork with a single lock in period.\n\u003e\n\u003e The first stage is designed to kill off the previous chain by holding\n\u003e back ntime to artificially increase network difficulty on the original\n\u003e chain to the point where it would be extremely difficult to mine the\n\u003e 2016 blocks needed to trigger a difficulty adjustment. This also makes\n\u003e it obvious to unupgraded clients that they are not syncing properly\n\u003e and need to upgrade.\n\u003e\n\u003e By locking in both stages at the same time we ensure that any clients\n\u003e merge mining are also locked in for the headers change stage so that\n\u003e the original chain is dead by the time the headers change takes place.\n\u003e\n\u003e We timewarp over a year of merge mining to massively increase the\n\u003e difficulty on the original chain to the point that it would be\n\u003e incredibly expensive to reduce the difficulty enough that the chain\n\u003e would be able to get caught up to current time.\n\u003e\n\u003e ==Backward Compatibility==\n\u003e\n\u003e This hardfork will permanently disable all nodes, both full and light,\n\u003e which do not explicitly add support for it.\n\u003e However, their security will not be compromised due to the implementation.\n\u003e To migrate, all nodes must choose to upgrade, and miners must express\n\u003e supermajority support.\n\u003e\n\u003e ==Reference Implementation==\n\u003e\n\u003e TODO\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160224/a97dd885/attachment.html\u003e",
"sig": "0f25cfa5358e15a29f44107c19f3ad0c6a8bbc5c15b451144a941601136a351910eaef1db9a6fad7d5c98f4b83634dd187e10515552596cc0b6cb82ecd92e83c"
}