Skip to content

Instantly share code, notes, and snippets.

@achow101
Last active March 7, 2022 06:38
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save achow101/3e179501290abb7049de198d46894c7c to your computer and use it in GitHub Desktop.
Save achow101/3e179501290abb7049de198d46894c7c to your computer and use it in GitHub Desktop.
Preferences of LOT=true/false for Taproot activation meeting 2021-02-16

During the taproot activation parameters meeting on 2021-02-16, participants expressed their preferences with regards to BIP 8's lockinontimeout (LOT) parameter. This is a summary of those preferences.

IRC Log

[02-16 02:45:56 pm] <@michaelfolkson> THIS SECTION. WHICH IS YOUR PREFERENCE? ARE YOU HAPPY WITH SECOND PREFERENCE?
[02-16 02:45:56 pm] <debit> michaelfolkson what are we moving on to
[02-16 02:46:04 pm] <robert_spigler> harding: if we're not sure that there aren't going to be any problems yet, we shouldn't be discussing activation
[02-16 02:46:15 pm] <luke-jr> michaelfolkson: wut
[02-16 02:46:17 pm] <belcher> michaelfolkson i prefer LOT=false but i'm happy with LOT=true
[02-16 02:46:20 pm] <fjahr> michaelfolkson: what is the difference between that and people threatening to fork to get a certain feature
[02-16 02:46:27 pm] <benthecarman> pref: lot=true, happy with lot=false
[02-16 02:46:28 pm] <proofofkeags> luke-jr we should discuss in another forum
[02-16 02:46:45 pm] <@michaelfolkson> I prefer LOT=true but I'm happy with LOT=false
[02-16 02:46:46 pm] <waxwing> lot=false,happy with lot=true
[02-16 02:46:49 pm] <robert_spigler> sorry, reading old messages
[02-16 02:46:50 pm] <hsjoberg> I am fine with lot=false IF it is easy to change to lot=true. Not requiring a shaolinfry-like fork.
[02-16 02:46:50 pm] <fjahr> lot=false
[02-16 02:46:51 pm] <devrandom> prefer LOT=true, OK with LOT=false if threshold <= 90%
[02-16 02:46:57 pm] <darosior> My preference is starting LOT=false *because* i oppose LOT=true (but only as starting method)
[02-16 02:46:58 pm] <andrewtoth> prefer LOT=false, but whatever will get activation code merged and released
[02-16 02:46:58 pm] <luke-jr> anything other than LOT=true would be a mistake IMO, but probably not fatal; I'm not up for repeating 2017 though, so if we do LOT=false and it turns into a mess, LOT=false people can fix it <.<
[02-16 02:47:03 pm] <emzy> michaelfolkson: I prefer LOT=false but i'm OK with LOT=true
[02-16 02:47:04 pm] <viaj3ro> prefer LOT=true, OK with LOT=false
[02-16 02:47:04 pm] <proofofkeags> michaelfolkson +1
[02-16 02:47:04 pm] <@michaelfolkson> Please be clear if you are happy with second preference
[02-16 02:47:04 pm] <achow101> prefer with lot=false followed by lot=true, no second preference
[02-16 02:47:12 pm] <Murch> eeb77f71f26eee: The point is that there is no way to measure support of all network participants.
[02-16 02:47:23 pm] <virtu> prefer lot=false
[02-16 02:47:23 pm] <luke-jr> to be clear: I am not happy with LOT=false
[02-16 02:47:31 pm] <proofofkeags> I prefer LOT=TRUE, but can live with LOT=FALSE
[02-16 02:47:31 pm] <Murch> There are very few things that are objectively measurable
[02-16 02:47:32 pm] <nickler> lot = false, then lot = true
[02-16 02:47:32 pm] <@michaelfolkson> achow101: You are definitely not happy with LOT=true at the outset?
[02-16 02:47:34 pm] <satosaurian> i prefer lot=true because I cant seem to find the arguments for lot=false convincing and I think lot=false would be a mistake because it could turn into a mess and would give miners power they don't have
[02-16 02:47:40 pm] <eeb77f71f26eee> prefer lot=true
[02-16 02:47:41 pm] <hsjoberg> michaelfolkson: Wow is that a change of opinion, I thought you preferred lot=false
[02-16 02:47:48 pm] <achow101> michaelfolkson: I have now been convinced that LOT=true is bad at the outset
[02-16 02:47:59 pm] <Murch> We can talk all we want on IRC, Twitter and Reddit, but that doesn't necessarily give us an accurate picture of the support landscape
[02-16 02:48:00 pm] <@michaelfolkson> Thanks achow101, that's useful
[02-16 02:48:01 pm] <gg34> prefer lot=true, if you make lot=false please make it as easy as possible for node runners like me to express our sovereignty.
[02-16 02:48:02 pm] <robert_spigler> I prefer LOT=true but would compromise with Modern Soft Fork
[02-16 02:48:12 pm] <hsjoberg> I prefer LOT=true, I am okay with LOT=false if it easy to for the user to change to LOT=true
[02-16 02:48:22 pm] <luke-jr> Murch: all we can do here is make a proposal for the rest of the community to consider
[02-16 02:48:26 pm] <gr-g> prefer LOT=false but OK with LOT=true
[02-16 02:48:36 pm] <harding> I prefer LOT=false to start with.  I won't quit Bitcoin if Bitcoin Core starts with LOT=true, but I will need to take time to understand why they made a decision I wouldn't expect
[02-16 02:48:36 pm] <jonatack> prefer lot = false, then lot = true
[02-16 02:48:38 pm] <pox> slight preference for LOT=true
[02-16 02:48:44 pm] <solairis> seems like LOT true is getting a majority support
[02-16 02:48:48 pm] <Billy> Prefer LOT=true, with no strong objection to LOT=false
[02-16 02:48:49 pm] <@michaelfolkson> luke-jr is strongly against false. achow101 is strongly against true. Any other strong opposition?
[02-16 02:48:49 pm] <proofofkeags> FWIW, a shortened timeout horizon would make me happier with LOT=FALSE
[02-16 02:49:05 pm] <hsjoberg> (Yep said that last time as well.)
[02-16 02:49:05 pm] <evankaloudis> I prefer lot = false. LOT=true is ok thought because the vast majority of miners have already indicated support
[02-16 02:49:08 pm] <virtu> strongly against starting with true
[02-16 02:49:14 pm] <luke-jr> would a longer timeoutheight make anyone happier with LOT=true?
[02-16 02:49:15 pm] <criley> I too prefer LOT=true but I'm fine with LOT=false. I compile each time anyway, so it is easy to flip.  I think everyone wants it activated as soon as possible, it is just a question of the best way.
[02-16 02:49:16 pm] <proofofkeags> I STRONGLY oppose multiple in flight fork attempts at the same time
[02-16 02:49:17 pm] <CubicEarth> I would like to see 90% or 85% threshold
[02-16 02:49:17 pm] <Murch> luke-jr: Right, so if it's a proposal, why should we force a date? Isn't it better to propose something that will benignly dissipate without anyone needing to upgrade if activation is not achieved?
[02-16 02:49:22 pm] <harding> luke-jr: not me.
[02-16 02:49:22 pm] <@michaelfolkson> harding: You would be happy(ish) with LOT=true?
[02-16 02:49:25 pm] <fjahr> michaelfolkson: pretty strong for starting with lot=false
[02-16 02:49:41 pm] <prayank> LOT = true only based on what I have read about everything involved
[02-16 02:49:45 pm] <evankaloudis> proofofkeags: we need to strongly define the time frames. they shouldn't overlap
[02-16 02:49:46 pm] <achow101> luke-jr: no
[02-16 02:49:51 pm] <darosior> michaelfolkson: i'm strongly against starting with true
[02-16 02:49:56 pm] <harding> michaelfolkson: definitely not happy, just not unhappy enough to quit Bitcoin (which is everyone's ultimate recourse to decisions they don't like).
[02-16 02:49:57 pm] <@michaelfolkson> Greg Maxwell said he would only support LOT=true if clear consensus
[02-16 02:50:17 pm] <hsjoberg> Makes sense
[02-16 02:50:18 pm] <viaj3ro> an easy configurable switch would make me happier with LOT=false
[02-16 02:50:27 pm] <hsjoberg> viaj3ro yep agree
[02-16 02:50:29 pm] <@michaelfolkson> Matt is (presumably) strongly against LOT=true
[02-16 02:50:33 pm] <luke-jr> Murch: the community needs to accept or reject the proposal, but if accepted, it should not fail
[02-16 02:50:42 pm] <debit> I prefer lot=false then true with short time periods
[02-16 02:50:46 pm] <proofofkeags> evankaloudis: 100%. If we do a sequenced L=F >> L=T, they should be non-overlapping, and I would add that we should shorten the time horizon for the L=F attempt so as to increase the rate at which said data gathering can occur
[02-16 02:50:49 pm] <@michaelfolkson> Strong opposition I think is key at this point
[02-16 02:50:52 pm] <Murch> I'm also unconvinced that LOT=True is a good idea, in case it's not clear.
[02-16 02:50:53 pm] <hsjoberg> lot=false is fine if we can prevent 2017-scenarion. If it isn't easily configurable we have learnt nothing since 2017.
[02-16 02:51:13 pm] <Murch> luke-jr: Right, but you can only measure actual sentiment once activation code is deployed
[02-16 02:51:19 pm] <luke-jr> 10 minutes left (unless we go longer than an hour); can we move on to the more critical params? :P
[02-16 02:51:29 pm] <belcher> in 2017 we got many bitcoin merchants (i.e. those who accept bitcoin as payment for something real) to say they support the UASF, since LOT=true is a UASF would it be useful to ask some of those businesses again? would that make people who disagree with LOT=true change their mind?
[02-16 02:51:33 pm] <luke-jr> Murch: I don't agree.
[02-16 02:51:46 pm] <@michaelfolkson> We have presumably Matt, darosior, achow101 (and presumably Greg) strongly against lot=true
[02-16 02:51:51 pm] <harding> belcher: it would not change my mind on the parameters for initial deployment.
[02-16 02:51:55 pm] <luke-jr> michaelfolkson: Matt isn't here.
[02-16 02:52:13 pm] <@michaelfolkson> luke-jr: We can ask him. I am pretty sure what he would say
[02-16 02:52:16 pm] <ghost43> I prefer lot=false, with modern soft fork activation as follow-up if it fails to activate. I think that's a conservative option without any drawbacks except possible delay
[02-16 02:52:20 pm] <hsjoberg> michaelfolkson: Well Greg isn't strongly against as you said. Only if there isn's consensus
[02-16 02:52:27 pm] <harding> belcher: argument F7 is important to me, and merchant support for UASF wouldn't affect that.
[02-16 02:52:40 pm] <proofofkeags> luke-jr Matt laid out a pretty comprehensive case against it on TFTC
[02-16 02:52:42 pm] <luke-jr> michaelfolkson: if he won't participate in the group, IMO he shouldn't be considered for the group's recommendation, especially while actively refusing to discuss
[02-16 02:52:52 pm] <@michaelfolkson> hsjoberg: Is there clear consensus on lot=true? I don't think so
[02-16 02:52:54 pm] <belcher> harding how so? anyone saying "core devs decided" would be easily shown wrong because of the records of merchant support
[02-16 02:52:55 pm] <robert_spigler> agreed
[02-16 02:53:06 pm] <hsjoberg> michaelfolkson: I don't know
[02-16 02:53:09 pm] <debit> belcher if the market better understood that bitcoin core is just a code-endorsement group and doesn't control what node software that people who pay for block production, that would change my mind
[02-16 02:53:12 pm] <@michaelfolkson> hsjoberg: If there isn't clear consensus on lot=true Greg is against
[02-16 02:53:17 pm] <achow101> belcher: debuning bullshit is an order of magnititude harder than it is to spread it
[02-16 02:53:18 pm] <fjahr> michaelfolkson: agree with luke, even if the opinion was made public I think the discussion here should be contained
[02-16 02:53:24 pm] <robert_spigler> There is not clear consensus on LOT=true
[02-16 02:53:32 pm] <@michaelfolkson> No robert_spigler
[02-16 02:53:32 pm] <hsjoberg> Well you said strongly against. So to be pendantic
[02-16 02:53:34 pm] <belcher> achow101 fair point
[02-16 02:53:35 pm] <fjahr> *matt's opinion
[02-16 02:53:37 pm] <hsjoberg> sorry*
[02-16 02:53:40 pm] <virtu> I think we're done with the 'what's everyone's preference' part
[02-16 02:53:41 pm] <waxwing> i think lot=false will lead to faster activation too

