Delivery-date: Sun, 21 Apr 2024 10:59:09 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) client-ip=2a00:1450:4864:20::42b;
MIME-Version: 1.0
References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com>
 <CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e=CGHGuSCgm+-4WxT9w@mail.gmail.com>
 <fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com> <070755a0-10e9-4903-9524-dd8ef98c1c8b@achow101.com>
 <CABu3BAeYqzp439z8Ug6_4QdhvSQ0fCysz-t2h1zzp2pX6Hsebg@mail.gmail.com>
 <0d4d85e3-9fbb-4bd4-af0f-92225e699b63@achow101.com> <CAFvNmHSH4aPvP88wJHg4uwSmRZS7iJxVaOYhamz5L4yPx7GsYg@mail.gmail.com>
 <97a10141-8847-417a-af11-d95e7d3be064@achow101.com> <CAFvNmHQVrzrmodRV1QUC3Ft39XEMW18YsfiZu_GTTnVde=nd_w@mail.gmail.com>
 <0591e62d-12da-48ac-9d19-faea473c647c@achow101.com>
In-Reply-To: <0591e62d-12da-48ac-9d19-faea473c647c@achow101.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Sun, 21 Apr 2024 18:57:39 +0100
Message-ID: <CAFvNmHTgfwSx-kNzHSFW_7HWfOG1yupJQGZqXWzG47i=-DjSsA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
To: Ava Chow <lists@achow101.com>
Cc: bitcoindev@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

> You are misunderstanding the role of BIP editors. They are not arbiters
of what is activated on Bitcoin. They are not gatekeepers of soft forks.
If a BIP author proposes or agrees with a change to their BIP and those
changes are formatted correctly, it is not the BIP editors' rights nor
responsibilities to refuse to merge that change. As with Bitcoin Core
maintainers, BIP editing is a largely janitorial role.

So once a BIP number is allocated (or before) the BIP author can write
whatever they like on that BIP? Including false and misleading
statements? And the BIP editors have to merge it as long as it meets
formatting requirements?

A misleading statement like "This soft fork will definitely activate
at block X as it has been merged into implementation Y. It hasn't been
merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
after the activation"

This is a step change from before. If we aren't relying on *any*
judgment then there might as well be 100 BIP editors. Because the
editors aren't doing anything, each BIP author (or champion) has total
license to write whatever they like on their BIP.

> They are not arbiters of what is activated on Bitcoin. They are not gatek=
eepers of soft forks.

Of course not. The BIP editors do not decide what is activated on
Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
and don't include false and misleading statements. Because false and
misleading statements can impact the evolution of an activation
process.

I tried. Based on your perspective all we need is one malicious BIP
author (or champion) and they'll make the entire BIP process a joke
and the BIP editors won't be able to do anything.

Michael


