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