Subject: Re: [bitcoindev] Re: Adding New BIP Editors

From: Antoine Riard <[email-masked]>
Date: Sun, 21 Apr 2024 21:48:07 +0100

> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.

ACK.

Beyond that, I'll stick to my mail of the 1st April and I won't comment
further on the subject of nominating new BIP editors.
If anyone has thoughts on how to improve the BIP process for the _future_,
I think real-or-random started a new thread called "Time for an update to
BIP2?".
Anyone can express themselves there and then start to champion a new BIP of
type "process".

Best,
Antoine

Le dim. 21 avr. 2024 à 20:08, 'Ava Chow' via Bitcoin Development Mailing
List <[email-masked]> a écrit :

> On 04/21/2024 01:57 PM, Michael Folkson wrote:
> > 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?
>
> I did not say that they can write anything, do not put words in my
> mouth. Modifications to a BIP are held to the same standard as when it
> is initially proposed. This standard is largely about formatting, but
> also about keeping BIPs as actual technical specifications. So long as
> the BIP after those modifications meet those requirements, then BIP
> editors should merge them.
>
> > 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"
>
> BIPs are specifications. They are not blog posts. They are not the place
> for opining about whether or not something will activate. Such
> statements would be off topic for a BIP and do not meet the standard for
> merging, so no, I do not think that should be merged, and I do not think
> any of the proposed BIP editors would merge such a PR.
>
> >
> > 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
> gatekeepers 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.
>
> You are being deliberately obtuse and strawmanning. I did not say that
> the BIP editors won't be able to do anything; I did not say that that a
> BIP author can put whatever they want once they get a BIP number.
>
> I suggest that you read the BIP process thread split from this one for
> opinions on how to refine the BIPs process to make it clearer as to what
> BIP editors should be merging.
>
> Frankly, I don't understand what it is your are arguing for or trying to
> achieve. You make absurd claims, use strawman arguments, and throw out
> whataboutisms. This all seems to me to be concern trolling, and as such,
> I see no reason to continue responding to you.
>
> Ava
>
> >
> > Michael
> >
> >
> >
> > On Sun, Apr 21, 2024 at 5:39 PM Ava Chow <[email-masked]> 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
> merged
> >>>>> 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
> and
> >>>> 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 AM Ava Chow <[email-masked]> 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
> agree
> >>>> 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
> like
> >>>> 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
> questions
> >>>> 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
> find
> >>>>> 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
> goes
> >>>> 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
> would
> >>>> 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
> merged
> >>>>> 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
> and
> >>>> 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
> the
> >>>> 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 PM 'Ava Chow' via Bitcoin Development
> >>>>> Mailing List <[email-masked]> 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
> him
> >>>>>> about being a BIPs editor.
> >>>>>>
> >>>>>>> I'm confused by this process that we don't even ask the people if
> they
> >>>>>>> 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/[email-masked]/
> >>>>>> [2]:
> >>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> >>>>>>> Mailing List <[email-masked]
> >>>>>>> <mailto:[email-masked]>> 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
> last email.
> >>>>>>>        As such, there is rough consensus on adding Kanzure, Murch,
> Jonatack,
> >>>>>>>        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
> Mailing 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
> subset of the
> >>>>>>>         > nominees should be added. As it is now, I have only seen
> an actual
> >>>>>>>         > objection to Kanzure and Ruben from /dev/fd0, and no
> explicit
> >>>>>>>        objections
> >>>>>>>         > to anyone else. It seems like the vast majority of
> people don't share
> >>>>>>>         > their concerns either as both Kanzure and Ruben continue
> to be
> >>>>>>>        endorsed
> >>>>>>>         > by many others.
> >>>>>>>         >
> >>>>>>>         > Looking at the endorsements each candidate has received,
> the 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
> added - 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
> Roasbeef have
> >>>>>>>        posted
> >>>>>>>         > on this list that they are willing to be BIP editors. I
> have
> >>>>>>>        reached out
> >>>>>>>         > to all 3 of them privately, and received responses from
> Kanzure and
> >>>>>>>         > Ruben that indicate that they probably are willing, but
> public
> >>>>>>>         > 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
> this
> >>>>>>>        task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritten
> by 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
> do not
> >>>>>>>        end up
> >>>>>>>         >> doing as much because they expect others to do the it.
> This does not
> >>>>>>>         >> only make the process look bad but may burnout the ones
> that 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
> excessive and
> >>>>>>>        we need
> >>>>>>>         >> to add more people (plus discourage people from joining
> and
> >>>>>>>        slacking off).
> >>>>>>>         >>
> >>>>>>>         >> I think 3 more people should be a good number to start
> from.
> >>>>>>>         >> 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 PM nvk <[email-masked]
> >>>>>>>        <mailto:[email-masked]>
> >>>>>>>         >> <mailto:[email-masked] <mailto:[email-masked]>>>
> wrote:
> >>>>>>>         >>
> >>>>>>>         >> +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
> by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> BIPs were intended as a means to collect ideas, not
> enforce ideas.
> >>>>>>>         >>
> >>>>>>>         >> I'd like to return to that.
> >>>>>>>         >>
> >>>>>>>         >> - NVK (temp gmail account)
> >>>>>>>         >>
> >>>>>>>         >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David
> A.
> >>>>>>>        Harding wrote:
> >>>>>>>         >>
> >>>>>>>         >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>>>         >>           > Please provide justification rather than
> simply
> >>>>>>>        saying "I
> >>>>>>>         >>          like Bob!".
> >>>>>>>         >>
> >>>>>>>         >>          Using only comments from the mailing list, the
> >>>>>>>        following appears
> >>>>>>>         >>          to be
> >>>>>>>         >>          the candidate list along with the current
> support.
> >>>>>>>        Asterisks denote
> >>>>>>>         >>          candidates who indicated their willingness to
> accept
> >>>>>>>        the role.
> >>>>>>>         >>
> >>>>>>>         >>          - Bryan "Kanzure" Bishop, recommended by Ava
> Chow[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],
> Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          Michael
> >>>>>>>         >>          Folkson[6], Antoine Riard[12], Murch[13],
> Antoine
> >>>>>>>        Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Jon Atack*, recommended by Luke Dashjr[2],
> Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          /dev/fd0[5][7],
> >>>>>>>         >>          Brandon Black[11], Antoine Riard[12], Ava
> Chow[14], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Olaoluwa "Roasbeef" Osuntokun, recommended
> by Chris
> >>>>>>>         >>          Stewart[3], John
> >>>>>>>         >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
> McClelland[8],
> >>>>>>>        Antoine
> >>>>>>>         >>          Riard[12], Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>>>>>        Folkson[6], Keagan
> >>>>>>>         >>          McClelland[8], Matt Corallo[10], Brandon
> Black[11], 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,
> which is
> >>>>>>>        listed
> >>>>>>>         >>          below as:
> >>>>>>>         >>          total PRs they commented on (number still
> open/number
> >>>>>>>        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
> believe
> >>>>>>>        there are
> >>>>>>>         >>          far-along
> >>>>>>>         >>          draft BIPs for both Murch (terminology) and
> Somsen (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
> candidates
> >>>>>>>        above with
> >>>>>>>         >>          multiple recommendations from other community
> >>>>>>>        participants are
> >>>>>>>         >>          fully
> >>>>>>>         >>          qualified for the role, so I'll only provide a
> detailed
> >>>>>>>         >>          justification
> >>>>>>>         >>          for the person who would be my first pick:
> Murch is not
> >>>>>>>        only a
> >>>>>>>         >>          longstanding and broadly liked Bitcoin
> contributor, but
> >>>>>>>        (as Corallo
> >>>>>>>         >>          mentioned) he has worked on standardizing
> terminology
> >>>>>>>        through a
> >>>>>>>         >>          draft
> >>>>>>>         >>          BIP. In addition, he provided an extremely
> detailed
> >>>>>>>        review of
> >>>>>>>         >>          all 300
> >>>>>>>         >>          pages of a draft of Mastering Bitcoin (3rd
> edition) 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
> that
> >>>>>>>        he's already
> >>>>>>>         >>          doing,
> >>>>>>>         >>          so I think there's an excellent fit of person
> to role.
> >>>>>>>         >>
> >>>>>>>         >>          -Dave
> >>>>>>>         >>
> >>>>>>>         >>          [1]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [2]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [3]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [4]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [5]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [6]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [7]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [8]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/
> >>
> >>>>>>>         >>          [9]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> >>>>>>>         >>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>>
> >>>>>>>         >>          [10]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [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/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [13]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [14]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/[email-masked]/> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [15]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >>
> >>>>>>>         >>          [16]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/[email-masked]/ <
> https://gnusha.org/pi/bitcoindev/[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/[email-masked]/
> >>
> >>>>>>>         >>          [17]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/
> >>
> >>>>>>>         >>
> >>>>>>>         >>      --
> >>>>>>>         >>      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 email to
> [email-masked]
> >>>>>>>        <mailto:[email-masked]>
> >>>>>>>         >>      <mailto:[email-masked]
> >>>>>>>        <mailto:[email-masked]>>.
> >>>>>>>         >>      To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >>.
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> Sergi.
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> 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 email to [email-masked]
> >>>>>>>        <mailto:[email-masked]>
> >>>>>>>         >> <mailto:[email-masked]
> >>>>>>>        <mailto:[email-masked]>>.
> >>>>>>>         >> To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> >>.
> >>>>>>>         >
> >>>>>>>         > --
> >>>>>>>         > 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 email to [email-masked]
> >>>>>>>        <mailto:[email-masked]>.
> >>>>>>>         > To view this discussion on the web visit
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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 emails
> from it,
> >>>>>>>        send an email to [email-masked]
> >>>>>>>        <mailto:[email-masked]>.
> >>>>>>>        To view this discussion on the web visit
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.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 emails from it,
> send an email to [email-masked].
> >>>>>> 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: [email-masked]
> >>>>
> >>>
> >>>
> >>> --
> >>> Michael Folkson
> >>> Personal email: [email-masked]
> >>
> >
> >
> > --
> > Michael Folkson
> > Personal email: [email-masked]
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email-masked].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.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 emails from it, send an email to [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BHdRQEewsy08ezcGU38Gr0N%2BCwYgRr1CbRNsDGEM_UThQ%40mail.gmail.com.