On Sun, Apr 21, 2024 at 5:39=E2=80=AFPM Ava Chow <lists@achow101.com> wrote=
:
>
> You are misunderstanding the role of BIP editors. They are not arbiters
> of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> If a BIP author proposes or agrees with a change to their BIP and those
> changes are formatted correctly, it is not the BIP editors' rights nor
> responsibilities to refuse to merge that change. As with Bitcoin Core
> maintainers, BIP editing is a largely janitorial role.
>
> Just because something is a BIP does not mean it is a good idea. Just
> because a BIP specifying a fork contains deployment parameters does not
> mean it will actually be deployed. There are several BIPs for both hard
> and soft forks that are rejected or withdrawn that have deployment
> parameters.
>
> Furthermore, for myself, I would actually prefer that contentious soft
> forks for which some people are legitimately attempting to activate have
> their deployment parameters be specified in a/the BIP. Having competing
> activation parameters in different BIPs is preferable over the
> documentation being spread around in many different places. It makes it
> much easier for implementations to inform users what they've actually
> implemented so that users can make a more informed decision.
>
> On 04/21/2024 07:43 AM, Michael Folkson wrote:
> > Ava
> >
> > Thanks for the detailed response, I appreciate the insight.
> >
> >>> I'm even more concerned about future soft fork activation attempts.
> >>> These don't necessarily need to be attempted via a Bitcoin Core merge=
d
> >>> pull request hence the BIPs repo could be a key source of information
> >>> and guidance on this.
> >
> >> This concern doesn't make any sense. There are already multiple soft a=
nd
> >> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >> to be a good idea.
> >
> > I would hope that a contentious soft fork and activation params for
> > that contentious soft fork would not be merged into the Bitcoin Core
> > codebase and up until now it hasn't been. I would hope all the Bitcoin
> > Core maintainers understand that even if they personally think a soft
> > fork is a good idea (apparently there is nothing to stop them merging
> > it without discussing it with the other maintainers) that they
> > shouldn't independently merge it if it is contentious.
> >
> > Similarly I would hope that all BIP editors would be careful about
> > what information gets merged around soft fork activation *attempts*
> > whether that be activation details on a particular soft fork BIP or on
> > a separate activation BIP. With Taproot there were very strong
> > disagreements over activation parameters for a non-contentious soft
> > fork. It would be much messier for a contentious soft fork activation
> > attempt. I'm not sure all these new BIP editors understand that or
> > would perhaps even agree with that. For example Laolu is listed as a
> > supporter of a CTV activation attempt back in 2022 [0] which was
> > clearly contentious. That doesn't inspire me with confidence that as
> > soon as he is a BIP editor he won't start merging details on
> > contentious soft fork activation attempts in BIPs and merging that
> > soft fork in say btcd. He would need to be removed as a BIP editor if
> > he were to do something like that.
> >
> > Thanks
> > Michael
> >
> > [0]: https://utxos.org/signals/
> >
> >
> >
> > On Sun, Apr 21, 2024 at 12:05=E2=80=AFAM Ava Chow <lists@achow101.com> =
wrote:
> >>
> >>
> >> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> >>> It is inevitable there will be a "revert war" unless they all have to
> >>> agree on merge decisions or communicate prior to merging. It is just =
a
> >>> matter of time. Does for example Ordinal Numbers get a BIP number? I
> >>> suspect all the new BIP editors won't agree on that.
> >>
> >> Why do you think that a revert war is inevitable?
> >>
> >> The Bitcoin Core repo operates in a similar way - the maintainers are
> >> independent and work autonomously. The maintainers do not have to agre=
e
> >> on merge decisions nor do they communicate prior to merging. If there'=
s
> >> disagreement about a merge decision, we talk to each other about it li=
ke
> >> adults and come to a mutually agreeable resolution. I don't think
> >> there's ever been a revert war in the history of Bitcoin.
> >>
> >> I would expect that when there is something that is likely to be
> >> controversial or is ambiguous that it should be a BIP that they would
> >> then talk to each other about it. It doesn't have to be all or nothing=
 -
