Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) - Ariel Lorenzo-Luaces

From: Ariel Lorenzo-Luaces <arielluaces@gmail•com>
To: Erik Aronesty <erik@q32•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Date: Tue, 02 Mar 2021 10:32:00 -0800	[thread overview]
Message-ID: <f2f36ee6-e08e-4e1a-bb07-00884dc29174@gmail.com> (raw)
In-Reply-To: <CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3560 bytes --]

I agree.

Thank you Erik for proposing it. It's a pretty good idea.

P.S. I wouldn't want a chain split of a low percentage of users though. The minority will be at the mercy of massive PoW swings and the chain will lose friends so it's not good for anyone. I recommend changing the final percentage to %50 because that's the hurdle where non-upgraded users *must* activate to avoid the risk of being reorged. The number of running users will quickly jump to 90%+ if it ever gets near 50%.

Cheers
Ariel Lorenzo-Luaces

On Mar 1, 2021, 5:54 AM, at 5:54 AM, Erik Aronesty <erik@q32•com> wrote:
>> Today users should start cooperating again to continue using the
>> optimal strategy.
>
>the "gradual" method of reducing the % of miners required for lock-in
>as time goes on seems to encode this optimal strategy.
>
>On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
><bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>> <bitcoin-dev@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@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@lists•linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@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
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4537 bytes --]