Preferences

The following table lists people's preferences as stated in the IRC log. Note that "Prefer" means first choice, "OK with" means second choice. Lack of an "OK with" indicates strong opposition to that option (except where it is the same option as the "Prefer").

IRC Nick Prefer LOT=true first Prefer LOT=false first OK with LOT=true first OK with LOT=false first Notes
belcher X X
benthcarman X X
waxwing X X
hsjoberg X LOT configurable
fjahr X
devrandom X threshold <= 90%
darosior X LOT=true after is OK
andrewtoth X OK with whatever gets activated
luke-jr X "LOT=false probably not fatal;.. if we do LOT=false and it turns into a mess, LOT=false people can fix it"
emzy X X
viaj3ro X X
achow101 X Prefer a followup with LOT=true afterwards if LOT=false fails for no good reason
virtu X
proofofkeags X X
nickler X X
satosaurian X
eeb77f71f26eee X
gg34 X LOT configurable
robert_spigler X Modern soft fork activation ok
gr-g X X
harding X
jonatack X LOT=true followup
pox X X
Billy X X
evankaloudis X X
virtu X
criley X X
prayank X
debit X "LOT=false then true with shorter time periods"
Murch X
ghost43 X Modern soft fork follow-up
TOTALS 14 17 6 7

The following table categorizes the preferences more cleanly.