> >> they can do most work without communicating, but when there's question=
s
> >> or ambiguity, then they communicate.
> >>
> >>> Who is to blame in a "revert war" if each editor is free to merge
> >>> whatever pull request they like? The editor who merged it? Why should
> >>> they be removed as an editor for merging a pull request when they fin=
d
> >>> out later a different editor disagreed with that merge decision and
> >>> wants to revert the merge?
> >>
> >> A revert war would be someone merging a PR that reverts another, then
> >> someone else (opening then) merging a PR that reverts that, and it goe=
s
> >> back and forth. It would not be limited to PRs only. This would likely
> >> be super obvious too that they are controversially merging things as I
> >> would be surprised if other BIP editors didn't comment on any of those
> >> actions, besides the fact that many people do also watch the BIPs repo=
.
> >> Regardless, the blame is on those who are doing the reverting, and wou=
ld
> >> be both sides.
> >>
> >>> I'm even more concerned about future soft fork activation attempts.
> >>> These don't necessarily need to be attempted via a Bitcoin Core merge=
d
> >>> pull request hence the BIPs repo could be a key source of information
> >>> and guidance on this.
> >>
> >> This concern doesn't make any sense. There are already multiple soft a=
nd
> >> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >> to be a good idea.
> >>
> >>> I've seen Wladimir is contributing again to Core. Is there a plan to
> >>> give him commit access again?
> >>
> >> It would have to be through the typical maintainer process, although I
> >> doubt that he even wants it. But that's completely orthogonal to the
> >> BIPs repo discussion.
> >>
> >>> I'd be more comfortable with him
> >>> overseeing things in the various repos under the Bitcoin Core
> >>> (/bitcoin) GitHub org as it sounds like you don't really care if the
> >>> BIPs repo degenerates into a free for all.
> >>
> >> I don't understand why you assume that.
> >>
> >> I've said this before, but if I see a revert war going on in the BIPs
> >> repo, I will remove those involved immediately and make a thread on th=
e
> >> list to discuss what to do about them. But I doubt that's a scenario
> >> that will actually come to pass.
> >>
> >> Ava
> >>
> >>>
> >>> Thanks
> >>> Michael
> >>>
> >>> On Sat, Apr 20, 2024 at 10:15=E2=80=AFPM 'Ava Chow' via Bitcoin Devel=
opment
> >>> Mailing List <bitcoindev@googlegroups.com> wrote:
> >>>>
> >>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>>>> Wasn't there evidence provided that Kanzure does not want this
> >>>>> responsibility without being paid?
> >>>>
> >>>> I am not aware of that, and it hasn't come up when I've talked to hi=
m
> >>>> about being a BIPs editor.
> >>>>
> >>>>> I'm confused by this process that we don't even ask the people if t=
hey
> >>>>> want the responsibility? I think only Laolu has chimed in to commit=
 to it?
> >>>>
> >>>> Personally, I've spoken to all 5 privately and they've all confirmed=
 to
> >>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2=
]
> >>>> have also replied to this thread about this.
> >>>>
> >>>> Ava
> >>>>
> >>>> [1]:
> >>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0b=
bn@googlegroups.com/
> >>>> [2]:
> >>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e77=
8@murch.one/
> >>>>
> >>>>>
> >>>>> On Sat, Apr 20, 2024 at 12:30=E2=80=AFPM 'Ava Chow' via Bitcoin Dev=
elopment
> >>>>> Mailing List <bitcoindev@googlegroups.com
> >>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>>>
> >>>>>       Since we're now past the deadline of April 19th, I'd like to =
inform
> >>>>>       everyone of what will happen on Monday.
> >>>>>
> >>>>>       There has not been any actual objections to the nominees nor =
have there
> >>>>>       been any suggestions on choosing a subset of them since my la=
st email.
> >>>>>       As such, there is rough consensus on adding Kanzure, Murch, J=
onatack,
> >>>>>       Ruben, and Roasbeef as BIP editors, and they will be added on=
 Monday
> >>>>>       April 22nd.
> >>>>>
> >>>>>       Ava
> >>>>>
> >>>>>       On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Ma=
iling List
> >>>>>       wrote:
> >>>>>        > While I don't disagree that 5 or 6 people seems like a lot=
 to add at
> >>>>>        > once, it's not clear to me how we should decide which subs=
et of the
> >>>>>        > nominees should be added. As it is now, I have only seen a=
n actual
> >>>>>        > objection to Kanzure and Ruben from /dev/fd0, and no expli=
cit
> >>>>>       objections
> >>>>>        > to anyone else. It seems like the vast majority of people =
don't share
> >>>>>        > their concerns either as both Kanzure and Ruben continue t=
o be
> >>>>>       endorsed
> >>>>>        > by many others.
> >>>>>        >
> >>>>>        > Looking at the endorsements each candidate has received, t=
he current
> >>>>>        > counts are:
> >>>>>        > * Kanzure - 17 for, 1 against
> >>>>>        > * Murch - 13 for
> >>>>>        > * Jonatack - 13 for
> >>>>>        > * Ruben - 12 for, 1 against
> >>>>>        > * Roasbeef - 9 for
> >>>>>        > * Michael Folkson - none
> >>>>>        >
> >>>>>        > However, I don't want this process to become a popularity =
contest and
> >>>>>        > require some kind of formal voting. Rather I'd prefer that=
 this
