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

From: "'Ava Chow' via Bitcoin Development Mailing List" <[email-masked]>
Date: Sun, 21 Apr 2024 18:47:05 +0000

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 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/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.com.