<div dir="auto">I think the most important thing is that the configuration setting is advertised if somebody were to query the node for its capabilities.<div dir="auto"><br></div><div dir="auto">Is this the case?</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">That way the default value isn't really the important thing.</div><div dir="auto"><br></div><div dir="auto">There are longstanding and well-known nodes, for example.  Community support and visibility for a UASF is the most important aspect.</div><div dir="auto"><br></div><div dir="auto">I looked over the threads and I don't think I saw the broadcast nature of this setting clearly discussed.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021, 10:10 AM Michael Folkson via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yesterday (February 16th) we held a second meeting on Taproot<br>
activation on IRC which again was open to all. Despite what appeared<br>
to be majority support for LOT=false over LOT=true in the first<br>
meeting I (and others) thought the arguments had not been explored in<br>
depth and that we should have a follow up meeting almost entirely<br>
focused on whether LOT (lockinontimeout) should be set to true or<br>
false.<br>
<br>
The meeting was announced here:<br>
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html" rel="noreferrer noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html</a><br>
<br>
In that mailing list post I outlined the arguments for LOT=true (T1 to<br>
T6) and arguments for LOT=false (F1 to F6) in their strongest form I<br>
could. David Harding responded with an additional argument for<br>
LOT=false (F7) here:<br>
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html" rel="noreferrer noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html</a><br>
<br>
These meetings are very challenging given they are open to all, you<br>
don’t know who will attend and you don’t know most people’s views in<br>
advance. I tried to give time for both the LOT=true arguments and the<br>
LOT=false arguments to be discussed as I knew there was support for<br>
both. We only tried evaluating which had more support and which had<br>
more strong opposition towards the end of the meeting.<br>
<br>
The conversation log is here:<br>
<a href="http://gnusha.org/taproot-activation/2021-02-16.log" rel="noreferrer noreferrer" target="_blank">http://gnusha.org/taproot-activation/2021-02-16.log</a><br>
<br>
(If you are so inclined you can watch a video of the meeting here.<br>
Thanks to the YouTube account “Bitcoin” for setting up the livestream:<br>
<a href="https://www.youtube.com/watch?v=vpl5q1ovMLM" rel="noreferrer noreferrer" target="_blank">https://www.youtube.com/watch?v=vpl5q1ovMLM</a>)<br>
<br>
A summary of the meeting was provided by Luke Dashjr on Mastodon here:<br>
<a href="https://bitcoinhackers.org/@lukedashjr/105742918779234566" rel="noreferrer noreferrer" target="_blank">https://bitcoinhackers.org/@lukedashjr/105742918779234566</a><br>
<br>
Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we<br>
did manage to come to consensus on everything but LockinOnTimeout.<br>
<br>
Activation height range: 693504-745920<br>
<br>
MASF threshold: 1815/2016 blocks (90%)<br>
<br>
Keep in mind only ~100 people showed for the meetings, hardly<br>
representative of the entire community.<br>
<br>
So, these details remain JUST a proposal for now.<br>
<br>
It seems inevitable that there won't be consensus on LOT.<br>
<br>
Everyone will have to choose for himself. :/<br>
<br>
Personally I agree with most of this. I agree that there wasn’t<br>
overwhelming consensus for either LOT=true or LOT=false. However, from<br>
my perspective there was clearly more strong opposition (what would<br>
usually be deemed a NACK in Bitcoin Core review terminology) from<br>
Bitcoin Core contributors, Lightning developers and other community<br>
members against LOT=true than there was for LOT=false. Andrew Chow<br>
tried to summarize views from the meeting in this analysis:<br>
<a href="https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c" rel="noreferrer noreferrer" target="_blank">https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c</a><br>
<br>
I am also aware of other current and previous Bitcoin Core<br>
contributors and Lightning developers who didn’t attend the meeting in<br>
person who are opposed to LOT=true. I don’t want to put them in the<br>
spotlight for no reason but if you go through the conversation logs of<br>
not only the meeting but the weeks of discussion prior to this meeting<br>
you will see their views evaluated on the ##taproot-activation<br>
channel. In addition, on <a href="http://taprootactivation.com" rel="noreferrer noreferrer" target="_blank">taprootactivation.com</a> some mining pools<br>
expressed a preference for lot=false though I don’t know how strong<br>
that preference was.<br>
<br>
I am only one voice but it is my current assessment that if we are to<br>
attempt to finalize Taproot activation parameters and propose them to<br>
the community at this time our only option is to propose LOT=false.<br>
Any further delay appears to me counterproductive in our collective<br>
aim to get the Taproot soft fork activated as early as possible.<br>
<br>
Obviously others are free to disagree with that assessment and<br>
continue discussions but personally I will be attempting to avoid<br>
those discussions unless prominent new information comes to light or<br>
various specific individuals change their minds.<br>
<br>
Next week we are planning a code review of the Bitcoin Core PR #19573<br>
which was initially delayed because of this LOT discussion. As I’ve<br>
said previously that will be loosely following the format of the<br>
Bitcoin Core PR review club and will be lower level and more<br>
technical. That is planned for Tuesday February 23rd at 19:00 UTC on<br>
the IRC channel ##taproot-activation.<br>
<br>
Thanks to the meeting participants (and those who joined the<br>
discussion on the channel prior and post the meeting) for engaging<br>
productively and in good faith.<br>
<br>
-- <br>
Michael Folkson<br>
Email: <a href="mailto:michaelfolkson@gmail.com" target="_blank" rel="noreferrer">michaelfolkson@gmail.com</a><br>
Keybase: michaelfolkson<br>
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank" rel="noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>