> >>>>>       process
> >>>>>        > be something more like how Bitcoin Core maintainers are ad=
ded - by
> >>>>>        > achieving rough consensus. Without any explicit objections=
 to any of
> >>>>>        > these candidates, I'm inclined to move forward with adding=
 the 5 who
> >>>>>        > have received endorsements. Having to pick "winners" from =
this list
> >>>>>        > seems like a quick way to stir up drama that I don't think=
 anyone
> >>>>>       really
> >>>>>        > wants to deal with.
> >>>>>        >
> >>>>>        > I do want to note that neither Kanzure, Ruben, nor Roasbee=
f have
> >>>>>       posted
> >>>>>        > on this list that they are willing to be BIP editors. I ha=
ve
> >>>>>       reached out
> >>>>>        > to all 3 of them privately, and received responses from Ka=
nzure and
> >>>>>        > Ruben that indicate that they probably are willing, but pu=
blic
> >>>>>        > confirmation from them on this list would also be nice. I =
have not
> >>>>>        > received a response from Roasbeef.
> >>>>>        >
> >>>>>        > Ava
> >>>>>        >
> >>>>>        > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>>>        >>   > I would prefer having more (9+?) than less folks on t=
his
> >>>>>       task, so
> >>>>>        >> personal preferences are easily ignored and overwritten b=
y the group
> >>>>>        >> majority.
> >>>>>        >>
> >>>>>        >> I disagree with that, the more doesn't really the better =
here.
> >>>>>       Having
> >>>>>        >> too many editors may result in a tragedy of the commons, =
in
> >>>>>       which people
> >>>>>        >> just commit to the job because many others do, and they d=
o not
> >>>>>       end up
> >>>>>        >> doing as much because they expect others to do the it. Th=
is does not
> >>>>>        >> only make the process look bad but may burnout the ones t=
hat end up
> >>>>>        >> doing the job, given their time commitment ends up being =
too far
> >>>>>       from
> >>>>>        >> their expectations.
> >>>>>        >>
> >>>>>        >> I think being more moderate with the amount of people is =
better, and
> >>>>>        >> gives us leeway in case the workload ends up being excess=
ive and
> >>>>>       we need
> >>>>>        >> to add more people (plus discourage people from joining a=
nd
> >>>>>       slacking off).
> >>>>>        >>
> >>>>>        >> I think 3 more people should be a good number to start fr=
om.
> >>>>>        >> I'd personally vouch for Murch, Kanzure, and Ruben based =
on
> >>>>>       their track
> >>>>>        >> record in the space
> >>>>>        >>
> >>>>>        >> On Tue, Apr 2, 2024 at 4:30=E2=80=AFPM nvk <rdlfnvk@gmail=
.com
> >>>>>       <mailto:rdlfnvk@gmail.com>
> >>>>>        >> <mailto:rdlfnvk@gmail.com <mailto:rdlfnvk@gmail.com>>> wr=
ote:
> >>>>>        >>
> >>>>>        >> +1 for
> >>>>>        >> Kanzure
> >>>>>        >> RubenSomsen
> >>>>>        >> Seccour
> >>>>>        >> Jon Atack
> >>>>>        >> Roasbeef
> >>>>>        >>
> >>>>>        >> I would prefer having more (9+?) than less folks on this =
task, so
> >>>>>        >> personal preferences are easily ignored and overwritten b=
y the group
> >>>>>        >> majority.
> >>>>>        >>
> >>>>>        >> BIPs were intended as a means to collect ideas, not enfor=
ce ideas.
> >>>>>        >>
> >>>>>        >> I'd like to return to that.
> >>>>>        >>
> >>>>>        >> - NVK (temp gmail account)
> >>>>>        >>
> >>>>>        >>      On Monday, April 1, 2024 at 5:16:54=E2=80=AFPM UTC-4=
 David A.
