š
Original date posted:2021-04-07
š Original message:As a user, I think it's very important for me to know if Taproot is
eventually coming or not. So why not make it so that if _either_ miners
_or_ users decide for Taproot, it will activate no matter what. Accepting a
chain split is imo the fairest way to 'resolve the conflict' (it can't be
resolved anyway).
That would probably mean running ST and and UASF concurrently.
The upside would be that we've got a safe date for Taproot, except neither
users nor miners want it.
Cheers,
Claus
On Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ryan Grant <bitcoin-dev at rgrant.org> writes:
> > 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.
>
> I don't believe that having a plan is brinkmanship or an escalation.
>
> During the segwit debate, Pieter Wuille said that users should decide.
> I've been thinking about that a lot, especially about what that means in
> a practical sense where the normal developer / miner dynamic has failed.
>
> >> 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
>
> Surely, yes. If the users of bitcoin decide blocks are invalid, they're
> invalid. With a year's warning, and developer and user consensus
> against them, I think we've reached the limits of acceptable miner
> apathy.
>
> > - in the risk of a chain split, should gauging economic majority
> > support - which there is zero intrinsic tooling for - go poorly.
>
> Agreed that we should definitely do better here: in practice people
> would rely on third party explorers for information on the other side of
> the split. Tracking the cumulative work on invalid chains would be a
> good idea for bitcoind in general (AJ suggested this, IIRC).
>
> >> 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
>
> Again, openly creating a contingency plan is not brinkmanship, it's
> normal. I know that considering these scenarios is uncomfortable; I
> avoid conflict myself! But I feel obliged to face this as a real
> possibility.
>
> I think we should be normalizing the understanding that bitcoin users
> are the ultimate decider. By offering *all* of them the tools to do so
> we show this isn't lip-service, but something that businesses and
> everyone else in the ecosystem should consider.
>
> > - 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.
>
> I don't believe this is true, unless you UASF before ST expires? ST is
> explicitly designed *not* to give time to conclude that miners are
> stalling (unless something has changed from the initial 3 month
> proposal?).
>
> > Although your NACK is well explained, for the reasons above I am
> > prepared to run code that overrides it.
>
> Good. In the end, we're all at the whim of the economic majority.
>
> Cheers!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/e1e7b86a/attachment.html>;
Claus Ehrenberg [ARCHIVE] /
npub1a8ā¦e3wff
2023-06-07 22:51:25
in reply to nevent1qā¦gqy9
Author Public Key
npub1a8ck0asqq2y93057qzj5laj2c67mrdssw65txe5kr84g3a80v2nqye3wffPublished at
2023-06-07 22:51:25Event JSON
{
"id": "1a3665f7c64592ae8598ba6f42d64d044785cffca89805dbcb1664532208d828",
"pubkey": "e9f167f600028858be9e00a54ff64ac6bdb1b61076a8b3669619ea88f4ef62a6",
"created_at": 1686178285,
"kind": 1,
"tags": [
[
"e",
"d523491946f0d211fd123a1f1b64561c6201851a92f7f901d22926762a444f04",
"",
"root"
],
[
"e",
"138f5c1104e6dac187a23f52d54cbc0f82dd3a3f8e14476d99e50e6088d2ead6",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2021-04-07\nš Original message:As a user, I think it's very important for me to know if Taproot is\neventually coming or not. So why not make it so that if _either_ miners\n_or_ users decide for Taproot, it will activate no matter what. Accepting a\nchain split is imo the fairest way to 'resolve the conflict' (it can't be\nresolved anyway).\n\nThat would probably mean running ST and and UASF concurrently.\n\nThe upside would be that we've got a safe date for Taproot, except neither\nusers nor miners want it.\n\nCheers,\nClaus\n\nOn Wed, Apr 7, 2021 at 7:02 AM Rusty Russell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Ryan Grant \u003cbitcoin-dev at rgrant.org\u003e writes:\n\u003e \u003e On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e The core question always was: what do we do if miners fail to activate?\n\u003e \u003e\u003e\n\u003e \u003e\u003e [...] Speedy Trial takes the approach that \"let's pretend we didn't\n\u003e \u003e\u003e *actually* ask [miners]\".\n\u003e \u003e\n\u003e \u003e What ST is saying is that a strategy of avoiding unnecessary risk is\n\u003e \u003e stronger than a strategy of brinkmanship when brinkmanship wasn't\n\u003e \u003e our only option. Having deescalation in the strategy toolkit makes\n\u003e \u003e Bitcoin stronger.\n\u003e\n\u003e I don't believe that having a plan is brinkmanship or an escalation.\n\u003e\n\u003e During the segwit debate, Pieter Wuille said that users should decide.\n\u003e I've been thinking about that a lot, especially about what that means in\n\u003e a practical sense where the normal developer / miner dynamic has failed.\n\u003e\n\u003e \u003e\u003e It's totally a political approach, to avoid facing the awkward question.\n\u003e \u003e\u003e Since I believe that such prevaricating makes a future crisis less\n\u003e \u003e\u003e predictable, I am forced to conclude that it makes bitcoin less robust.\n\u003e \u003e\n\u003e \u003e LOT=true does face the awkward question, but there are downsides:\n\u003e \u003e\n\u003e \u003e - in the requirement to drop blocks from apathetic miners (although\n\u003e \u003e as Luke-Jr pointed out in a previous reply on this list they have\n\u003e \u003e no contract under which to raise a complaint); and\n\u003e\n\u003e Surely, yes. If the users of bitcoin decide blocks are invalid, they're\n\u003e invalid. With a year's warning, and developer and user consensus\n\u003e against them, I think we've reached the limits of acceptable miner\n\u003e apathy.\n\u003e\n\u003e \u003e - in the risk of a chain split, should gauging economic majority\n\u003e \u003e support - which there is zero intrinsic tooling for - go poorly.\n\u003e\n\u003e Agreed that we should definitely do better here: in practice people\n\u003e would rely on third party explorers for information on the other side of\n\u003e the split. Tracking the cumulative work on invalid chains would be a\n\u003e good idea for bitcoind in general (AJ suggested this, IIRC).\n\u003e\n\u003e \u003e\u003e Personally, I think the compromise position is using LOT=false and\n\u003e \u003e\u003e having those such as Luke and myself continue working on a LOT=true\n\u003e \u003e\u003e branch for future consideration. It's less than optimal, but I\n\u003e \u003e\u003e appreciate that people want Taproot activated more than they want\n\u003e \u003e\u003e the groundwork future upgrades.\n\u003e \u003e\n\u003e \u003e Another way of viewing the current situation is that should\n\u003e \u003e brinkmanship be necessary, then better tooling to resolve a situation\n\u003e \u003e that requires brinkmanship will be invaluable. But:\n\u003e \u003e\n\u003e \u003e - we do not need to normalize brinkmanship;\n\u003e \u003e\n\u003e \u003e - designing brinkmanship tooling well before the next crisis does\n\u003e \u003e not require selecting conveniently completed host features to\n\u003e \u003e strap the tooling onto for testing; and\n\u003e\n\u003e Again, openly creating a contingency plan is not brinkmanship, it's\n\u003e normal. I know that considering these scenarios is uncomfortable; I\n\u003e avoid conflict myself! But I feel obliged to face this as a real\n\u003e possibility.\n\u003e\n\u003e I think we should be normalizing the understanding that bitcoin users\n\u003e are the ultimate decider. By offering *all* of them the tools to do so\n\u003e we show this isn't lip-service, but something that businesses and\n\u003e everyone else in the ecosystem should consider.\n\u003e\n\u003e \u003e - it's already the case that a UASF branch can be prepared along\n\u003e \u003e with ST (ie. without requiring LOT=false), although the code is a\n\u003e \u003e bit more complex and the appropriate stopheight a few blocks later.\n\u003e\n\u003e I don't believe this is true, unless you UASF before ST expires? ST is\n\u003e explicitly designed *not* to give time to conclude that miners are\n\u003e stalling (unless something has changed from the initial 3 month\n\u003e proposal?).\n\u003e\n\u003e \u003e Although your NACK is well explained, for the reasons above I am\n\u003e \u003e prepared to run code that overrides it.\n\u003e\n\u003e Good. In the end, we're all at the whim of the economic majority.\n\u003e\n\u003e Cheers!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210407/e1e7b86a/attachment.html\u003e",
"sig": "3ea8b8c23a9cd29a0a3af903242575b6d299c9ae266a139b2d1cd95c752a3c43f023fc21f398e5eeaa04aef95753ec15d506a080d391f4472401e7d78bb30109"
}