public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation
Date: Sun, 28 Feb 2021 12:29:36 -0500	[thread overview]
Message-ID: <c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com> (raw)
In-Reply-To: <202102281720.07392.luke@dashjr.org>

I think you may have misunderstood my proposal. I'm not suggesting some people run BIP 8(true), some run BIP8(false), 
and some run a client which has a flag day, I'm suggesting a flag day activation instead of any BIP8-based activation. 
Replies to your further points inline.

Matt

On 2/28/21 12:20, Luke Dashjr wrote:
> On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote:
> Concept NACK. This still has the same problems BIP149 would have had, as I
> just reminded in my last email to this ML:
> 
> 1) Such a chain does not indicate activation at all, leaving it unresolved and
> debatable whether activation has occurred or not.
> 2) As a result, it is also impractical to intentionally reject the softfork
> should anyone decide to do so.
> 
> Signalling is important to activation.

Several people responded disagreeing, including myself. I'll paste my response here in case you missed it:

Forced-signaling, or any form of signaling, does not materially change whether a soft fork can be seen to be safe to 
use. Pieter wrote a great post[1] some time ago that goes into depth about the security of soft forks, but, while miners 
can help to avoid the risk of forks, they aren't the determining factor in whether use of a fork should be considered 
safe (ie the fork "has activated").

Not only that, but the signaling methods used in BIP 8/9 (ie the version field in the block header) do not imply 
anything about whether mining pools are running full nodes which enforce the soft fork at all, only whether the pool has 
configured their stratum software to signal or not.

Ultimately, forced-signaling, or signaling period, are not a substitute for having a broad set of upgraded nodes across 
the network, including an overwhelming majority of economically-active nodes, enforcing the rules of a new fork. As this 
can be difficult to measure, waiting some time after a fork and examining upgrade patterns across the network is important.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html


  reply	other threads:[~2021-02-28 17:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28 16:45 [bitcoin-dev] Straight Flag Day (Height) Taproot Activation Matt Corallo
2021-02-28 17:20 ` Luke Dashjr
2021-02-28 17:29   ` Matt Corallo [this message]
2021-02-28 19:43     ` Jeremy
2021-02-28 19:51       ` Matt Corallo
2021-02-28 20:02         ` Jeremy
2021-02-28 20:19           ` Eric Voskuil
2021-02-28 20:25             ` Matt Corallo
2021-02-28 20:38               ` Eric Voskuil
2021-02-28 20:20           ` Matt Corallo
2021-03-03 14:59 ` Anthony Towns
2021-03-03 16:49   ` Matt Corallo
2021-03-06 11:33     ` Anthony Towns
2021-03-08 12:51       ` Jorge Timón
2021-03-08 14:13         ` eric

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=c6a7a7ab-ee68-6594-ebd0-60f38ba40c37@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.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