📅 Original date posted:2021-02-24 📝 Original message:On Tue, Feb 23, 2021 at ...

Ariel Luaces [ARCHIVE] /

npub1a0k…09zx

2023-06-07 18:29:01

in reply to nevent1q…ktcp

📅 Original date posted:2021-02-24
📝 Original message:On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.
>
> Where am I wrong here?
>
> Keagan
>
> On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).
>>
>> Cheers,
>>
>> Jeremy
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

To favor LOT=true because it seems like the inevitable result is like
playing the prisoner's dilemma and never cooperating instead of using
the most optimal strategy which is tit-for-tat (cooperating at first
and then cheating once for every time your counterparty cheats).

During segwit users started by cooperating (BIP9, or "LOT=false"),
then a minority of
miners didn't cooperate (small veto but remember the majority of
miners cooperated), then users stopped cooperating in response (UASF),
then miners
reverted to cooperating (MASF while intolerant miners forked off).
Today users should start cooperating again to continue using the
optimal strategy.

Cheers
Ariel Lorenzo-Luaces

Author Public Key

npub1a0k5f8724s6malknkr647u8w7f0dj42zkfhazfv42gk65cspvvzq2r09zx

Show more details

Published at

2023-06-07 18:29:01

Kind type

1 Short Text Note

Event JSON

{ "id": "aba7cf3da6979393e19a4840134e209860ca759c70f3d95f6c9db803eb01d1b6", "pubkey": "ebed449fcaac35befed3b0f55f70eef25ed95542b26fd12595522daa62016304", "created_at": 1686162541, "kind": 1, "tags": [ [ "e", "36a704a4e069f975c0a2345dd12b0515173da2f8fbd7952bae3e044e579a7daa", "", "root" ], [ "e", "3f4c3f5f772cf643a1b3e89f8477e31a141d8e4ae04951ae1c870c615f6a90f8", "", "reply" ], [ "p", "3e3a823d01e151b0b71cd3e8a321e9984fac6dfba221d9b352553644e70d902e" ] ], "content": "📅 Original date posted:2021-02-24\n📝 Original message:On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e If social consensus is what drives technical consensus and not the other way around it seems as if there cannot exist a valid (rational?) reason to oppose Taproot itself, and then by extension with the arguments laid out above, LOT=true seems to be the logical conclusion of all of this, even if Core ships LOT=false at the outset.\n\u003e\n\u003e Where am I wrong here?\n\u003e\n\u003e Keagan\n\u003e\n\u003e On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Personally, I think with either plan the ultimate risk of forking is low given probability to activate before timeout, so we should just pick something and move on, accepting that we aren't setting a precedent by which all future forks should abide. Given my understanding of the tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't move to hold back a plan of LOT=false (but would probably take mitigative steps on community advocacy if it looks like there is non majority but non negligible LOT=true uptake).\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e\n\u003e\u003e Jeremy\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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\nTo favor LOT=true because it seems like the inevitable result is like\nplaying the prisoner's dilemma and never cooperating instead of using\nthe most optimal strategy which is tit-for-tat (cooperating at first\nand then cheating once for every time your counterparty cheats).\n\nDuring segwit users started by cooperating (BIP9, or \"LOT=false\"),\nthen a minority of\nminers didn't cooperate (small veto but remember the majority of\nminers cooperated), then users stopped cooperating in response (UASF),\nthen miners\nreverted to cooperating (MASF while intolerant miners forked off).\nToday users should start cooperating again to continue using the\noptimal strategy.\n\nCheers\nAriel Lorenzo-Luaces", "sig": "185a668573749a6e3e83bf96352ab137ed6f57e17ce796499ef47610c3cd23a9642eea3ab830a68e291a068458c00358ba73cd07af5398401b19970cb19abfee" }