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@lists.linuxfoundation.org
> > mailto:bitcoin-dev@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-li...@mattcorallo.com <mailto:lf-li...@mattcorallo.com>
> > <mailto:lf-li...@mattcorallo.com <mailto:lf-li...@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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > >> <mailto:bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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
> > <zmnsc...@protonmail.com <mailto:zmnsc...@protonmail.com>
> > <mailto:zmnsc...@protonmail.com <mailto:zmnsc...@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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > >> <mailto:bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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
> > <ariellua...@gmail.com
> > <mailto:ariellua...@gmail.com>
> > >> <mailto:ariellua...@gmail.com
> > <mailto:ariellua...@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@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > >> <mailto:bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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: michaelfolk...@gmail.com
> > <mailto:michaelfolk...@gmail.com> <mailto:michaelfolk...@gmail.com
> > <mailto:michaelfolk...@gmail.com>>
> > >> > > Keybase: michaelfolkson
> > >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > >> > > _______________________________________________
> > >> > > bitcoin-dev mailing list
> > >> > > bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > <mailto:bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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: michaelfolk...@gmail.com
> > <mailto:michaelfolk...@gmail.com> <mailto:michaelfolk...@gmail.com
> > <mailto:michaelfolk...@gmail.com>>
> > >> Keybase: michaelfolkson
> > >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > >> _______________________________________________
> > >> bitcoin-dev mailing list
> > >> bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > <mailto:bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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: michaelfolk...@gmail.com <mailto:michaelfolk...@gmail.com>
> > <mailto:michaelfolk...@gmail.com
> > <mailto:michaelfolk...@gmail.com>>
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