> >>>>>       Harding wrote:
> >>>>>        >>
> >>>>>        >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>        >>           > Please provide justification rather than simp=
ly
> >>>>>       saying "I
> >>>>>        >>          like Bob!".
> >>>>>        >>
> >>>>>        >>          Using only comments from the mailing list, the
> >>>>>       following appears
> >>>>>        >>          to be
> >>>>>        >>          the candidate list along with the current suppor=
t.
> >>>>>       Asterisks denote
> >>>>>        >>          candidates who indicated their willingness to ac=
cept
> >>>>>       the role.
> >>>>>        >>
> >>>>>        >>          - Bryan "Kanzure" Bishop, recommended by Ava Cho=
w[1], Chris
> >>>>>        >>          Stewart[3],
> >>>>>        >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[=
10],
> >>>>>       Brandon
> >>>>>        >>          Black[11],
> >>>>>        >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15=
], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Ruben Somsen, recommended by Ava Chow[1], Chri=
s
> >>>>>       Stewart[3],
> >>>>>        >>          Michael
> >>>>>        >>          Folkson[6], Antoine Riard[12], Murch[13], Antoin=
e
> >>>>>       Poinsot[15], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Jon Atack*, recommended by Luke Dashjr[2], Chr=
is
> >>>>>       Stewart[3],
> >>>>>        >>          /dev/fd0[5][7],
> >>>>>        >>          Brandon Black[11], Antoine Riard[12], Ava Chow[1=
4], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by =
Chris
> >>>>>        >>          Stewart[3], John
> >>>>>        >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClellan=
d[8],
> >>>>>       Antoine
> >>>>>        >>          Riard[12], Ava Chow[14]
> >>>>>        >>
> >>>>>        >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>>>       Folkson[6], Keagan
> >>>>>        >>          McClelland[8], Matt Corallo[10], Brandon Black[1=
1], Antoine
> >>>>>        >>          Riard[12],
> >>>>>        >>          Ava Chow[14]
> >>>>>        >>
> >>>>>        >>          - Michael Folkson*
> >>>>>        >>
> >>>>>        >>          Note: Luke Dashjr proposed[17] Seccour and Greg =
Tonoski for
> >>>>>        >>          "non-dev
> >>>>>        >>          triaging", Tonoski proposed himself[18] for "BIP
> >>>>>       editor", and
> >>>>>        >>          Antoine
> >>>>>        >>          Riard[12] proposed Seccour for "decentralized PM=
".
> >>>>>        >>
> >>>>>        >>          I searched the BIPs repo by commenter to see if =
any of
> >>>>>       the above
> >>>>>        >>          candidates had been especially active there, whi=
ch is
> >>>>>       listed
> >>>>>        >>          below as:
> >>>>>        >>          total PRs they commented on (number still open/n=
umber
> >>>>>       closed).
> >>>>>        >>
> >>>>>        >>          - 21 (1/20) commenter:kanzure
> >>>>>        >>          - 3 (2/1) commenter:rubensomsen
> >>>>>        >>          - 15 (0/15) commenter:jonatack
> >>>>>        >>          - 18 (2/16) commenter:roasbeef
> >>>>>        >>          - 10 (6/4) commenter:Murchandamus
> >>>>>        >>          - 57 (6/51) commenter:michaelfolkson
> >>>>>        >>
> >>>>>        >>          I'll also note that Osuntokun is the only member=
 of the
> >>>>>       set to
> >>>>>        >>          have a
> >>>>>        >>          merged BIP that they co-authored, although I bel=
ieve
> >>>>>       there are
> >>>>>        >>          far-along
> >>>>>        >>          draft BIPs for both Murch (terminology) and Soms=
en (Silent
> >>>>>        >>          Payments). I
> >>>>>        >>          don't think this should be a requirement, but I =
do think it
> >>>>>        >>          demonstrates
> >>>>>        >>          familiarity with the process.
> >>>>>        >>
> >>>>>        >>          Speaking only for myself, I think all of the can=
didates
> >>>>>       above with
> >>>>>        >>          multiple recommendations from other community
> >>>>>       participants are
> >>>>>        >>          fully
> >>>>>        >>          qualified for the role, so I'll only provide a d=
etailed
> >>>>>        >>          justification
> >>>>>        >>          for the person who would be my first pick: Murch=
 is not
