Burying CSV and segwit soft fork activations

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

On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote:

> 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.

I just wanted to elaborate on this excellent point:

This is debatable because Bitcoin is a decentralized, soft-forks are backwards compatible, and it's very difficult if not impossible to measure the preferences of economically significant nodes. Both the BIP9 version bits signalling and the BIP 148 UASF had the same basic effect: enforce segwit. Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the BIP9 version bits.

We can observe the fact that 100% of known blocks produced after Aug 1st 2017 have complied with segwit rules, and the BIP9 signalling protocol for segwit. But strictly speaking we don't really know why that happened. It's possible that miners were running the BIP9 signalling Bitcoin Core release around that time. It's also possible that miners were running UASF enforcing software. It's possible there was a combination of both. Or even entirely different software - remember that some miners produced segwit-valid blocks, but didn't actually mine segwit transactions. Each scenario leads to the same externally observable outcome.

Furthermore there's the question as to why miners were producing segwit-compliant blocks: perhaps they thought the vast majority of economically significant nodes would reject their blocks? Perhaps they just wanted to enforce segwit?

These are all questions that have plausible answers, backed by evidence and argument. But because Bitcoin is a decentralized network no authority can tell you what the answers are.

Thanks for adding this to the record.

And for the record I’ll reiterate here, as I did with BIP90, that this is a hard fork.

e

> On Aug 16, 2019, at 12:06, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote:
>> 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.
>
> I just wanted to elaborate on this excellent point:
>
> This is debatable because Bitcoin is a decentralized, soft-forks are backwards
> compatible, and it's very difficult if not impossible to measure the
> preferences of economically significant nodes. Both the BIP9 version bits
> signalling and the BIP 148 UASF had the same basic effect: enforce segwit.
> Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the BIP9
> version bits.
>
> We can observe the fact that 100% of known blocks produced after Aug 1st 2017
> have complied with segwit rules, and the BIP9 signalling protocol for segwit.
> But strictly speaking we don't really know why that happened. It's possible
> that miners were running the BIP9 signalling Bitcoin Core release around that
> time. It's also possible that miners were running UASF enforcing software.
> It's possible there was a combination of both. Or even entirely different
> software - remember that some miners produced segwit-valid blocks, but didn't
> actually mine segwit transactions. Each scenario leads to the same externally
> observable outcome.
>
> Furthermore there's the question as to why miners were producing
> segwit-compliant blocks: perhaps they thought the vast majority of economically
> significant nodes would reject their blocks? Perhaps they just wanted to
> enforce segwit?
>
> These are all questions that have plausible answers, backed by evidence and
> argument. But because Bitcoin is a decentralized network no authority can tell
> you what the answers are.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev