📅 Original date posted:2022-03-10
📝 Original message: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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 23:06:01
in reply to nevent1q…73ly
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 23:06:01Event JSON
{
"id": "e73b21c8050a3a7309f39b5a352ae066021863090e80d5d5ff11d45ae1ebb7cf",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686179161,
"kind": 1,
"tags": [
[
"e",
"a5af5e39047c2302ef2c813ca29b2c17152d49444d282becfeb36106acf5ee47",
"",
"root"
],
[
"e",
"116b47882e91ae5dcc01dab44d4d58419ba822c9a592727f3aeff2bbf61a8442",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2022-03-10\n📝 Original message:On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:\n\u003e The \"no-miner-veto\" concerns are, to an extent, addressed by the short\n\u003e timeline of Speedy Trial. No more waiting 2 years on the miners dragging\n\u003e their feet.\n\nIt's still a miner veto. The only way this works is if the full deployment \n(with UASF fallback) is released in parallel.\n\n\u003e If you are so concerned about listening to legitimate criticism, maybe you\n\u003e can design a new deployment mechanism that addresses the concerns of the\n\u003e \"devs-do-not-decide\" faction and the \"no-divegent-consensus-rules\"\n\u003e faction.\n\nBIP8 already does that.\n\n\u003e A major contender to the Speedy Trial design at the time was to mandate\n\u003e eventual forced signalling, championed by luke-jr. It turns out that, at\n\u003e the time of that proposal, a large amount of hash power simply did not have\n\u003e the firmware required to support signalling. That activation proposal\n\u003e never got broad consensus,\n\nBIP 8 did in fact have broad consensus before some devs decided to ignore the \ncommunity and do their own thing. Why are you trying to rewrite history?\n\n\u003e and rightly so, because in retrospect we see \n\u003e that the design might have risked knocking a significant fraction of mining\n\u003e power offline if it had been deployed. Imagine if the firmware couldn't be\n\u003e quickly updated or imagine if the problem had been hardware related.\n\nThey had 18 months to fix their broken firmware. That's plenty of time.\n\nLuke",
"sig": "d582ce26d6a3b98a3569fa35e2571437c0e7f757a7a051cc83ad0985f3b092c635e095714b0bf029153973b297308710bfd73edd2189fc5a98363f0df25c96e5"
}