> >>>>>       only a
> >>>>>        >>          longstanding and broadly liked Bitcoin contribut=
or, but
> >>>>>       (as Corallo
> >>>>>        >>          mentioned) he has worked on standardizing termin=
ology
> >>>>>       through a
> >>>>>        >>          draft
> >>>>>        >>          BIP. In addition, he provided an extremely detai=
led
> >>>>>       review of
> >>>>>        >>          all 300
> >>>>>        >>          pages of a draft of Mastering Bitcoin (3rd editi=
on) and has
> >>>>>        >>          reviewed
> >>>>>        >>          drafts of over 200 weekly Optech newsletters, in=
 both cases
> >>>>>        >>          significantly improving the accuracy and
> >>>>>       comprehensibility of the
> >>>>>        >>          documentation. To me, that seems very similar to=
 the
> >>>>>       work we'd
> >>>>>        >>          ask him
> >>>>>        >>          to perform as a BIPs editor and it's something t=
hat
> >>>>>       he's already
> >>>>>        >>          doing,
> >>>>>        >>          so I think there's an excellent fit of person to=
 role.
> >>>>>        >>
> >>>>>        >>          -Dave
> >>>>>        >>
> >>>>>        >>          [1]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow1=
01.com/
> >>>>>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow=
101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d9792=
7551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba=
1a-c9d97927551e@achow101.com/>>
> >>>>>        >>          [2]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr=
.org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashj=
r.org/>
> >>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1f=
f8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-=
b843-c1ff8f8a62a3@dashjr.org/>>
> >>>>>        >>          [3]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@google=
groups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googleg=
roups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc4=
6f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-=
4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >>>>>        >>          [4]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpur=
gatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurg=
atory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55=
899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d=
333-fd28-bdd55899b713@netpurgatory.com/>>
> >>>>>        >>          [5]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@google=
groups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googleg=
roups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c371=
9157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-=
4a36-be81-7c3719157fabn@googlegroups.com/>>
> >>>>>        >>          [6]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@google=
groups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googleg=
roups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3=
564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-=
48d2-a787-639a3564d006n@googlegroups.com/>>
> >>>>>        >>          [7]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@google=
groups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googleg=
roups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d34=
6efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-=
4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >>>>>        >>          [8]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=
=3DwruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFG=
L1-LKPWd7YRS110ut8tX=3DwruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org=
/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=3DwruqgLEazRA5nVw9siYCPj4A@mail.g=
mail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=3Dwr=
uqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >>>>>        >>          [9]
> >>>>>       https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >>>>>        >>
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.=
org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.=
org/>>
> >>>>>        >>          [10]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattco=
rallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcora=
llo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336=
a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5=
-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >>>>>        >>          [11]
> >>>>>       https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>>>>        >>
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >>>>>        >>          [12]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...=
@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+=
E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+=
FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bit=
coindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/=
>>
> >>>>>        >>          [13]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.=
one/
> >>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch=
.one/>
> >>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32b=
d88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-9=
20b-32bd88d5e778@murch.one/>>
> >>>>>        >>          [14]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow1=
01.com/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow=
101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80=
b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-86=
6d-c555b80b0644@achow101.com/>>
> >>>>>        >>          [15]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5W=
of_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4=
xojo=3D@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85km=
IBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXO=
H4gwU1c2jS4xojo=3D@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1=
tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf=
8IDApPqF7bXOH4gwU1c2jS4xojo=3D@protonmail.com/ <https://gnusha.org/pi/bitco=
indev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qf=
WMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=3D@protonmail.com/>>
> >>>>>        >>          [16]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@google=
groups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googleg=
roups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9e=
d340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-=
4552-88ca-11b9ed340661n@googlegroups.com/>>
> >>>>>        >>          [17]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU=
=3D=3DYJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMH=
HROw9mZJRnTbUo76PdqwJU=3D=3DYJMvd9Qrst+...@mail.gmail.com/> <https://gnusha=
.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU=3D=3DYJMvd9Qrst+nmyypaedYZgg@=
mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJ=
U=3D=3DYJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>>
> >>>>>        >>
> >>>>>        >>      --
> >>>>>        >>      You received this message because you are subscribed=
 to the
