John Newbery [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-16 📝 Original message:Once a consensus change ...
📅 Original date posted:2019-08-16
📝 Original message:Once a consensus change has been activated and buried by sufficient work,
we consider the height of that change to be historic fact. The exact
activation method is no longer of practical interest. In some cases the
cause of activation is not even decidable. For example, we know that segwit
activated at height 481,824 but it's debatable whether that was due to BIP
9 version bits signaling, BIP 148 UASF, or a combination of the two.
In such cases, we can significantly simplify the implementation by
hard-coding the activation height. This was done for the 3 ISM soft forks
(BIPs 34, 66 and 65) in BIP 90 [1] [2]. P2SH and segwit script enforcement
were backdated to the genesis block (with the exception of for one block)
for similar code simplification reasons [3] [4].
'Burying' deployments in this way provides a number of benefits:
1. consensus code is simplified and implementers can avoid writing and
testing code paths that are no longer relevant.
2. a hard-coded activation height is far easier to review and re-implement
than complex deployment activation logic.
3. using a non-contextual check (in this case a hard-coded constant) can
provide performance and code structure benefits (eg reducing lock
contention on blockchain data).
Bitcoin Core PR 16060 [5] was recently merged, which buries the CSV and
segwit activation heights to 419328 and 481824 respectively.
It is technically possible for this to be a non-backwards compatible
change. In the event of a re-org below the BIP9 segwit LOCKED_IN height,
this change _could_ cause a chainsplit between pre-0.19 nodes and 0.19
nodes. Such a re-org would require re-doing over 93% of the total work ever
committed to Bitcoin mining (chainwork is 0x7eb6a652531c5ad6a4b8e9 at
height 481824 compared to 0x07d75b9d25fb6602be2b51c6 at height 590393). To
quote from BIP90:
> The occurrence of such a reorg that would cause the activating block to
be disconnected would raise fundamental concerns about the security
assumptions of Bitcoin, a far bigger issue than any non-backwards
compatible change.
> So while this proposal could theoretically result in a consensus split,
it is extremely unlikely, and in particular any such circumstances would be
sufficiently damaging to the Bitcoin network to dwarf any concerns about
the effects of this proposed change.
(See the 'Considerations' section of BIP 90 for more details).
Cheers,
John
[1] https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
[2] https://github.com/bitcoin/bitcoin/pull/8391
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015588.html
[4] https://github.com/bitcoin/bitcoin/pull/11739
[5] https://github.com/bitcoin/bitcoin/pull/16060
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190816/c439614c/attachment.html>;
📝 Original message:Once a consensus change has been activated and buried by sufficient work,
we consider the height of that change to be historic fact. The exact
activation method is no longer of practical interest. In some cases the
cause of activation is not even decidable. For example, we know that segwit
activated at height 481,824 but it's debatable whether that was due to BIP
9 version bits signaling, BIP 148 UASF, or a combination of the two.
In such cases, we can significantly simplify the implementation by
hard-coding the activation height. This was done for the 3 ISM soft forks
(BIPs 34, 66 and 65) in BIP 90 [1] [2]. P2SH and segwit script enforcement
were backdated to the genesis block (with the exception of for one block)
for similar code simplification reasons [3] [4].
'Burying' deployments in this way provides a number of benefits:
1. consensus code is simplified and implementers can avoid writing and
testing code paths that are no longer relevant.
2. a hard-coded activation height is far easier to review and re-implement
than complex deployment activation logic.
3. using a non-contextual check (in this case a hard-coded constant) can
provide performance and code structure benefits (eg reducing lock
contention on blockchain data).
Bitcoin Core PR 16060 [5] was recently merged, which buries the CSV and
segwit activation heights to 419328 and 481824 respectively.
It is technically possible for this to be a non-backwards compatible
change. In the event of a re-org below the BIP9 segwit LOCKED_IN height,
this change _could_ cause a chainsplit between pre-0.19 nodes and 0.19
nodes. Such a re-org would require re-doing over 93% of the total work ever
committed to Bitcoin mining (chainwork is 0x7eb6a652531c5ad6a4b8e9 at
height 481824 compared to 0x07d75b9d25fb6602be2b51c6 at height 590393). To
quote from BIP90:
> The occurrence of such a reorg that would cause the activating block to
be disconnected would raise fundamental concerns about the security
assumptions of Bitcoin, a far bigger issue than any non-backwards
compatible change.
> So while this proposal could theoretically result in a consensus split,
it is extremely unlikely, and in particular any such circumstances would be
sufficiently damaging to the Bitcoin network to dwarf any concerns about
the effects of this proposed change.
(See the 'Considerations' section of BIP 90 for more details).
Cheers,
John
[1] https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
[2] https://github.com/bitcoin/bitcoin/pull/8391
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015588.html
[4] https://github.com/bitcoin/bitcoin/pull/11739
[5] https://github.com/bitcoin/bitcoin/pull/16060
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190816/c439614c/attachment.html>;