From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 11 Mar 2022 00:28:08 +0000
User-Agent: KMail/1.9.10
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
In-Reply-To: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202203110028.09249.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Precedence: list

On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> their feet.

It's still a miner veto. The only way this works is if the full deployment 
(with UASF fallback) is released in parallel.

> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.

BIP8 already does that.

> A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr.  It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling.  That activation proposal
> never got broad consensus,

BIP 8 did in fact have broad consensus before some devs decided to ignore the 
community and do their own thing. Why are you trying to rewrite history?

> and rightly so, because in retrospect we see 
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed.  Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.

They had 18 months to fix their broken firmware. That's plenty of time.

Luke