> >>>>>       Google
> >>>>>        >>      Groups "Bitcoin Development Mailing List" group.
> >>>>>        >>      To unsubscribe from this group and stop receiving em=
ails
> >>>>>       from it,
> >>>>>        >>      send an email to bitcoindev+unsubscribe@googlegroups=
.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>
> >>>>>        >>      <mailto:bitcoindev+unsubscribe@googlegroups.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>>.
> >>>>>        >>      To view this discussion on the web visit
> >>>>>        >>
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4c=
a0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid=
/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <http=
s://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0b=
ben%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter <https://grou=
ps.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40go=
oglegroups.com?utm_medium=3Demail&utm_source=3Dfooter>>.
> >>>>>        >>
> >>>>>        >>
> >>>>>        >>
> >>>>>        >> --
> >>>>>        >> Sergi.
> >>>>>        >>
> >>>>>        >> --
> >>>>>        >> You received this message because you are subscribed to t=
he Google
> >>>>>        >> Groups "Bitcoin Development Mailing List" group.
> >>>>>        >> To unsubscribe from this group and stop receiving emails =
from
> >>>>>       it, send
> >>>>>        >> an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>
> >>>>>        >> <mailto:bitcoindev+unsubscribe@googlegroups.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>>.
> >>>>>        >> To view this discussion on the web visit
> >>>>>        >>
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61t=
ysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.go=
ogle.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2=
B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CA=
EYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_=
medium=3Demail&utm_source=3Dfooter <https://groups.google.com/d/msgid/bitco=
indev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.=
com?utm_medium=3Demail&utm_source=3Dfooter>>.
> >>>>>        >
> >>>>>        > --
> >>>>>        > You received this message because you are subscribed to th=
e
> >>>>>       Google Groups "Bitcoin Development Mailing List" group.
> >>>>>        > To unsubscribe from this group and stop receiving emails f=
rom it,
> >>>>>       send an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
> >>>>>        > To view this discussion on the web visit
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4d=
b8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitc=
oindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>.
> >>>>>
> >>>>>       --
> >>>>>       You received this message because you are subscribed to the G=
oogle
> >>>>>       Groups "Bitcoin Development Mailing List" group.
> >>>>>       To unsubscribe from this group and stop receiving emails from=
 it,
> >>>>>       send an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
> >>>>>       To view this discussion on the web visit
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-49=
03-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitc=
oindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >>>>>
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google G=
roups "Bitcoin Development Mailing List" group.
> >>>> To unsubscribe from this group and stop receiving emails from it, se=
nd an email to bitcoindev+unsubscribe@googlegroups.com.
> >>>> To view this discussion on the web visit https://groups.google.com/d=
/msgid/bitcoindev/0d4d85e3-9fbb-4bd4-af0f-92225e699b63%40achow101.com.
> >>>
> >>>
> >>>
> >>> --
> >>> Michael Folkson
> >>> Personal email: michaelfolkson@gmail.com
> >>
> >
> >
> > --
> > Michael Folkson
> > Personal email: michaelfolkson@gmail.com
>


--=20
Michael Folkson
Personal email: michaelfolkson@gmail.com

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CAFvNmHTgfwSx-kNzHSFW_7HWfOG1yupJQGZqXWzG47i%3D-DjSsA%40mail.gma=
il.com.