📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The core question always was: what do we do if miners fail to activate?
>
> [...] Speedy Trial takes the approach that "let's pretend we didn't
> *actually* ask [miners]".
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.
> It's totally a political approach, to avoid facing the awkward question.
> Since I believe that such prevaricating makes a future crisis less
> predictable, I am forced to conclude that it makes bitcoin less robust.
LOT=true does face the awkward question, but there are downsides:
- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and
- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.
> Personally, I think the compromise position is using LOT=false and
> having those such as Luke and myself continue working on a LOT=true
> branch for future consideration. It's less than optimal, but I
> appreciate that people want Taproot activated more than they want
> the groundwork future upgrades.
Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:
- we do not need to normalize brinkmanship;
- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and
- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.
Although your NACK is well explained, for the reasons above I am
prepared to run code that overrides it.
Ryan Grant [ARCHIVE] /
npub19a…6mwcl
2023-06-07 18:31:20
in reply to nevent1q…pdcg
Author Public Key
npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclPublished at
2023-06-07 18:31:20Event JSON
{
"id": "4dcdb483bff0be440678a4c90c59046aa6f238bcda56d09894a6cb1149408309",
"pubkey": "2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254",
"created_at": 1686162680,
"kind": 1,
"tags": [
[
"e",
"e73e50e9f54430f38360d52272d6b1694af07b74d14c02f6b929d26ea12016e1",
"",
"root"
],
[
"e",
"97bb42efbf1acb6b87f9f18dd909217e94b4a08cefd314d0da8d963f33922b6e",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2021-04-06\n📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e The core question always was: what do we do if miners fail to activate?\n\u003e\n\u003e [...] Speedy Trial takes the approach that \"let's pretend we didn't\n\u003e *actually* ask [miners]\".\n\nWhat ST is saying is that a strategy of avoiding unnecessary risk is\nstronger than a strategy of brinkmanship when brinkmanship wasn't\nour only option. Having deescalation in the strategy toolkit makes\nBitcoin stronger.\n\n\u003e It's totally a political approach, to avoid facing the awkward question.\n\u003e Since I believe that such prevaricating makes a future crisis less\n\u003e predictable, I am forced to conclude that it makes bitcoin less robust.\n\nLOT=true does face the awkward question, but there are downsides:\n\n - in the requirement to drop blocks from apathetic miners (although\n as Luke-Jr pointed out in a previous reply on this list they have\n no contract under which to raise a complaint); and\n\n - in the risk of a chain split, should gauging economic majority\n support - which there is zero intrinsic tooling for - go poorly.\n\n\u003e Personally, I think the compromise position is using LOT=false and\n\u003e having those such as Luke and myself continue working on a LOT=true\n\u003e branch for future consideration. It's less than optimal, but I\n\u003e appreciate that people want Taproot activated more than they want\n\u003e the groundwork future upgrades.\n\nAnother way of viewing the current situation is that should\nbrinkmanship be necessary, then better tooling to resolve a situation\nthat requires brinkmanship will be invaluable. But:\n\n - we do not need to normalize brinkmanship;\n\n - designing brinkmanship tooling well before the next crisis does\n not require selecting conveniently completed host features to\n strap the tooling onto for testing; and\n\n - it's already the case that a UASF branch can be prepared along\n with ST (ie. without requiring LOT=false), although the code is a\n bit more complex and the appropriate stopheight a few blocks later.\n\nAlthough your NACK is well explained, for the reasons above I am\nprepared to run code that overrides it.",
"sig": "429854ac0f5c100a6b1162de1ef538c504786bc7fc6819fe52028fa3a10b2febb5d587905e031bc55e5c57d6e1ff6f96ebabeabe2b996f3d9025cba280dadc61"
}