public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-17 12:51 Michael Folkson
  2021-02-18  5:43 ` Ariel Lorenzo-Luaces
  2021-02-21 16:21 ` Erik Aronesty
  0 siblings, 2 replies; 42+ messages in thread
From: Michael Folkson @ 2021-02-17 12:51 UTC (permalink / raw)
  To: bitcoin-dev

Yesterday (February 16th) we held a second meeting on Taproot
activation on IRC which again was open to all. Despite what appeared
to be majority support for LOT=false over LOT=true in the first
meeting I (and others) thought the arguments had not been explored in
depth and that we should have a follow up meeting almost entirely
focused on whether LOT (lockinontimeout) should be set to true or
false.

The meeting was announced here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html

In that mailing list post I outlined the arguments for LOT=true (T1 to
T6) and arguments for LOT=false (F1 to F6) in their strongest form I
could. David Harding responded with an additional argument for
LOT=false (F7) here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html

These meetings are very challenging given they are open to all, you
don’t know who will attend and you don’t know most people’s views in
advance. I tried to give time for both the LOT=true arguments and the
LOT=false arguments to be discussed as I knew there was support for
both. We only tried evaluating which had more support and which had
more strong opposition towards the end of the meeting.

The conversation log is here:
http://gnusha.org/taproot-activation/2021-02-16.log

(If you are so inclined you can watch a video of the meeting here.
Thanks to the YouTube account “Bitcoin” for setting up the livestream:
https://www.youtube.com/watch?v=vpl5q1ovMLM)

A summary of the meeting was provided by Luke Dashjr on Mastodon here:
https://bitcoinhackers.org/@lukedashjr/105742918779234566

Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
did manage to come to consensus on everything but LockinOnTimeout.

Activation height range: 693504-745920

MASF threshold: 1815/2016 blocks (90%)

Keep in mind only ~100 people showed for the meetings, hardly
representative of the entire community.

So, these details remain JUST a proposal for now.

It seems inevitable that there won't be consensus on LOT.

Everyone will have to choose for himself. :/

Personally I agree with most of this. I agree that there wasn’t
overwhelming consensus for either LOT=true or LOT=false. However, from
my perspective there was clearly more strong opposition (what would
usually be deemed a NACK in Bitcoin Core review terminology) from
Bitcoin Core contributors, Lightning developers and other community
members against LOT=true than there was for LOT=false. Andrew Chow
tried to summarize views from the meeting in this analysis:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

I am also aware of other current and previous Bitcoin Core
contributors and Lightning developers who didn’t attend the meeting in
person who are opposed to LOT=true. I don’t want to put them in the
spotlight for no reason but if you go through the conversation logs of
not only the meeting but the weeks of discussion prior to this meeting
you will see their views evaluated on the ##taproot-activation
channel. In addition, on taprootactivation.com some mining pools
expressed a preference for lot=false though I don’t know how strong
that preference was.

I am only one voice but it is my current assessment that if we are to
attempt to finalize Taproot activation parameters and propose them to
the community at this time our only option is to propose LOT=false.
Any further delay appears to me counterproductive in our collective
aim to get the Taproot soft fork activated as early as possible.

Obviously others are free to disagree with that assessment and
continue discussions but personally I will be attempting to avoid
those discussions unless prominent new information comes to light or
various specific individuals change their minds.

Next week we are planning a code review of the Bitcoin Core PR #19573
which was initially delayed because of this LOT discussion. As I’ve
said previously that will be loosely following the format of the
Bitcoin Core PR review club and will be lower level and more
technical. That is planned for Tuesday February 23rd at 19:00 UTC on
the IRC channel ##taproot-activation.

Thanks to the meeting participants (and those who joined the
discussion on the channel prior and post the meeting) for engaging
productively and in good faith.

-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-19 22:12 Matt Hill
  2021-02-19 23:30 ` Matt Corallo
  0 siblings, 1 reply; 42+ messages in thread
From: Matt Hill @ 2021-02-19 22:12 UTC (permalink / raw)
  To: bitcoin-dev

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

Good day all, this is my first post to this mailing list. Per Adam's
comment below:

> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Both here and elsewhere, the debate taking place is around the manner of
Taproot activation, not whether or not Taproot should be activated. The
latter seems to have widespread support. Given this favorable environment,
it seems to me this is an incredible opportunity for the developer
contingency to "take the high road" while also minimizing time to Taproot
activation using political incentives. By offering power on the left hand
to miners and and power on the right to users, neither of whom is
expressing disapproval of activation, but both of whom are able to activate
without the consent of the other, both are incentivized to signal
activation as quickly as possible to emerge as the "group that did it". All
that must be done is to include a LOT=true option to Bitcoin Core that
carries a default of LOT=false. Miners can activate at any time, users can
signal their intent to activate should miners renege, and developers emerge
as politically neutral in the eyes of both.

Extrapolating a bit, I contend this expanded agency of full node
operatorship may result in more users running a full node, which is good
and healthy. From a miner's point of view, more full nodes only increases
the likelihood of future UASFs, and so they are even further incentivized
to expedite Taproot activation. Perhaps this is a stretch, perhaps not.

To summarize: (1) this positions developers as neutral facilitators who
deferred power to the other contingencies; (2) we may see a rise in the
popularity of running a full node and the number of full node operators;
(3) miners are incentivized to activate quickly to avoid being perceived as
the "bad guys" and to avoid the spread of full nodes; and (4) even if
miners do not activate, users can organize a UASF in a grass-roots way.

Matt Hill

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

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
@ 2021-02-21 10:10 Prayank
  0 siblings, 0 replies; 42+ messages in thread
From: Prayank @ 2021-02-21 10:10 UTC (permalink / raw)
  To: Bitcoin Dev

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

Hello Everyone,

The below comment by Matt about different implementations and their opinion on `lockinontimeout` is from 18 Feb 2021 communication: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018433.html

> If the eventual outcome is that different implementations (that have material *transaction processing* userbases, and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here and not activate Taproot. Seriously. Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.

I don't agree to the part that 'we should stop and not activate taproot'. Instead it will be helpful if we can educate most of the people about trade-offs involved in both options with some tables, charts etc.

I think its time to use Bitcoin Knots for more projects and also maintain multiple forks of Bitcoin Core. This is not just limited to `LOT=True or False` but few other things and in general its good for decentralization of Bitcoin. Bitcoin Core is used by most of the nodes according to this pie chart: https://luke.dashjr.org/programs/bitcoin/files/charts/software.html however having multiple forks of Bitcoin Core with real usage, more maintainers in different parts of the world (some even anon), few different features, more reviewers, better communication channels etc. will help everyone involved in Bitcoin.

I am working on a project right now which involves multisig, discreet log contracts, liquid etc. Using bitcoin-s for it because I need DLC but still depending on Bitcoin Core in it. Would try Bitcoin Knots and other implementations soon and also have been looking for developers good with C++ and Python, living in India who are interested to maintain a fork of Bitcoin Core with few changes. I had shared about in replies to Amir Taaki's tweet few days back.

--
Prayank


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

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2021-03-02 18:32 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-17 12:51 [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox