{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-18\n📝 Original message:Hi all,\n\nI think it's important for us to consider what is actually being considered\nfor activation here.\n\nThe designation of \"soft fork\" is accurate but I don't think it adequately\nconveys how non-intrusive a change like this is. All that taproot does\n(unless I'm completely missing something) is imbue a previously undefined\nscript version with actual semantics. In order for a chain reorg to take\nplace it would mean that someone would have to have a use case for that\nscript version today. This is something I think that we can easily check by\ndigging through the UTXO set or history. If anyone is using that script\nversion, we absolutely should not be using it, but that doesn't mean that\nwe can't switch to a script version that no one is actually using.\n\nIf no one is even attempting to use the script version, then the change has\nno effect on whether a chain split occurs because there is simply no block\nthat contains a transaction that only some of the network will accept.\n\nFurthermore, I don't know how Bitcoin can stand the test of time if we\nallow developers who rely on \"undefined behavior\" (which the taproot script\nversion presently is) to exert tremendous influence over what code does or\ndoes not get run. This isn't a soft fork that makes some particular UTXO's\nunspendable. It isn't one that bans miners from collecting fees. It is a\nchange that means that certain \"always accept\" transactions actually have\nreal conditions you have to meet. I can't imagine a less intrusive change.\n\nOn the other hand, choosing to let L=F be a somewhat final call sets a very\nreal precedent that 10% of what I estimate to be 1% of bitcoin users can\neffectively block any change from here on forward. At that point we are\nsaying that miners are in control of network consensus in ways they have\nnot been up until now. I don't think this is a more desirable outcome to\nlet ~0.1% of the network get to block *non-intrusive* changes that the rest\nof the network wants.\n\nI can certainly live with an L=F attempt as a way to punt on the\ndiscussion, maybe the activation happens and this will all be fine. But if\nit doesn't, I hardly think that users of Bitcoin are just going to be like\n\"well, guess that's it for Taproot\". I have no idea what ensues at that\npoint, but probably another community led UASF movement.\n\nI wasn't super well educated on this stuff back in '17 when Segwit went\ndown, as I was new at that time, so if I'm missing something please say so.\nBut from my point of view, we can't treat all soft forks as equal.\n\nKeagan\n\nOn Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e We've had several softforks in Bitcoin which, through the course of their\n\u003e activation, had a several-block reorg. That\n\u003e should be indication enough that we need to very carefully consider\n\u003e activation to ensure we reduce the risk of that as\n\u003e much as absolutely possible. Again, while I think Taproot is a huge\n\u003e improvement and am looking forward to being able to\n\u003e use it, getting unlucky and hitting a 4-block reorg that happens to\n\u003e include a double-spend and some PR around an\n\u003e exchange losing millions would be worse than having Taproot is good.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 2/18/21 09:26, Michael Folkson wrote:\n\u003e \u003e Thanks for your response Matt. It is a fair challenge. There is always\n\u003e going to be an element of risk with soft forks,\n\u003e \u003e all we can do is attempt to minimize that risk. I would argue that risk\n\u003e has been minimized for Taproot.\n\u003e \u003e\n\u003e \u003e You know (better than I do in fact) that Bitcoin (and layers built on\n\u003e top of it) greatly benefit from upgrades such as\n\u003e \u003e Taproot. To say we shouldn't do Taproot or any future soft forks because\n\u003e there is a small but real risk of chain splits\n\u003e \u003e I think is shortsighted. Indeed I think even if we collectively decided\n\u003e not to do any future soft fork upgrades ever\n\u003e \u003e again on this mailing list that wouldn't stop soft fork attempts from\n\u003e other people in future.\n\u003e \u003e\n\u003e \u003e I don't think there is anything else we can do to minimize that risk for\n\u003e the Taproot soft fork at this point though I'm\n\u003e \u003e open to ideas. To reiterate that risk will never be zero. I don't think\n\u003e I see Bitcoin as fragile as you seem to (though\n\u003e \u003e admittedly you have a much better understanding than me of what happened\n\u003e in 2017).\n\u003e \u003e\n\u003e \u003e The likely scenario for the Taproot soft fork is LOT turns out to be\n\u003e entirely irrelevant and miners activate Taproot\n\u003e \u003e before it becomes relevant. And even the unlikely worst case scenario\n\u003e would only cause short term disruption and\n\u003e \u003e wouldn't kill Bitcoin long term.\n\u003e \u003e\n\u003e \u003e On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo \u003clf-lists at mattcorallo.com\n\u003e \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e     If the eventual outcome is that different implementations (that have\n\u003e material *transaction processing* userbases,\n\u003e \u003e     and I’m not sure to what extent that’s true with Knots) ship\n\u003e different consensus rules, we should stop here and not\n\u003e \u003e     activate Taproot. Seriously.\n\u003e \u003e\n\u003e \u003e     Bitcoin is a consensus system. The absolute worst outcome at all\n\u003e possible is to have it fall out of consensus.\n\u003e \u003e\n\u003e \u003e     Matt\n\u003e \u003e\n\u003e \u003e\u003e     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e     \n\u003e \u003e\u003e     Right, that is one option. Personally I would prefer a Bitcoin Core\n\u003e release sets LOT=false (based on what I have\n\u003e \u003e\u003e     heard from Bitcoin Core contributors) and a community effort\n\u003e releases a version with LOT=true. I don't think users\n\u003e \u003e\u003e     should be forced to choose something they may have no context on\n\u003e before they are allowed to use Bitcoin Core.\n\u003e \u003e\u003e\n\u003e \u003e\u003e     My current understanding is that roasbeef is planning to set\n\u003e LOT=false on btcd (an alternative protocol\n\u003e \u003e\u003e     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided\n\u003e on Bitcoin Knots.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\n\u003e \u003cmailto:ZmnSCPxj at protonmail.com\u003e\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e         Good morning all,\n\u003e \u003e\u003e\n\u003e \u003e\u003e         \u003e \"An activation mechanism is a consensus change like any other\n\u003e change, can be contentious like any other\n\u003e \u003e\u003e         change, and we must resolve it like any other change. Otherwise\n\u003e we risk arriving at the darkest timeline.\"\n\u003e \u003e\u003e         \u003e\n\u003e \u003e\u003e         \u003e Who's we here?\n\u003e \u003e\u003e         \u003e\n\u003e \u003e\u003e         \u003e Release both and let the network decide.\n\u003e \u003e\u003e\n\u003e \u003e\u003e         A thing that could be done, without mandating either LOT=true\n\u003e or LOT=false, would be to have a release that\n\u003e \u003e\u003e         requires a `taprootlot=1` or `taprootlot=0` and refuses to\n\u003e start if the parameter is not set.\n\u003e \u003e\u003e\n\u003e \u003e\u003e         This assures everyone that neither choice is being forced on\n\u003e users, and instead what is being forced on users,\n\u003e \u003e\u003e         is for users to make that choice themselves.\n\u003e \u003e\u003e\n\u003e \u003e\u003e         Regards,\n\u003e \u003e\u003e         ZmnSCPxj\n\u003e \u003e\u003e\n\u003e \u003e\u003e         \u003e\n\u003e \u003e\u003e         \u003e On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via\n\u003e bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\u003e         \u003e\n\u003e \u003e\u003e         \u003e \u003e Thanks for your response Ariel. It would be useful if you\n\u003e responded to specific points I have made in the\n\u003e \u003e\u003e         mailing list post or at least quote these ephemeral \"people\"\n\u003e you speak of. I don't know if you're responding\n\u003e \u003e\u003e         to conversation on the IRC channel or on social media etc.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e The argument comes from a naive assumption that users\n\u003e MUST upgrade to the choice that is submitted into\n\u003e \u003e\u003e         code. But in fact this isn't true and some voices in this\n\u003e discussion need to be more humble about what users\n\u003e \u003e\u003e         must or must not run.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e I personally have never made this assumption. Of course\n\u003e users aren't forced to run any particular software\n\u003e \u003e\u003e         version, quite the opposite. Defaults set in software versions\n\u003e matter though as many users won't change them.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e Does no one realize that it is a very possible outcome\n\u003e that if LOT=true is released there may be only a\n\u003e \u003e\u003e         handful of people that begin running it while everyone else\n\u003e delays their upgrade (with the very good reason of\n\u003e \u003e\u003e         not getting involved in politics) and a year later those\n\u003e handful of people just become stuck at the moment of\n\u003e \u003e\u003e         MUST_SIGNAL, unable to mine new blocks?\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e It is a possible outcome but the likely outcome is that\n\u003e miners activate Taproot before LOT is even\n\u003e \u003e\u003e         relevant. I think it is prudent to prepare for the unlikely but\n\u003e possible outcome that miners fail to activate\n\u003e \u003e\u003e         and hence have this discussion now rather than be unprepared\n\u003e for that eventuality. If LOT is set to false in a\n\u003e \u003e\u003e         software release there is the possibility (T2 in\n\u003e \u003e\u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html\n\u003e \u003e\u003e         \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html\u003e)\n\u003e of individuals or a\n\u003e \u003e\u003e         proportion of the community changing LOT to true. In that sense\n\u003e setting LOT=false in a software release\n\u003e \u003e\u003e         appears to be no more safe than LOT=true.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e The result: a wasted year of waiting and a minority of\n\u003e people who didn't want to be lenient with miners\n\u003e \u003e\u003e         by default.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e There is the (unlikely but possible) possibility of a\n\u003e wasted year if LOT is set to false and miners fail\n\u003e \u003e\u003e         to activate. I'm not convinced by this perception that LOT=true\n\u003e is antagonistic to miners. I actually think it\n\u003e \u003e\u003e         offers them clarity on what will happen over a year time period\n\u003e and removes the need for coordinated or\n\u003e \u003e\u003e         uncoordinated community UASF efforts on top of LOT=false.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e An activation mechanism is a consensus change like any\n\u003e other change, can be contentious like any other\n\u003e \u003e\u003e         change, and we must resolve it like any other change. Otherwise\n\u003e we risk arriving at the darkest timeline.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e I don't know what you are recommending here to avoid \"this\n\u003e darkest timeline\". Open discussions have\n\u003e \u003e\u003e         occurred and are continuing and in my mailing list post that\n\u003e you responded to **I recommended we propose\n\u003e \u003e\u003e         LOT=false be set in protocol implementations such as Bitcoin\n\u003e Core**. I do think this apocalyptic language\n\u003e \u003e\u003e         isn't particularly helpful. In an open consensus system\n\u003e discussion is healthy, we should prepare for bad or\n\u003e \u003e\u003e         worst case scenarios in advance and doing so is not\n\u003e antagonistic or destructive. Mining pools have pledged\n\u003e \u003e\u003e         support for Taproot but we don't build secure systems based on\n\u003e pledges of support, we build them to minimize\n\u003e \u003e\u003e         trust in any human actors. We can be grateful that people like\n\u003e Alejandro have worked hard on\n\u003e \u003e\u003e         taprootactivation.com \u003chttp://taprootactivation.com\u003e (and this\n\u003e effort has informed the discussion) without\n\u003e \u003e\u003e         taking pledges of support as cast iron guarantees.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e TL;DR It sounds like you agree with my recommendation to\n\u003e set LOT=false in protocol implementations in my\n\u003e \u003e\u003e         email :)\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces \u003c\n\u003e arielluaces at gmail.com\n\u003e \u003e\u003e         \u003cmailto:arielluaces at gmail.com\u003e\u003e wrote:\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e Something what strikes me about the conversation is the\n\u003e emotion surrounding the letters UASF.\n\u003e \u003e\u003e         \u003e \u003e \u003e It appears as if people discuss UASF as if it's a massive\n\u003e tidal wave of support that is inevitable, like\n\u003e \u003e\u003e         we saw during segwit activation. But the actual definition is\n\u003e \"any activation that is not a MASF\".\n\u003e \u003e\u003e         \u003e \u003e \u003e A UASF can consist of a single node, ten nodes, a\n\u003e thousand, half of all nodes, all business' nodes, or\n\u003e \u003e\u003e         even all the non mining nodes. On another dimension it can have\n\u003e zero mining support, 51% support, 49% support,\n\u003e \u003e\u003e         or any support right up against a miner activation threshold.\n\u003e \u003e\u003e         \u003e \u003e \u003e Hell a UASF doesn't even need code or even a single node\n\u003e running as long as it exists as a possibility\n\u003e \u003e\u003e         in people's minds.\n\u003e \u003e\u003e         \u003e \u003e \u003e The only thing a UASF doesn't have is miner support above\n\u003e an agreed activation threshold (some number\n\u003e \u003e\u003e         above %51).\n\u003e \u003e\u003e         \u003e \u003e \u003e I say this because it strikes me when people say that\n\u003e they are for LOT=true with the logic that since a\n\u003e \u003e\u003e         UASF is guaranteed to happen then it's better to just make it\n\u003e default from the beginning. Words like\n\u003e \u003e\u003e         coordination and safety are sometimes sprinkled into the\n\u003e argument.\n\u003e \u003e\u003e         \u003e \u003e \u003e The argument comes from a naive assumption that users\n\u003e MUST upgrade to the choice that is submitted into\n\u003e \u003e\u003e         code. But in fact this isn't true and some voices in this\n\u003e discussion need to be more humble about what users\n\u003e \u003e\u003e         must or must not run.\n\u003e \u003e\u003e         \u003e \u003e \u003e Does no one realize that it is a very possible outcome\n\u003e that if LOT=true is released there may be only a\n\u003e \u003e\u003e         handful of people that begin running it while everyone else\n\u003e delays their upgrade (with the very good reason of\n\u003e \u003e\u003e         not getting involved in politics) and a year later those\n\u003e handful of people just become stuck at the moment of\n\u003e \u003e\u003e         MUST_SIGNAL, unable to mine new blocks? Or attracting a\n\u003e minority of miners, activating, and forking off into a\n\u003e \u003e\u003e         minority fork. Then a lot=false could be started that ends up\n\u003e activating the feature now that the stubborn\n\u003e \u003e\u003e         option has ran its course.\n\u003e \u003e\u003e         \u003e \u003e \u003e The result: a wasted year of waiting and a minority of\n\u003e people who didn't want to be lenient with miners\n\u003e \u003e\u003e         by default. The chains could be called BitcoinLenient and\n\u003e BitcoinStubborn.\n\u003e \u003e\u003e         \u003e \u003e \u003e How is that strictly safer or more coordinated?\n\u003e \u003e\u003e         \u003e \u003e \u003e I may be in the minority, or maybe a silent majority, or\n\u003e maybe a majority that just hasn't considered\n\u003e \u003e\u003e         this as a choice but honestly if there is contention about\n\u003e whether we're going to be stubborn or lenient with\n\u003e \u003e\u003e         miners for Taproot and in the future then I prefer to just not\n\u003e activate anything at all. I'm fine for calling\n\u003e \u003e\u003e         bitcoin ossified, accepting that segwit is Bitcoin's last\n\u003e network upgrade. Taproot is amazing but no new\n\u003e \u003e\u003e         feature is worth a network split down the middle.\n\u003e \u003e\u003e         \u003e \u003e \u003e Maybe in 10 or 20 years, when other blockchains implement\n\u003e features like Taproot and many more, we will\n\u003e \u003e\u003e         become envious enough to put aside our differences on how to\n\u003e behave towards miners and finally activate Taproot.\n\u003e \u003e\u003e         \u003e \u003e \u003e An activation mechanism is a consensus change like any\n\u003e other change, can be contentious like any other\n\u003e \u003e\u003e         change, and we must resolve it like any other change. Otherwise\n\u003e we risk arriving at the darkest timeline.\n\u003e \u003e\u003e         \u003e \u003e \u003e Cheers\n\u003e \u003e\u003e         \u003e \u003e \u003e Ariel Lorenzo-Luaces\n\u003e \u003e\u003e         \u003e \u003e \u003e On Feb 17, 2021, at 7:05 AM, Michael Folkson via\n\u003e bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e         \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\u003e         \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Yesterday (February 16th) we held a second meeting on\n\u003e Taproot\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e activation on IRC which again was open to all. Despite\n\u003e what appeared\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e to be majority support for LOT=false over LOT=true in\n\u003e the first\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e meeting I (and others) thought the arguments had not\n\u003e been explored in\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e depth and that we should have a follow up meeting\n\u003e almost entirely\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e focused on whether LOT (lockinontimeout) should be set\n\u003e to true or\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e false.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e The meeting was announced here:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html\n\u003e \u003e\u003e         \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html\n\u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e In that mailing list post I outlined the arguments for\n\u003e LOT=true (T1 to\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e T6) and arguments for LOT=false (F1 to F6) in their\n\u003e strongest form I\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e could. David Harding responded with an additional\n\u003e argument for\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e LOT=false (F7) here:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html\n\u003e \u003e\u003e         \u003c\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html\n\u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e These meetings are very challenging given they are open\n\u003e to all, you\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e don’t know who will attend and you don’t know most\n\u003e people’s views in\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e advance. I tried to give time for both the LOT=true\n\u003e arguments and the\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e LOT=false arguments to be discussed as I knew there was\n\u003e support for\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e both. We only tried evaluating which had more support\n\u003e and which had\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e more strong opposition towards the end of the meeting.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e The conversation log is here:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e http://gnusha.org/taproot-activation/2021-02-16.log \u003c\n\u003e http://gnusha.org/taproot-activation/2021-02-16.log\u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e (If you are so inclined you can watch a video of the\n\u003e meeting here.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Thanks to the YouTube account “Bitcoin” for setting up\n\u003e the livestream:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e https://www.youtube.com/watch?v=vpl5q1ovMLM \u003c\n\u003e https://www.youtube.com/watch?v=vpl5q1ovMLM\u003e)\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e A summary of the meeting was provided by Luke Dashjr on\n\u003e Mastodon here:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e https://bitcoinhackers.org/@lukedashjr/105742918779234566\n\u003e \u003e\u003e         \u003chttps://bitcoinhackers.org/@lukedashjr/105742918779234566\u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Today's #Bitcoin #Taproot meeting was IMO largely\n\u003e unproductive, but we\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e did manage to come to consensus on everything but\n\u003e LockinOnTimeout.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Activation height range: 693504-745920\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e MASF threshold: 1815/2016 blocks (90%)\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Keep in mind only ~100 people showed for the meetings,\n\u003e hardly\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e representative of the entire community.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e So, these details remain JUST a proposal for now.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e It seems inevitable that there won't be consensus on\n\u003e LOT.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Everyone will have to choose for himself. :/\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Personally I agree with most of this. I agree that\n\u003e there wasn’t\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e overwhelming consensus for either LOT=true or\n\u003e LOT=false. However, from\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e my perspective there was clearly more strong opposition\n\u003e (what would\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e usually be deemed a NACK in Bitcoin Core review\n\u003e terminology) from\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Bitcoin Core contributors, Lightning developers and\n\u003e other community\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e members against LOT=true than there was for LOT=false.\n\u003e Andrew Chow\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e tried to summarize views from the meeting in this\n\u003e analysis:\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c\n\u003e \u003e\u003e         \u003c\n\u003e https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c\u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e I am also aware of other current and previous Bitcoin\n\u003e Core\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e contributors and Lightning developers who didn’t attend\n\u003e the meeting in\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e person who are opposed to LOT=true. I don’t want to put\n\u003e them in the\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e spotlight for no reason but if you go through the\n\u003e conversation logs of\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e not only the meeting but the weeks of discussion prior\n\u003e to this meeting\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e you will see their views evaluated on the\n\u003e ##taproot-activation\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e channel. In addition, on taprootactivation.com \u003c\n\u003e http://taprootactivation.com\u003e some mining pools\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e expressed a preference for lot=false though I don’t\n\u003e know how strong\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e that preference was.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e I am only one voice but it is my current assessment\n\u003e that if we are to\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e attempt to finalize Taproot activation parameters and\n\u003e propose them to\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e the community at this time our only option is to\n\u003e propose LOT=false.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Any further delay appears to me counterproductive in\n\u003e our collective\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e aim to get the Taproot soft fork activated as early as\n\u003e possible.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Obviously others are free to disagree with that\n\u003e assessment and\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e continue discussions but personally I will be\n\u003e attempting to avoid\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e those discussions unless prominent new information\n\u003e comes to light or\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e various specific individuals change their minds.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Next week we are planning a code review of the Bitcoin\n\u003e Core PR #19573\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e which was initially delayed because of this LOT\n\u003e discussion. As I’ve\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e said previously that will be loosely following the\n\u003e format of the\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Bitcoin Core PR review club and will be lower level and\n\u003e more\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e technical. That is planned for Tuesday February 23rd at\n\u003e 19:00 UTC on\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e the IRC channel ##taproot-activation.\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e Thanks to the meeting participants (and those who\n\u003e joined the\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e discussion on the channel prior and post the meeting)\n\u003e for engaging\n\u003e \u003e\u003e         \u003e \u003e \u003e \u003e productively and in good faith.\n\u003e \u003e\u003e         \u003e \u003e\n\u003e \u003e\u003e         \u003e \u003e --\n\u003e \u003e\u003e         \u003e \u003e Michael Folkson\n\u003e \u003e\u003e         \u003e \u003e Email: michaelfolkson at gmail.com \u003cmailto:\n\u003e michaelfolkson at gmail.com\u003e\n\u003e \u003e\u003e         \u003e \u003e Keybase: michaelfolkson\n\u003e \u003e\u003e         \u003e \u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e \u003e\u003e         \u003e \u003e _______________________________________________\n\u003e \u003e\u003e         \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e\u003e         \u003e \u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e \u003e\u003e         \u003e \u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e         \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e     --\n\u003e \u003e\u003e     Michael Folkson\n\u003e \u003e\u003e     Email: michaelfolkson at gmail.com \u003cmailto:michaelfolkson at gmail.com\u003e\n\u003e \u003e\u003e     Keybase: michaelfolkson\n\u003e \u003e\u003e     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e \u003e\u003e     _______________________________________________\n\u003e \u003e\u003e     bitcoin-dev mailing list\n\u003e \u003e\u003e     bitcoin-dev at lists.linuxfoundation.org \u003cmailto:\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e \u003e\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e     \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Michael Folkson\n\u003e \u003e Email: michaelfolkson at gmail.com \u003cmailto:michaelfolkson at gmail.com\u003e\n\u003e \u003e Keybase: michaelfolkson\n\u003e \u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210218/a2f47541/attachment-0001.html\u003e"}