{"type":"rich","version":"1.0","author_name":"npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlpha","author_url":"https://nostr.ae/npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlpha","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-18\n📝 Original message:Something what strikes me about the conversation is the emotion surrounding the letters UASF.\n\nIt appears as if people discuss UASF as if it's a massive tidal wave of support that is inevitable, like we saw during segwit activation. But the actual definition is \"any activation that is not a MASF\".\n\nA UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49% support, or any support right up against a miner activation threshold.\n\nHell a UASF doesn't even need code or even a single node running as long as it exists as a possibility in people's minds.\n\nThe only thing a UASF doesn't have is miner support above an agreed activation threshold (some number above %51).\n\nI say this because it strikes me when people say that they are for LOT=true with the logic that since a UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like coordination and safety are sometimes sprinkled into the argument.\n\nThe argument comes from a naive assumption that users MUST upgrade to the choice that is submitted into code. But in fact this isn't true and some voices in this discussion need to be more humble about what users must or must not run.\n\nDoes no one realize that it is a very possible outcome that if LOT=true is released there may be only a handful of people that begin running it while everyone else delays their upgrade (with the very good reason of not getting involved in politics) and a year later those handful of people just become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off into a minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn option has ran its course.\nThe result: a wasted year of waiting and a minority of people who didn't want to be lenient with miners by default. The chains could be called BitcoinLenient and BitcoinStubborn.\nHow is that strictly safer or more coordinated?\n\nI may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient with miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for calling bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new feature is worth a network split down the middle.\n\nMaybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will become envious enough to put aside our differences on how to behave towards miners and finally activate Taproot.\n\nAn activation mechanism is a consensus change like any other change, can be contentious like any other change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.\n\nCheers\nAriel Lorenzo-Luaces\n\n\nOn Feb 17, 2021, 7:05 AM, at 7:05 AM, Michael Folkson via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eYesterday (February 16th) we held a second meeting on Taproot\n\u003eactivation on IRC which again was open to all. Despite what appeared\n\u003eto be majority support for LOT=false over LOT=true in the first\n\u003emeeting I (and others) thought the arguments had not been explored in\n\u003edepth and that we should have a follow up meeting almost entirely\n\u003efocused on whether LOT (lockinontimeout) should be set to true or\n\u003efalse.\n\u003e\n\u003eThe meeting was announced here:\n\u003ehttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html\n\u003e\n\u003eIn that mailing list post I outlined the arguments for LOT=true (T1 to\n\u003eT6) and arguments for LOT=false (F1 to F6) in their strongest form I\n\u003ecould. David Harding responded with an additional argument for\n\u003eLOT=false (F7) here:\n\u003ehttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html\n\u003e\n\u003eThese meetings are very challenging given they are open to all, you\n\u003edon’t know who will attend and you don’t know most people’s views in\n\u003eadvance. I tried to give time for both the LOT=true arguments and the\n\u003eLOT=false arguments to be discussed as I knew there was support for\n\u003eboth. We only tried evaluating which had more support and which had\n\u003emore strong opposition towards the end of the meeting.\n\u003e\n\u003eThe conversation log is here:\n\u003ehttp://gnusha.org/taproot-activation/2021-02-16.log\n\u003e\n\u003e(If you are so inclined you can watch a video of the meeting here.\n\u003eThanks to the YouTube account “Bitcoin” for setting up the livestream:\n\u003ehttps://www.youtube.com/watch?v=vpl5q1ovMLM)\n\u003e\n\u003eA summary of the meeting was provided by Luke Dashjr on Mastodon here:\n\u003ehttps://bitcoinhackers.org/@lukedashjr/105742918779234566\n\u003e\n\u003eToday's #Bitcoin #Taproot meeting was IMO largely unproductive, but we\n\u003edid manage to come to consensus on everything but LockinOnTimeout.\n\u003e\n\u003eActivation height range: 693504-745920\n\u003e\n\u003eMASF threshold: 1815/2016 blocks (90%)\n\u003e\n\u003eKeep in mind only ~100 people showed for the meetings, hardly\n\u003erepresentative of the entire community.\n\u003e\n\u003eSo, these details remain JUST a proposal for now.\n\u003e\n\u003eIt seems inevitable that there won't be consensus on LOT.\n\u003e\n\u003eEveryone will have to choose for himself. :/\n\u003e\n\u003ePersonally I agree with most of this. I agree that there wasn’t\n\u003eoverwhelming consensus for either LOT=true or LOT=false. However, from\n\u003emy perspective there was clearly more strong opposition (what would\n\u003eusually be deemed a NACK in Bitcoin Core review terminology) from\n\u003eBitcoin Core contributors, Lightning developers and other community\n\u003emembers against LOT=true than there was for LOT=false. Andrew Chow\n\u003etried to summarize views from the meeting in this analysis:\n\u003ehttps://gist.github.com/achow101/3e179501290abb7049de198d46894c7c\n\u003e\n\u003eI am also aware of other current and previous Bitcoin Core\n\u003econtributors and Lightning developers who didn’t attend the meeting in\n\u003eperson who are opposed to LOT=true. I don’t want to put them in the\n\u003espotlight for no reason but if you go through the conversation logs of\n\u003enot only the meeting but the weeks of discussion prior to this meeting\n\u003eyou will see their views evaluated on the ##taproot-activation\n\u003echannel. In addition, on taprootactivation.com some mining pools\n\u003eexpressed a preference for lot=false though I don’t know how strong\n\u003ethat preference was.\n\u003e\n\u003eI am only one voice but it is my current assessment that if we are to\n\u003eattempt to finalize Taproot activation parameters and propose them to\n\u003ethe community at this time our only option is to propose LOT=false.\n\u003eAny further delay appears to me counterproductive in our collective\n\u003eaim to get the Taproot soft fork activated as early as possible.\n\u003e\n\u003eObviously others are free to disagree with that assessment and\n\u003econtinue discussions but personally I will be attempting to avoid\n\u003ethose discussions unless prominent new information comes to light or\n\u003evarious specific individuals change their minds.\n\u003e\n\u003eNext week we are planning a code review of the Bitcoin Core PR #19573\n\u003ewhich was initially delayed because of this LOT discussion. As I’ve\n\u003esaid previously that will be loosely following the format of the\n\u003eBitcoin Core PR review club and will be lower level and more\n\u003etechnical. That is planned for Tuesday February 23rd at 19:00 UTC on\n\u003ethe IRC channel ##taproot-activation.\n\u003e\n\u003eThanks to the meeting participants (and those who joined the\n\u003ediscussion on the channel prior and post the meeting) for engaging\n\u003eproductively and in good faith.\n\u003e\n\u003e-- \n\u003eMichael Folkson\n\u003eEmail: michaelfolkson at gmail.com\n\u003eKeybase: michaelfolkson\n\u003ePGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210217/689747ce/attachment-0001.html\u003e"}