From: Eric Voskuil <eric@voskuil.org>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Cc: John Newbery <john@johnnewbery.com>
Subject: Re: [bitcoin-dev] Burying CSV and segwit soft fork activations
Date: Fri, 16 Aug 2019 13:44:47 -0400 [thread overview]
Message-ID: <2377A2C2-04E6-4128-A756-2909474C423C@voskuil.org> (raw)
In-Reply-To: <20190816160650.artngylrzy2id5tr@petertodd.org>
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
prev parent reply other threads:[~2019-08-16 17:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 15:23 [bitcoin-dev] Burying CSV and segwit soft fork activations John Newbery
2019-08-16 16:06 ` Peter Todd
2019-08-16 17:44 ` Eric Voskuil [this message]
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=2377A2C2-04E6-4128-A756-2909474C423C@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=john@johnnewbery.com \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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