Nickname Only LOT=true Only LOT=false Modern Soft Fork Activation (MSFA) Both, prefer LOT=true Both, prefer LOT=false
belcher X
benthecarman X
waxwing X
hsjoberg X
fjahr X
devrandom X
darosior X
andrewtoth X
luke-jr X
emzy X
viaj3ro X
achow101 X
virtu X
proofofkeags X
nickler X
satosaurian X
eeb77f7f26eee X
gg34 X
robert_spigler X
gr-g X
harding X
jonatack X
pox X
Billy X
evankaloudis X
virtu X
criley X
prayank X
debit X
Murch X
ghost43 X
TOTALS 6 5 5 8 7

The following table summarizes whether each person is ok with LOT=true first or LOT=false first. This is regardless of which is the first choice. This is only for the initial soft fork, i.e. MSFA is counted as only LOT=false.

Nickname LOT=true LOT=false
belcher X X
benthecarman X X
waxwing X X
hsjoberg X
fjahr X
devrandom X X
darosior X
andrewtoth X
luke-jr X
enzy X X
viaj3ro X X
achow101 X
virtu X
proofofkeags X X
nickler X X
satosaurian X
eeb77f7f26eee X
gg34 X X
harding X
jonatack X
pox X X
Billy X X
evankaloudis X X
virtu X
criley X X
prayank X
debit X
Murch X
ghost43 X
TOTALS 18 24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment