From: Peter Todd <pete@petertodd•org>
To: John Newbery <john@johnnewbery•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Burying CSV and segwit soft fork activations
Date: Fri, 16 Aug 2019 12:06:50 -0400 [thread overview]
Message-ID: <20190816160650.artngylrzy2id5tr@petertodd.org> (raw)
In-Reply-To: <CAFmfg2tv4AP6GYSeHkgOYBKiWa3ia_KxWWBBjqY5u4-GkW6oLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-08-16 16:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 15:23 John Newbery
2019-08-16 16:06 ` Peter Todd [this message]
2019-08-16 17:44 ` Eric Voskuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190816160650.artngylrzy2id5tr@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=john@johnnewbery$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox