From: Erik Aronesty <erik@q32•com>
To: Ariel Luaces <arielluaces@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Date: Mon, 1 Mar 2021 08:54:34 -0500 [thread overview]
Message-ID: <CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com> (raw)
In-Reply-To: <CAOv1TnhQcYrc5q6GTUTuQMEi9RAV4dy5mmyNp--HuYTPzEUfJQ@mail.gmail.com>
> 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
next prev parent reply other threads:[~2021-03-01 13:54 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 12:51 Michael Folkson
2021-02-18 5:43 ` Ariel Lorenzo-Luaces
2021-02-18 11:01 ` Michael Folkson
2021-02-18 11:11 ` Samson Mow
2021-02-18 11:52 ` ZmnSCPxj
2021-02-18 12:20 ` Michael Folkson
2021-02-18 14:01 ` Matt Corallo
2021-02-18 14:26 ` Michael Folkson
2021-02-18 14:42 ` Matt Corallo
2021-02-18 14:51 ` Michael Folkson
2021-02-18 14:53 ` Matt Corallo
2021-02-18 15:01 ` Matt Corallo
2021-02-18 15:04 ` Keagan McClelland
2021-02-18 15:18 ` Matt Corallo
2021-02-19 2:20 ` Ariel Luaces
2021-02-19 11:30 ` ZmnSCPxj
2021-02-19 12:05 ` Adam Back
2021-02-19 14:13 ` Matt Corallo
2021-02-19 17:48 ` Matt Corallo
2021-02-20 2:55 ` ZmnSCPxj
2021-02-20 17:20 ` Ariel Lorenzo-Luaces
2021-02-21 14:30 ` Matt Corallo
2021-02-22 5:16 ` Anthony Towns
2021-02-22 6:44 ` Matt Corallo
2021-02-22 10:16 ` Anthony Towns
2021-02-22 14:00 ` Matt Corallo
2021-02-22 16:27 ` Anthony Towns
2021-02-22 16:31 ` Jorge Timón
2021-02-22 16:48 ` Jorge Timón
2021-02-23 2:10 ` Jeremy
2021-02-23 19:33 ` Keagan McClelland
2021-02-23 23:14 ` Ben Woosley
2021-02-24 22:37 ` Ariel Luaces
2021-03-01 13:54 ` Erik Aronesty [this message]
2021-03-02 18:32 ` Ariel Lorenzo-Luaces
2021-02-24 7:18 ` Anthony Towns
2021-02-18 13:59 ` Matt Corallo
2021-02-21 16:21 ` Erik Aronesty
2021-02-19 22:12 Matt Hill
2021-02-19 23:30 ` Matt Corallo
2021-02-19 23:42 ` Bryan Bishop
2021-02-21 10:10 Prayank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJowKgL07Jo0XyU-XGJ0DOCk8jCj6TbjiQzGKWApqYfKjsPvGQ@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=arielluaces@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox