rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2021-02-19 📝 Original message:Good morning list, > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should > be designed, this doesn't imply anything about the consensus code which represents the activation thereof. > > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one > which almost certainly carries significantly more risk than Taproot. > > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority > of Bitcoin users and is only not activating due to lagging miner upgrades. Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing). Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out. The issue is that those people will get forked off the network at the end of this particular deployment attempt. I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode. ("Never again" for some people) How do we convince them to go run LOT=false instead of getting themselves forked off? Or do we simply let them? (and how is that different from asking each user to decide on LOT=false/true right now?) ("reasonable default"?) (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.) Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"? Why or why not? Regards, ZmnSCPxj > Matt > > On 2/18/21 10:04, Keagan McClelland wrote: > > > Hi all, > > I think it's important for us to consider what is actually being considered for activation here. > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for > > that script version today. This is something I think that we can easily check by digging through the UTXO set or > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we > > can't switch to a script version that no one is actually using. > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs > > because there is simply no block that contains a transaction that only some of the network will accept. > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior" > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run. > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to > > meet. I can't imagine a less intrusive change. > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants. > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement. > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm > > missing something please say so. But from my point of view, we can't treat all soft forks as equal. > > Keagan > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org > > mailto:bitcoin-dev at lists.linuxfoundation.org> wrote: > > > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That > > should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as > > much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to > > use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an > > exchange losing millions would be worse than having Taproot is good. > > > > Matt > > > > On 2/18/21 09:26, Michael Folkson wrote: > > > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft > > forks, > > > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot. > > > > > > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades > > such as > > > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain > > splits > > > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever > > > again on this mailing list that wouldn't stop soft fork attempts from other people in future. > > > > > > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point > > though I'm > > > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to > > (though > > > admittedly you have a much better understanding than me of what happened in 2017). > > > > > > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot > > > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and > > > wouldn't kill Bitcoin long term. > > > > > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com> > > <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>>> wrote: > > > > > >     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. > > > > > >     Matt > > > > > >>     On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org > > <mailto:bitcoin-dev at lists.linuxfoundation.org> > > >>     <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote: > > >> > > >>      > > >>     Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have > > >>     heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think > > users > > >>     should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core. > > >> > > >>     My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol > > >>     implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots. > > >> > > >> > > >> > > >>     On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com> > > <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>>> wrote: > > >> > > >>         Good morning all, > > >> > > >>         > "An 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." > > >>         > > > >>         > Who's we here? > > >>         > > > >>         > Release both and let the network decide. > > >> > > >>         A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that > > >>         requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set. > > >> > > >>         This assures everyone that neither choice is being forced on users, and instead what is being forced on > > users, > > >>         is for users to make that choice themselves. > > >> > > >>         Regards, > > >>         ZmnSCPxj > > >> > > >>         > > > >>         > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org > > <mailto:bitcoin-dev at lists.linuxfoundation.org> > > >>         <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote: > > >>         > > > >>         > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made > > in the > > >>         mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding > > >>         to conversation on the IRC channel or on social media etc. > > >>         > > > > >>         > > > The 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. > > >>         > > > > >>         > > I personally have never made this assumption. Of course users aren't forced to run any particular > > software > > >>         version, quite the opposite. Defaults set in software versions matter though as many users won't change > > them. > > >>         > > > > >>         > > > Does 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? > > >>         > > > > >>         > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even > > >>         relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to > > activate > > >>         and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to > > false in a > > >>         software release there is the possibility (T2 in > > >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html> > > >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>) of individuals or a > > >>         proportion of the community changing LOT to true. In that sense setting LOT=false in a software release > > >>         appears to be no more safe than LOT=true. > > >>         > > > > >>         > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with > > miners > > >>         by default. > > >>         > > > > >>         > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail > > >>         to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually > > think it > > >>         offers them clarity on what will happen over a year time period and removes the need for coordinated or > > >>         uncoordinated community UASF efforts on top of LOT=false. > > >>         > > > > >>         > > > An 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. > > >>         > > > > >>         > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have > > >>         occurred and are continuing and in my mailing list post that you responded to **I recommended we propose > > >>         LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language > > >>         isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or > > >>         worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged > > >>         support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize > > >>         trust in any human actors. We can be grateful that people like Alejandro have worked hard on > > >> taprootactivation.com <http://taprootactivation.com> <http://taprootactivation.com > > <http://taprootactivation.com>> (and this effort has informed the discussion) without > > >>         taking pledges of support as cast iron guarantees. > > >>         > > > > >>         > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my > > >>         email :) > > >>         > > > > >>         > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces at gmail.com > > <mailto:arielluaces at gmail.com> > > >>         <mailto:arielluaces at gmail.com <mailto:arielluaces at gmail.com>>> wrote: > > >>         > > > > >>         > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF. > > >>         > > > It 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". > > >>         > > > A 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. > > >>         > > > Hell 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. > > >>         > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number > > >>         above %51). > > >>         > > > I 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. > > >>         > > > The 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. > > >>         > > > Does 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. > > >>         > > > The 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. > > >>         > > > How is that strictly safer or more coordinated? > > >>         > > > I 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. > > >>         > > > Maybe 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. > > >>         > > > An 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. > > >>         > > > Cheers > > >>         > > > Ariel Lorenzo-Luaces > > >>         > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev > > <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > > >>         <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote: > > >>         > > > > > >>         > > > > 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 > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html> > > >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html > > <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 > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html> > > >>         <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html > > <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 > > <http://gnusha.org/taproot-activation/2021-02-16.log> <http://gnusha.org/taproot-activation/2021-02-16.log > > <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 <https://www.youtube.com/watch?v=vpl5q1ovMLM> > > <https://www.youtube.com/watch?v=vpl5q1ovMLM <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 > > <https://bitcoinhackers.org/@lukedashjr/105742918779234566> > > >>         <https://bitcoinhackers.org/@lukedashjr/105742918779234566 > > <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 > > <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c> > > >>         <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c > > <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 <http://taprootactivation.com> > > <http://taprootactivation.com <http://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 at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com > > <mailto:michaelfolkson at gmail.com>> > > >>         > > Keybase: michaelfolkson > > >>         > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > >>         > > _______________________________________________ > > >>         > > bitcoin-dev mailing list > > >>         > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> > > >>         > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > >>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> > > >> > > >> > > >> > > >> > > >>     -- > > >>     Michael Folkson > > >>     Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com > > <mailto:michaelfolkson at gmail.com>> > > >>     Keybase: michaelfolkson > > >>     PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > >>     _______________________________________________ > > >>     bitcoin-dev mailing list > > >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> > > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > >>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> > > > > > > > > > > > > -- > > > Michael Folkson > > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com > > <mailto:michaelfolkson at gmail.com>> > > > Keybase: michaelfolkson > > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev