📅 Original date posted:2016-02-04
📝 Original message:https://github.com/bitcoin/bips/pull/317
ABSTRACT
This document specifies a proposed change to the semantics of the sign
bit of the "version" field in Bitcoin block headers, as a mechanism to
indicate a hardfork is deployed. It alleviates certain risks related to
a hardfork by introducing an explicit "point of no return" in the
blockchain. This is a general mechanism which should be employed by any
planned hardfork in the future.
[1]MOTIVATION
Hardforks in Bitcoin are usually considered as difficult and risky,
because:
* Hardforks require not only support of miners, but also, most
importantly, supermajority support of the Bitcoin economy. As a result,
softfork deployment mechanisms described in BIP 34 [2] or BIP 9 [3] are
not enough for introducing hardforks safely.
* Full nodes and SPV nodes following original consensus rules may not
be aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens.
* In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may unexpectedly
reorg back to the original chain if it grows faster than the new one.
People may find their confirmed transactions becoming unconfirmed and
lose money.
The first issue involves soliciting support for a hardfork proposal,
which is more a political topic than a technical one. This proposal aims
at alleviating the risks related to the second and third issues. It
should be employed by any planned hardfork in the future.
[4]DEFINITIONS
See BIP99 [5]
[6]SPECIFICATION
HARDFORK BIT The sign bit in nVersion is defined as the hardfork bit.
Currently, blocks with this header bit setting to 1 are invalid, since
BIP65 [7] interprets nVersion as a signed number and requires it to be ≥
4. Among the 640 bits in the block header, this is the only one which is
fixed and serves no purpose, and therefore the best way to indicate the
deployment of a hardfork.
FLAG BLOCK Any planned hardfork must have one and only one flag block
which is the "point of no return". To ensure monotonicity, flag block
should be determined by block height, or as the first block with
GetMedianTimePast() greater than a threshold. Other mechanisms could be
difficult for SPV nodes to follow. The height/time threshold could be a
predetermined value or relative to other events (e.g. 10000 blocks / 100
days after 95% of miner support). The exact mechanism is out of the
scope of this BIP. No matter what mechanism is used, the threshold is
consensus critical. It must be publicly verifiable with only blockchain
data, and preferably SPV-friendly (i.e. verifiable with block headers
only, without downloading any transaction).
Flag block is constructed in a way that nodes with the original
consensus rules must reject. On the other hand, nodes with the new
consensus rules must reject a block if it is not a flag block while it
is supposed to be. To achieve these goals, the flag block must
* have the hardfork bit setting to 1, and
* follow any other rules required by the hardfork
If these conditions are not fully satisfied, upgraded nodes shall reject
the block.
The hardfork bit must be turned off in the successors of the flag block,
until the deployment of the next hardfork.
Although a hardfork is officially deployed when flag block is generated,
the exact behavioural change is out of the scope of this BIP. For
example, a hardfork may not be fully active until certain time after the
flag block.
CONCURRENT HARDFORK PROPOSALS To avoid confusion and unexpected
behaviour, a flag block should normally signify the deployment of only
one hardfork. Therefore, a hardfork proposal has to make sure that its
flag block threshold is not clashing with other ongoing hardfork
proposals.
In the case that the version bits mechanism is used in deploying a
hardfork, height of the flag block should take a value of32N + B, where
N is a positive integer and B is the position of bit B defined in BIP9
[8]. This guarantees that no clash may happen with another hardfork
proposal using BIP9.
UNCONTROVERSIAL SUBTLE HARDFORKS Hardforks may sometimes be totally
uncontroversial and make barely noticeable change (BIP50 [9], for
example). In such cases, the use of hardfork bit may not be needed as it
may cause unnecessary disruption. The risk and benefit should be
evaluated case-by-case.
AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
found on the network, full nodes and SPV nodes should alert their users
and/or stop accepting/sending transactions. It should be noted that the
warning system could become a denial-of-service vector if the attacker
is willing to give up the block reward. Therefore, the warning may be
issued only if a few blocks are built on top of the flag block in a
reasonable time frame. This will in turn increase the risk in case of a
real planned hardfork so it is up to the wallet programmers to decide
the optimal strategy. Human warning system (e.g. the emergency alert
system in Bitcoin Core) could fill the gap.
[10]COMPATIBILITY
As a mechanism to indicate hardfork deployment, this BIP breaks backward
compatibility intentionally. However, without further changes in the
block header format, full nodes and SPV nodes could still verify the
Proof-of-Work of a flag block and its successors.
HARDFORK INVOLVING CHANGE IN BLOCK HEADER FORMAT If a hardfork involves
a new block header format, the original format should still be used for
the flag block and a reasonable period afterwards, to make sure existing
nodes realize that an unknown hardfork has been deployed.
VERSION BITS This proposal is also compatible with the BIP9. The version
bits mechanism could be employed to measure miner support towards a
hardfork proposal, and to determine the height or time threshold of the
flag block. Also, miners of the flag block may still cast votes for
other concurrent softfork or hardfork proposals as normal.
POINT OF NO RETURN After the flag block is generated, a miner may
support either the original rules or the new rules, but not both. It is
not possible for miners in one fork to attack or overtake the other fork
without giving up the mining reward of their preferred fork.
[11]COPYRIGHT
This document is placed in the public domain.
Links:
------
[1]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation
[2] https://github.com/jl2012/bips/blob/hardforkbit/bip-0034.mediawiki
[3] https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki
[4]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions
[5] https://github.com/jl2012/bips/blob/hardforkbit/bip-0099.mediawiki
[6]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification
[7] https://github.com/jl2012/bips/blob/hardforkbit/bip-0065.mediawiki
[8]
https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Mechanism
[9] https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki
[10]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility
[11]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/d4208f4f/attachment.html>;
jl2012 [ARCHIVE] /
npub14v…jyksm
2023-06-07 17:48:28
in reply to nevent1q…m4cu
Author Public Key
npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksmPublished at
2023-06-07 17:48:28Event JSON
{
"id": "c8f94abda250f4e21afdc551793bd71e1705cbf9f626867bd55566724ce6da53",
"pubkey": "ab1c85bd5ad443631a95b228bd1630bf7acdb27f6de01a960ccfbb077831d7ec",
"created_at": 1686160108,
"kind": 1,
"tags": [
[
"e",
"225bd65196e0b92a41e9e14e274e0ca016fd5fd1fb7ff068f7d16d873098abfe",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2016-02-04\n📝 Original message:https://github.com/bitcoin/bips/pull/317\n\nABSTRACT\n\nThis document specifies a proposed change to the semantics of the sign\nbit of the \"version\" field in Bitcoin block headers, as a mechanism to\nindicate a hardfork is deployed. It alleviates certain risks related to\na hardfork by introducing an explicit \"point of no return\" in the\nblockchain. This is a general mechanism which should be employed by any\nplanned hardfork in the future. \n\n [1]MOTIVATION\n\nHardforks in Bitcoin are usually considered as difficult and risky,\nbecause: \n\n \t* Hardforks require not only support of miners, but also, most\nimportantly, supermajority support of the Bitcoin economy. As a result,\nsoftfork deployment mechanisms described in BIP 34 [2] or BIP 9 [3] are\nnot enough for introducing hardforks safely.\n \t* Full nodes and SPV nodes following original consensus rules may not\nbe aware of the deployment of a hardfork. They may stick to an\neconomic-minority fork and unknowingly accept devalued legacy tokens.\n \t* In the case which the original consensus rules are also valid under\nthe new consensus rules, users following the new chain may unexpectedly\nreorg back to the original chain if it grows faster than the new one.\nPeople may find their confirmed transactions becoming unconfirmed and\nlose money.\n\nThe first issue involves soliciting support for a hardfork proposal,\nwhich is more a political topic than a technical one. This proposal aims\nat alleviating the risks related to the second and third issues. It\nshould be employed by any planned hardfork in the future.\n\n [4]DEFINITIONS\n\nSee BIP99 [5] \n\n [6]SPECIFICATION\n\nHARDFORK BIT The sign bit in nVersion is defined as the hardfork bit.\nCurrently, blocks with this header bit setting to 1 are invalid, since\nBIP65 [7] interprets nVersion as a signed number and requires it to be ≥\n4. Among the 640 bits in the block header, this is the only one which is\nfixed and serves no purpose, and therefore the best way to indicate the\ndeployment of a hardfork. \n\nFLAG BLOCK Any planned hardfork must have one and only one flag block\nwhich is the \"point of no return\". To ensure monotonicity, flag block\nshould be determined by block height, or as the first block with\nGetMedianTimePast() greater than a threshold. Other mechanisms could be\ndifficult for SPV nodes to follow. The height/time threshold could be a\npredetermined value or relative to other events (e.g. 10000 blocks / 100\ndays after 95% of miner support). The exact mechanism is out of the\nscope of this BIP. No matter what mechanism is used, the threshold is\nconsensus critical. It must be publicly verifiable with only blockchain\ndata, and preferably SPV-friendly (i.e. verifiable with block headers\nonly, without downloading any transaction). \n\nFlag block is constructed in a way that nodes with the original\nconsensus rules must reject. On the other hand, nodes with the new\nconsensus rules must reject a block if it is not a flag block while it\nis supposed to be. To achieve these goals, the flag block must \n\n \t* have the hardfork bit setting to 1, and\n \t* follow any other rules required by the hardfork\n\nIf these conditions are not fully satisfied, upgraded nodes shall reject\nthe block.\n\nThe hardfork bit must be turned off in the successors of the flag block,\nuntil the deployment of the next hardfork. \n\nAlthough a hardfork is officially deployed when flag block is generated,\nthe exact behavioural change is out of the scope of this BIP. For\nexample, a hardfork may not be fully active until certain time after the\nflag block. \n\nCONCURRENT HARDFORK PROPOSALS To avoid confusion and unexpected\nbehaviour, a flag block should normally signify the deployment of only\none hardfork. Therefore, a hardfork proposal has to make sure that its\nflag block threshold is not clashing with other ongoing hardfork\nproposals. \n\nIn the case that the version bits mechanism is used in deploying a\nhardfork, height of the flag block should take a value of32N + B, where\nN is a positive integer and B is the position of bit B defined in BIP9\n[8]. This guarantees that no clash may happen with another hardfork\nproposal using BIP9. \n\nUNCONTROVERSIAL SUBTLE HARDFORKS Hardforks may sometimes be totally\nuncontroversial and make barely noticeable change (BIP50 [9], for\nexample). In such cases, the use of hardfork bit may not be needed as it\nmay cause unnecessary disruption. The risk and benefit should be\nevaluated case-by-case. \n\nAUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is\nfound on the network, full nodes and SPV nodes should alert their users\nand/or stop accepting/sending transactions. It should be noted that the\nwarning system could become a denial-of-service vector if the attacker\nis willing to give up the block reward. Therefore, the warning may be\nissued only if a few blocks are built on top of the flag block in a\nreasonable time frame. This will in turn increase the risk in case of a\nreal planned hardfork so it is up to the wallet programmers to decide\nthe optimal strategy. Human warning system (e.g. the emergency alert\nsystem in Bitcoin Core) could fill the gap. \n\n [10]COMPATIBILITY\n\nAs a mechanism to indicate hardfork deployment, this BIP breaks backward\ncompatibility intentionally. However, without further changes in the\nblock header format, full nodes and SPV nodes could still verify the\nProof-of-Work of a flag block and its successors. \n\nHARDFORK INVOLVING CHANGE IN BLOCK HEADER FORMAT If a hardfork involves\na new block header format, the original format should still be used for\nthe flag block and a reasonable period afterwards, to make sure existing\nnodes realize that an unknown hardfork has been deployed. \n\nVERSION BITS This proposal is also compatible with the BIP9. The version\nbits mechanism could be employed to measure miner support towards a\nhardfork proposal, and to determine the height or time threshold of the\nflag block. Also, miners of the flag block may still cast votes for\nother concurrent softfork or hardfork proposals as normal. \n\nPOINT OF NO RETURN After the flag block is generated, a miner may\nsupport either the original rules or the new rules, but not both. It is\nnot possible for miners in one fork to attack or overtake the other fork\nwithout giving up the mining reward of their preferred fork. \n\n [11]COPYRIGHT\n\nThis document is placed in the public domain. \n\nLinks:\n------\n[1]\nhttps://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation\n[2] https://github.com/jl2012/bips/blob/hardforkbit/bip-0034.mediawiki\n[3] https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki\n[4]\nhttps://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions\n[5] https://github.com/jl2012/bips/blob/hardforkbit/bip-0099.mediawiki\n[6]\nhttps://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification\n[7] https://github.com/jl2012/bips/blob/hardforkbit/bip-0065.mediawiki\n[8]\nhttps://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Mechanism\n[9] https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki\n[10]\nhttps://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility\n[11]\nhttps://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/d4208f4f/attachment.html\u003e",
"sig": "88d9664dc793f3accae67a58eda203f0137659edbf4a9a1df6695c62bc716846358e360adf1ba58fbb1951d90a0d766a117d5c72eea595bd2852c132f24060de"
}