Adding New BIP Editors

[Ava Chow]

Hi All,

Following on the recent [discussion][1] about BIP process friction, and
admissions from Luke that he has not had the time to actively work on
the BIPs repo ([2], [3]), I think it is prudent for us to look at adding
more BIPs editors. These people would have the same permissions and
responsibilities that Luke has, i.e. can assign BIP numbers, merge PRs
adding new BIPs, merge PRs to fix existing BIPs,and all other
responsibilities as described in [BIP 2][4]. I think this would
significantly help get through the backlog of BIPs PRs, and responding
to them in a timely manner to significantly reduce the friction of
getting BIPs changes merged. Of course, this would require that all BIP
editors agree on the numbering scheme so that BIPs continue to be
numbered consistently.

Considering the responsibilities of these tasks, I think any new BIP
editors should be people who have a history of following and being
involved in Bitcoin development, as well as being known to evaluate
proposals objectively, and of course, are willing to do the job. With
that in mind, I think both Kanzure and RubenSomsen are very good
candidates to be BIP editors, and having both of them working on the
BIPs repo would greatly benefit all of us.

Thanks,
Ava

[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022289.html
[2]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022291.html
[3]: https://twitter.com/LukeDashjr/status/1761127972302459000
[4]:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_Editor_Responsibilities__Workflow

[Léo Haf]

Luke should choose the new editors himself, especially since he has already made a call for applications.

[Antoine Poinsot]

I think this would be helpful, thanks for bringing it up.

I agree Kanzure and RubenSomsen are good candidates for this role.

Antoine

> --
> 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 bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e%40achow101.com.

[Greg Tonoski]

I am proposing my candidacy for BIP editor.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo%3D%40protonmail.com.

[Luke Dashjr]

On 2/27/24 15:11, 'Léo Haf' via Bitcoin Development Mailing List wrote:
> Luke should choose the new editors himself, especially since he has
> already made a call for applications.

Thanks, but this is for the broader development community to decide, not
just any one person.

My tweet got many people volunteering in response, and while I agree
another dev reviewing new BIPs would be helpful, I do think it would be
best to have non-devs contribute by triaging what doesn't require dev
skills.

Of those who actually put their names forward, Jon Atack and Roasbeef
stand out as long-time devs to consider (though I have reservations
about Roasbeef for this role). (Kanzure and Ruben both seem undecided if
they're even available to help at this time.) For non-dev triaging, I
would suggest we consider testing out the idea with perhaps Seccour
and/or Greg Tonoski.

Assigning BIP numbers itself is easy enough. The hard part is evaluating
if the new proposal meets the criteria - which definitely needs dev
skills (mainly for technical soundness). So IMO we should move forward
with more editors ASAP without waiting for a new way to coordinate the
numbering (we can deal with that later/in parallel to solving the
immediate need).

Luke

[Steve Lee]

I am unfamiliar with Seccour and Greg Tonoski. Is there a place to look at their history of bitcoin contributions?

--
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 bitcoindev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3%40dashjr.org.

[Ava Chow]

On 02/27/24 05:40 PM, Luke Dashjr wrote:

I do think it would be best to have non-devs contribute by triaging what doesn't require dev

skills.

Can you clarify what the non-dev triagers would be doing?

Assigning BIP numbers itself is easy enough. The hard part is evaluating
if the new proposal meets the criteria - which definitely needs dev
skills (mainly for technical soundness). So IMO we should move forward
with more editors ASAP without waiting for a new way to coordinate the
numbering (we can deal with that later/in parallel to solving the
immediate need).

While I think having BIP editors who can go through the backlog of PRs that modify BIPs would be useful, I think the primary complaint recently has really been on the assigning of numbers and subsequently getting those proposed BIPs merged. AJ's original email began with a discussion of open proposed BIPs that were (presumably) waiting on numbers. So I think adding editors who can assign numbers should be something we do sooner rather than later.

Ava

[bitcoin-dev...@slmail.me]

Why does non-dev triaging require any permissions? For BIP
modifications of existing BIPs, the list of authors is in the header,
so anyone can get this list and ping the corresponding GitHub account.
Once at least one author has approved the changes, the editor(s) can
be notified.

Given that the BIP process is documented, for simple issues arising in
newly proposed BIPs, anyone with good understanding of the process
should be able to help without permission. For example, leaving a
comment that a required section is missing (c.f.
https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166).

So if there is anyone out there with good understanding of the
process, willing to help, they could start right away with non-dev
triage?

Regardless, I agree that there is a need for another BIP editor, given
the backlog for number assignment and backlog on merges of approved
changes to existing BIPs. The proposed candidates seem like a good
fit.

Best, void867

[/dev /fd0]

Hi Ava,

Even though it would be better if the BIPs repository was archived and everyone maintained different repositories for BIPs. However, if it still remains relevant I would not want mailing list moderators to be same as BIP editors. So I disagree with the 2 names suggested.

/dev/fd0

floppy disk guy

[Tim Ruffing]

On Tue, 2024-02-27 at 17:40 -0500, Luke Dashjr wrote:
> The hard part is evaluating
> if the new proposal meets the criteria - which definitely needs dev
> skills (mainly for technical soundness).

I'm aware that checking technical soundness is in accordance with BIP2
[1], but I believe that this is one of the main problems of the current
process, and I can imagine that this is what eats the time of editors.

I'd prefer a BIP process in which the editors merely check that the
proposal is related to the Bitcoin ecosystem and meets some minimal
formal criteria that we already enforce now (i.e., is a full self-
contained document, has the required sections, etc...). This relieves
the editors not just from the effort, but also from the responsibility
to do so. Technical soundness should be evaluated by the audience of a
BIP, not by the editor.

Best,
Tim


[1] BIP2 says: 
"For each new BIP that comes in an editor does the following:

- Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
[...]"

[Antoine Riard]

Hi,

> For non-dev triaging, I 
would suggest we consider testing out the idea with perhaps Seccour

I can vet for Seccour.

Already met IRL, he's organizing bitcoin meetups somewhere in the world.

Best,

Antoine

[Keagan McClelland]

NACK on Tonoski. He's so far shown far too little interest in understanding the history of technical decisions and has been rather extreme in rhetoric. These are not qualities I want in a BIP Editor whose job should be a facilitator rather than an advocate. While I don't expect any BIP Editor to be devoid of their own opinions, I do not trust that he won't use the seat as a means of pushing his own agenda.

Keags

On Tue, Feb 27, 2024 at 2:45 PM Luke Dashjr <lu...@dashjr.org> wrote:

[Michael Folkson]

+1 on Kanzure and RubenSomsen

I would put my name forward if Kanzure, RubenSomsen weren't willing to do it and I was concerned about who it might be. I don't think it should be someone the Bitcoin dev community isn't familiar with and hasn't proven themselves over a long period of time like Kanzure, RubenSomsen have. There is the opportunity for a new BIP editor to cause chaos if they were of the wrong temperament and weren't willing to acknowledge opposing views and perspectives. Both Kanzure and RubenSomsen have proved over a long period of time that although they have their own personal views (like anyone else) they won't censor transcripts of presentations or emails to the bitcoin-dev mailing list that contain opposing views to their own. I'm not sure if any of the other candidates putting themselves forward here tick the same boxes as Kanzure and RubenSomsen. I also don't think BIP editors should be Luke Dashjr's personal fiefdom even though overall I personally think Luke has done an excellent job over many years as BIP editor in sometimes difficult circumstances.

Thanks

Michael

[Jon A]

> Of those who actually put their names forward, Jon Atack and Roasbeef
stand out as long-time devs to consider

Thanks. I am willing to help if doing so can be of service. Have been working on Bitcoin development since five years (March 2019) and interested in bitcoin since 2016.  Prior to that was an open source maintainer of a popular search engine for several years and tech lead for various globocorps software projects. Before that, as a teen I wrote professional games in 6502 assembly. Current status and role as described in https://jonatack.github.io/. Have been on temporary hiatus recently. Am unaligned with any particular group, no particular agenda or strong viewpoint regarding, for instance, future soft-fork activations. I see the BIP editor role as about being of service to bitcoin and reckon would follow BIP 2, e.g. its "BIP Editor Responsibilities & Workflow" section.  Cheers, best to all.

[Bitcoin Error Log]

I'd support Atak, Bishop, or Somsen, fwiw. 

[Chris Stewart]

I agree with Tim's thoughts here.

I think Jon Atack, Reuben Somsen, Kanzure or Roasbeef would all make great candidates.

[Murch]

Hey everyone,

I wanted to check in on the topic adding BIP Editors. There seem to be a
number of candidates that are willing and able, and there seems to be
broad agreement among the current editor, the readers of the repository,
and the contributors to the repository that additional help is desirable.

I have seen some support and reservations raised for pretty much every
candidate. A few weeks have passed since this topic was last active. So
far, there seems no clear path forward.

If we are all just in a holding pattern, perhaps we could timebox this
decision process: how about we invite arguments for and against any
candidates in this thread until next Friday EOD (April 5th). If any
candidates find broad support, those candidates could be added as new
editors to the repository on the following Monday (April 8th). If none
get broad support, at least we’d be able to move on and try something else.

I propose that all editors share the same privileges, especially that
any editor may assign numbers to BIPs. If there is guidance to be
provided on the process of assigning numbers and number ranges for
specific topics, it should be provided by then. If the editors decide on
a single number authority among themselves, that would also be fine as
long as it doesn’t become a bottleneck.

As Tim and Chris have suggested, it seems reasonable to me that
assessment of the technical soundness can be left to the audience. BIPs
have been published in the repository and set to the "rejected" status
before, so it’s not as if adding a BIP to the repository is treated as
an unequivocal endorsement or implementation recommendation.

Cheers,
Murch

[John C. Vernaleo]

For what it's worth, I strongly support Roasbeef as a candidate.

That said, I would find it helpful if someone could go through the thread
and list all the people who've been proposed so people know who they
should be thinking about.

-------------------------------------------------------
John C. Vernaleo, Ph.D.
www.netpurgatory.com
j...@netpurgatory.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 bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef%40murch.one.
>

[Keagan McClelland]

I support this as a go forward plan.

[Matt Corallo]

Seems reasonable to me.

While there are plenty of competent technical folks who would make fine BIP editors, I'd suggest
Kanzure and Murch as clear candidates over others:

* Kanzure has been around for longer than any other candidate as far as I can tell, and has
certainly seen more proposals for changes to Bitcoin than anyone. This makes him a great candidate
to point new BIP authors to appropriate citations. Similarly, he has a long history of being very
responsive, which I believe is part of the goal in appointing new editors here.
* Murch similarly has lots of experience dealing with lots of various ideas around Bitcoin, but
importantly here also has worked extensively to document appropriate terminology for all things
Bitcoin [1]. This makes him an excellent copy editor of Bitcoin technical proposals, which is
basically the only thing the BIP editors are supposed to do.

While there are a handful of other candidates mentioned in this thread who are technically quite
competent, that isn't really the relevant criteria for BIP editors.

Matt

[1] https://github.com/murchandamus/bips/pull/1/files

[Murch]

I just went through the thread, previously mentioned were:

- Kanzure
- Ruben Somsen
- Greg Tonoski
- Jon Atack
- Roasbeef
- Seccour

And Matt just suggested me for the role. Hope I didn’t overlook anyone.

[/dev /fd0]

I support Jon Atack and Roasbeef from this list.

[Brandon Black]

I agree with Matt's suggestions, and also support Jon Atack as a BIP
editor.

* Jon's work in bitcoin has focused on practical concerns of users of
the bitcoin software, a valuable perspective for the BIP process as
well. He's been a steady contributor to the bitcoin node software for 4
continuous years, this steadiness would be a boon to the BIP process.

Best,

--Brandon

[Matt Corallo]

Nothing against Jon specifically, but I don't see how this is relevant to a BIP editor. BIP editors
are not responsible for opining on the merit of a proposal. Their job is to assign numbers and
occasionally suggest copy edits to ensure the documents are of high quality and readability.

Matt

[Matt Corallo]

Please provide justification rather than simply saying "I like Bob!".

Matt

> --
> 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

> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Antoine Riard]

Hi all,

On the timeframe of the new appointment of new BIP editors, I would suggest to postpone the effective date to the 1st May or after.

There is a CoreDev edition happening in April and it's better to not conflict the appointment of new BIP editors with any of the CoreDev dates by transparency towards the wider community.

This avoids last-minute "Hong-Kong Agreement" decision-making-style and anyone present in the room with the GH administrative rights on the BIP repository making the change in a "fait accompli".

On all the other concerns, I think it's still better to split the administrative rights between 1) editors who can merge and 2) "product-management" style privileges for PR / issues sorting.

I think it's good to let technical relevance of the proposal be appreciated by the wider community, marking them as "rejected" if necessary.

As new BIP editors, I'm supporting the following list:

- Kanzure (great responsiveness in my experience)

- Ruben (very knowledgeable in all part of Bitcoin stack)

- Roasbeef (i think it's good to have someone for all inter-compatibility clients things)

- Murch (top bitcoin stackoverflow contributor)

- Jon Atack (much experience with bitcoin core codebase and great responsiveness too)

As new BIP "decentralized PM", I'm supporting the following list:

- Seccour 

I don't know the Bitcoin technical credentials of Greg Tonoski.

I think a good thing is to have not-only US-based BIP editors for higher timezones coverage and BIP process responsiveness.

Best,

Antoine 

--
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 bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgWRu32FXzqqg69V%40console.

[Antoine Riard]

>  Their job is to assign numbers and 
occasionally suggest copy edits to ensure the documents are of high quality and readability.

How can you efficiently suggest copy edit if you don't know the terminology to suggest from years of technical experience ?

Including when the technical concept is novel and isn't well-defined in the English language.

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 bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.

[Matt Corallo]

Right, so again I'm not sure why this is relevant to the BIPs repo. I love Roasbeef and he's a super
smart cookie, but that's not really a relevant criteria for the BIP editor, I don't thin. Indeed,
the editors need to understand Bitcoin fairly well, but there's tons of candidates who meet that
criteria. Rather, the BIP editor(s) should have demonstrated competence at copy-editing, have a long
track record in Bitcoin, and be reliably available.

Matt

On 3/28/24 4:59 PM, John C. Vernaleo wrote:
> Fair enough, that was a less than useful comment of mine.
>
> Roasbeef's work on alternative clients and lightning make him technically useful plus I've worked
> with him personally and know he is responive and careful enough for the role.
>
> Can't speak directly about anyone else so no comment on the rest of them.

>
> -------------------------------------------------------
> John C. Vernaleo, Ph.D.
> www.netpurgatory.com
> j...@netpurgatory.com
> -------------------------------------------------------
>

>> bitcoindev+...@googlegroups.com.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.
>>

[John C. Vernaleo]

Fair enough, that was a less than useful comment of mine.

Roasbeef's work on alternative clients and lightning make him technically
useful plus I've worked with him personally and know he is responive and
careful enough for the role.

Can't speak directly about anyone else so no comment on the rest of them.

-------------------------------------------------------
John C. Vernaleo, Ph.D.
www.netpurgatory.com
j...@netpurgatory.com
-------------------------------------------------------

On Thu, 28 Mar 2024, Matt Corallo wrote:

> email to bitcoindev+...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.
>

[Michael Folkson]

This is getting messier than I initially thought it would. I was happy to +1 Kanzure and RubenSomsen and Murch would also get my +1 but some of these other names seem a touch peculiar to me.

For example I think Jon Atack would make a great Core maintainer at some point in the future and I'm not sure a BIP editor should also be a Core maintainer given the independence sometimes required between Core and the BIP process. Also given Luke is struggling for time I'm not sure making Roasbeef a BIP editor makes sense given he is the maintainer of LND, maintainer of btcd and CTO of Lightning Labs unless he is winding down some of his other responsibilities. This is obviously not a criticism of either as they more than qualified to be maintainers of Core and LND/btcd.

GIven the unexpected messiness I'll throw my hat into the ring. I was debating whether to initially as I've given a lot of thought to a BIP process update (BIP 3), closely followed Luke work through some of the frictions and tension points in the past and I disagree it is entirely an administrative task although it broadly is.

Thanks

Michael

[/dev /fd0]

Justification:

1. Jon Atack: Good at avoiding controversies and technical documentation.

2. Roasbeef: Since BIPs are not just related to bitcoin core, it's good to have btcd maintainer as a BIP editor.

[Antoine Riard]

> Roasbeef's work on alternative clients and lightning make him technically 
useful

I think one of the aim of the BIP process is to harmonize common mechanisms among Bitcoin clients of different langages breeds or at different layers (wallet / full-node).

Having someone among BIP editors with a proven track record of contributing to other full-node codebase beyond C++ can be valuable in that sense.

Especially for all matters related to compatibility and deployment.

> For example I think Jon Atack would make a great Core maintainer at some point in the future and I'm not sure a BIP editor should also be a Core maintainer given the

> independence sometimes required between Core and the BIP process

In a world where both Core and BIP repository are living under a single Github organization, I don't think in matters that much as the highest privilege account will be able to 

override any BIP merging decision, or even remove on the flight BIP editors rights in case of conflicts or controversies. If you're raising the issue that the BIP repository should be moved to its own GH repository I think it's a valuable point.

Beyond, I still think we should ensure we have a wider crowd of geographically and culturally diverse BIP editors. As if the role is ensuring high-quality and readability of the terminology of the standards, we might have highly-skilled technical BIP champions which are not English native. With the current set of proposed BIP editors, to the best of my knowledge, at least we have few langages spoken by the candidates: Dutch, French, German, Spanish. This can be very helpful to translate concepts devised in language A to technical english.

Best,

Antoine

[Keagan McClelland]

My top preferences for the role are Murch and Roasbeef.

Both have demonstrated a permissive and curious attitude towards experimentation on Bitcoin and for the role of BIP editor, I would want more quality proposals to be admitted *even if I may personally disagree with them*. It is for me to decide whether or not I like a proposal. The editor should not be making that choice for me.

It was also mentioned that having a "non-Core" perspective would be beneficial to the process and I'm inclined to agree.

Keags

--
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 bitcoindev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9baa15e4-062d-478f-8c87-8ff19ab79989%40murch.one.

[Peter Todd]

On Thu, Mar 28, 2024 at 09:02:26AM -0400, Murch wrote:
> I just went through the thread, previously mentioned were:
>
> - Kanzure

Kanzure is the obvious choice for me. Sufficiently technical to make good
decisions. But, importantly, independent enough for the role:

user@dev-btc:~/bitcoin$ git log | grep -C 2 kanzure

commit a7af9839d688bee9b0b15add61259140b3c00014
Author: Bryan Bishop <kan...@gmail.com>
Date: Fri Nov 14 09:12:41 2014 -0600

--

commit b881100aabee7c8d71cf616ff61a526d0afa9450
Author: Bryan Bishop <kan...@gmail.com>
Date: Wed Feb 26 10:40:18 2014 -0600

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Michael Folkson]

> In a world where both Core and BIP repository are living under a single Github organization, I don't think in matters that much as the highest privilege account will be able to
override any BIP merging decision, or even remove on the flight BIP
editors rights in case of conflicts or controversies. If you're
raising the issue that the BIP repository should be moved to its own
GH repository I think it's a valuable point.

In the past there have been disagreements between Core maintainers and
BIP editors (e.g. Luke with Taproot activation params) and those Core
maintainers haven't merged pull requests in the BIPs repo or removed
him as a BIP editor. As long as that continues it isn't necessary to
create a new GitHub organization for the BIPs repo. They are separate
repos with different maintainers/editors but under the same
organization and everyone knows where it is located.

> Beyond, I still think we should ensure we have a wider crowd of geographically and culturally diverse BIP editors. As if the role is ensuring high-quality and readability of the terminology of the standards, we might have highly-skilled technical BIP champions which are not English native. With the current set of proposed BIP editors, to the best of my knowledge, at least we have few langages spoken by the candidates: Dutch, French, German, Spanish. This can be very helpful to translate concepts devised in language A to technical english.

It seems like you want to create some kind of United Nations for the
BIP process. As I said previously this is almost entirely an
administrative task. Going to a committee of 10 people with different
nationalities and languages to decide whether something should get a
BIP number is absurd. If you think Luke is slow to respond wait until
your United Nations of the BIP process has to all agree to assign a
BIP number. Please don't try to make this unnecessarily bureaucratic
and political for no reason. There's enough of that outside of
Bitcoin.

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegroups.com.



--
Michael Folkson
Personal email: michael...@gmail.com

[Antoine Riard]

Hi Michael,

> In the past there have been disagreements between Core maintainers and
> BIP editors (e.g. Luke with Taproot activation params) and those Core
> maintainers haven't merged pull requests in the BIPs repo or removed
> him as a BIP editor. As long as that continues it isn't necessary to
> create a new GitHub organization for the BIPs repo. They are separate
> repos with different maintainers/editors but under the same
> organization and everyone knows where it is located.

Indeed, avoiding new conflicts like we have seen with Luke with Taproot activation params is a good reason to separate repositories in my opinion.

Beyond, "security through distrusting" [0] is a very legitimate security philosophy including for communication space infrastructure.

[0] https://www.qubes-os.org/news/2017/12/11/joanna-rutkowska-black-hat-europe-2017/

> It seems like you want to create some kind of United Nations for the
> BIP process. As I said previously this is almost entirely an
> administrative task. Going to a committee of 10 people with different
> nationalities and languages to decide whether something should get a
> BIP number is absurd. If you think Luke is slow to respond wait until
> your United Nations of the BIP process has to all agree to assign a
> BIP number. Please don't try to make this unnecessarily bureaucratic
> and political for no reason. There's enough of that outside of
> Bitcoin.

No, I wish to ensure that if the aim of the BIP is ensuring high-quality and readability of standards those ones are well-written, including when the original standard is contributed by someone non-native.

I can only remember numerous times when my english technical texts have been kindly corrected by other contributors. Having editors understanding multiple languages helps in quality redaction.

Beyond, from reading conversations it sounds there is a disagreement if it's an administrative task (i.e "assigning numbers") or editorial one (i.e "high-quality, well-written standards").

If we wish to make things less bureaucratic, we might actually separate the two tasks with different groups of BIP process maintainers :

- assign temporary numbers for experimentation

- wait for more-or-less finalized drafts written in a quality fashion

- assign final numbers for standard candidate deployment

If you see other ways to dissociate the roles and make things less bureaucratic ? E.g having people only in charge of triage.

If I remember correctly the IETF does not assign RFC numbers for draft proposals, and you generally have years of experimentation.

Best,

Antoine

PS: By the way, even at the United Nations, unanimity is not the rule, it's two-third of the general assembly. I think your analogy is not valid.

[Michael Folkson]

Hi Antoine

Thanks for the challenge. I think we are going to end up disagreeing
on some things but perhaps the discussion is worth having.

> Indeed, avoiding new conflicts like we have seen with Luke with Taproot activation params is a good reason to separate repositories in my opinion.
Beyond, "security through distrusting" [0] is a very legitimate
security philosophy including for communication space infrastructure.

I repeat having the BIPs repo under a different GitHub organization
would *not* have resulted in a different outcome in the Taproot
activation params or avoided that particular conflict. If Core
maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor
that would have been a different outcome. There are costs to moving
the BIPs repo to a different GitHub organization (existing links,
discoverability, two GitHub organizations to worry about rather than
one) and as long as Core maintainers don't overrule BIP editors in the
BIPs repo there are no clear upsides.

> No, I wish to ensure that if the aim of the BIP is ensuring high-quality and readability of standards those ones are well-written, including when the original standard is contributed by someone non-native.
I can only remember numerous times when my english technical texts
have been kindly corrected by other contributors. Having editors
understanding multiple languages helps in quality redaction.

Just as you don't need to be a maintainer to provide high quality pull
request review in the Core repo you don't need to be a BIP editor to
provide high quality pull request review in the BIPs repo. There is
nothing to stop people who aren't BIP editors continuing to provide
review of your work in English and a BIPs repo in English only needs
BIP editors who are fluent in English.

> Beyond, from reading conversations it sounds there is a disagreement if it's an administrative task (i.e "assigning numbers") or editorial one (i.e "high-quality, well-written standards").

I think we'd agree we are somewhere in between these pure extremes and
I'd argue mostly towards the administrative task end. One of the
reasons I think Kanzure, RubenSomsen and Murch are good BIP editor
candidates is that they can also provide high quality pull request
review before potentially merging but unlike the Core repo where bad
ideas should never be merged a BIP editor will end up merging up pull
requests they think are bad ideas that they would never want merged
into Core. A BIP can get a BIP number and end up being rejected by
Core or the broader community for example.

> If we wish to make things less bureaucratic, we might actually separate the two tasks with different groups of BIP process maintainers :
- assign temporary numbers for experimentation
- wait for more-or-less finalized drafts written in a quality fashion
- assign final numbers for standard candidate deployment

This seems even more bureaucratic to me. Different numbers to track,
more complexity. There is a BINANA repo [0] for Bitcoin Inquisition
for this kind of early experimentation for proposed consensus changes
that aren't advanced enough to be BIPs.

> If you see other ways to dissociate the roles and make things less bureaucratic ? E.g having people only in charge of triage.
If I remember correctly the IETF does not assign RFC numbers for draft
proposals, and you generally have years of experimentation.

Personally I think it is fine as it is. We are discussing the
potential addition of high quality BIP editors as only having one
currently (Luke) is clearly not ideal. That will alleviate Luke as a
single bottleneck. I do think it is time for an update to the BIP
process (BIP 3) too so BIP editors have some guidance on how to treat
bad ideas (how bad are we talking!) and are comfortable merging pull
requests around attempted (successful or failed) soft fork
activations. Ultimately though just like with Core maintainers there
is going to be some personal judgment required especially during those
cases where there isn't clear community consensus either way. Hence
for those cases I'd be much more comfortable with say Kanzure,
RubenSomsen or Murch than someone we know very little about and hasn't
demonstrated a strong understanding of how Bitcoin works.

> PS: By the way, even at the United Nations, unanimity is not the rule, it's two-third of the general assembly. I think your analogy is not valid.

Perhaps we can leave discussion of my imperfect analogies to a
different forum :) Hopefully we can agree that this is a direction of
travel that we shouldn't be pursuing for the BIPs repo.

[0]: https://github.com/bitcoin-inquisition/binana

[Ava Chow]

Thanks for bringing this back up again. I agree that we should try to
move forward on this, and this timeline seems reasonable to me.

Kanzure, Ruben, Roasbeef, Murch, and Jonatack all have my support to be
BIP editors with all privileges and responsibilities as laid out in BIP 2.

Regarding guidance on assigning BIP numbers, if there is no guidance
provided by Luke to the new BIP editors when their permissions are
granted, I would also support simply creating their own numbering scheme
and begin assigning new BIP numbers. It's ridiculous that we should be
bottlenecked on simply what number a proposal should have.

Ava

> --
> 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 bitcoindev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef%40murch.one.

[/dev /fd0]

An alternative approach for BIP numbers:

1. A bot assigns a temporary number to each pull request opened with "NEW:" in title based on GitHub pull request number and append B in front of it. Example: B1551

2. BIP editors and others could review to improve the BIP documentation. BIP author can use this number for the BIP until pull request is open.

3. Once the pull request is merged, it is assigned a permanent number which can be used to refer this doc in future.

Both numbers would stay relevant and if someone is not aware of permanent number, they could easily check it by opening pull request.

Other things CI can be used for:

- Automated grammar check when pull request is opened/re-opened

- Publish a copy of BIP as torrent or nostr event etc. when pull request is merged

/dev/fd0

floppy disk guy

[Michael Folkson]

> f there is no guidance provided by Luke to the new BIP editors when their permissions are granted

I know this isn't how Core maintainers like to operate but perhaps
this guidance to BIPs editors could be public and transparent. There
isn't any need for BIP editors to go the Core maintainer route of
onboarding new maintainers and discussing merge decisions that impact
Core users and the broader community privately and in the shadows. To
the extent that there is disagreement or personal judgment required
that's fine. Say so in public.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644%40achow101.com.

[Murch]

On 3/27/24 19:54, Matt Corallo wrote:
> While there are plenty of competent technical folks who would make fine
> BIP editors, I'd suggest Kanzure and Murch as clear candidates over others

Thanks Matt. After mulling it over for a bit, I have decided to accept
the nomination and announce my candidacy for the BIP Editor role under
the assumptions that 1) all editors will share the same privileges, and
2) there will be at least three active editors at the end of this process.

My first choice for BIP Editor additions would be Kanzure for his
encyclopedic knowledge of development discussions and his track record
of reliably performing a similarly janitorial role for many years.
My second choice would be Ruben who has a similar track record and who I
imagine might be the person who has perused the BIPs repository most in
the recent years among the proposed candidates. I consider them both
levelheaded, open-minded enough to assess proposals beyond their own
predilections, but also capable of applying uniformly the standards set
out in the BIP process. I’d be happy to collaborate with them to chip
away at those 137 open pull requests, if the community expresses support
for that outcome.

Cheers,
Murch

[Jonas Nick]

> how about we invite arguments for and against any candidates in this thread
> until next Friday EOD (April 5th). If any candidates find broad support, those
> candidates could be added as new editors to the repository on the following
> Monday (April 8th). If none get broad support, at least we’d be able to move on
> and try something else.

It also seems important that candidates confirm their availability for the role
and associated responsibilities. To the best of my knowledge, based on the list
of candidates you posted, only Jon Atack and Greg Tonoski have done so in this
thread so far.

[David A. Harding]

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/2092f7ff-4860-47f8...@achow101.com/
[2]
https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
[3]
https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
[4]
https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
[5]
https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
[6]
https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
[7]
https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
[8]
https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
[9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
[10]
https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
[11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
[12]
https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
[13]
https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
[14]
https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
[15]
https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
[16]
https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
[17]
https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/

[Antoine Riard]

Hi Michael,

Thanks for the thoughtful answer.

> I repeat having the BIPs repo under a different GitHub organization
> would *not* have resulted in a different outcome in the Taproot
> activation params or avoided that particular conflict. If Core
> maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor
> that would have been a different outcome. There are costs to moving
> the BIPs repo to a different GitHub organization (existing links,
> discoverability, two GitHub organizations to worry about rather than
> one) and as long as Core maintainers don't overrule BIP editors in the
> BIPs repo there are no clear upsides.

Fair point, though I think it's more a one-time migration cost for long-term returns.

I still believe we shall apply the principle of least privilege when we can.

This blog article is a good one to meditate:

https://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html

> Just as you don't need to be a maintainer to provide high quality pull
> request review in the Core repo you don't need to be a BIP editor to
> provide high quality pull request review in the BIPs repo. There is
> nothing to stop people who aren't BIP editors continuing to provide
> review of your work in English and a BIPs repo in English only needs
> BIP editors who are fluent in English.

That's a fair point too, terminology / high-quality review can be provided by non-editors.

The worthiness of having non-English editors it's up if we see this as an administrative task or editorial one in my opinion.

> I think we'd agree we are somewhere in between these pure extremes and
> I'd argue mostly towards the administrative task end. One of the
> reasons I think Kanzure, RubenSomsen and Murch are good BIP editor
> candidates is that they can also provide high quality pull request
> review before potentially merging but unlike the Core repo where bad
> ideas should never be merged a BIP editor will end up merging up pull
> requests they think are bad ideas that they would never want merged
> into Core. A BIP can get a BIP number and end up being rejected by
> Core or the broader community for example.

On the experience of the inheritance rule in bip125, I would say it's not so bad if there is a minimum of editorial checks.

At least when the proposal starts to be "proposed" / "final". You don't need at first how standards are aging with time.

It's not specific to BIP, we have this issue with the BOLTs which have been amended many times to make things more robust.

I don't know if the BIP process should be more proactive "deprecating" / "obsolating" / "cleaning-up" standards like done by the IETF.

(It's clearly another set of tasks far beyond the focus of this discussion...).

> This seems even more bureaucratic to me. Different numbers to track,
> more complexity. There is a BINANA repo [0] for Bitcoin Inquisition
> for this kind of early experimentation for proposed consensus changes
> that aren't advanced enough to be BIPs.

That "fast-track" numbers assignment experiment might work with time. Let' see.

> Personally I think it is fine as it is. We are discussing the
> potential addition of high quality BIP editors as only having one
> currently (Luke) is clearly not ideal. That will alleviate Luke as a
> single bottleneck. I do think it is time for an update to the BIP
> process (BIP 3) too so BIP editors have some guidance on how to treat
> bad ideas (how bad are we talking!) and are comfortable merging pull
> requests around attempted (successful or failed) soft fork
> activations. Ultimately though just like with Core maintainers there
> is going to be some personal judgment required especially during those
> cases where there isn't clear community consensus either way. Hence
> for those cases I'd be much more comfortable with say Kanzure,
> RubenSomsen or Murch than someone we know very little about and hasn't
> demonstrated a strong understanding of how Bitcoin works.

On the contrary, the BIP process should clearly bound BIP editors personal judgement, especially at a time of lack of clear community consensus.

If there is one lesson of consensus activation or policy changes over the last few years, it's better to "wait-and-proactively-build-more-consensus" rather than "force-through".

Even if the "force-through" is coming from appointed editors or whatever, practice and respect of the process matters over titles and roles in my opinion.

For sure, anyone who has already championed a change in Bitcoin has fallen short of impatience, myself included (e.g with mempoolfullrbf).

Yet, it's good to remember that a bit of technical conservatism, over-reviewing and feedback collection is always welcome on the delicate changes.

All that said, I said my opinion on the list of BIP candidates already and I have nothing more to say.

I won't express myself further on this subject, too much code to write and review.

Best,

Antoine

[/dev /fd0]

I think before we decide new BIP editors its important to discuss some things about the process itself:

1. Quoting first paragraph from BIPs repo README: "People wishing to submit BIPs, first should propose their idea or document to the bitco...@lists.linuxfoundation.org mailing list (do not assign a number - read BIP 2 for the full process). After discussion, please open a PR. After copy-editing and acceptance, it will be published here."

If Kanzure and Ruben are BIP editors, does it mean they can censor someone from submitting BIPs? This question makes sense because they will have control over the whole improvement process for "bitcoin" by being moderators for mailing list and BIP editors.

2. How are numbers going to be assigned to BIPs?

3. Will there be copy of BIPs and pull requests maintained elsewhere like bitcoin core?

4. What are the expectations from new BIP editors? In what situation do we look for next BIP editors or in other words, what will be the process to remove an editor if lot of people are unhappy with their work?

/dev/fd0

floppy disk guy

[Michael Folkson]

> - 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.

Thanks for this analysis Dave. A minor correction, I've also
co-authored a merged BIP (BIP 343) though it was a rather short BIP
and Taproot activation related.

> --
> 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 bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/77554baa9330c57361c65c1fc85557f1%40dtrt.org.

[Ava Chow]

On 04/01/2024 07:55 PM, /dev /fd0 wrote:
> I think before we decide new BIP editors its important to discuss some
> things about the process itself:
>
> 1. Quoting first paragraph from BIPs repo README: "People wishing to
> submit BIPs, first should propose their idea or document to the
> bitco...@lists.linuxfoundation.org mailing list (do not assign a
> number - read BIP 2 for the full process). After discussion, please open
> a PR. After copy-editing and acceptance, it will be published here."
>
> If Kanzure and Ruben are BIP editors, does it mean they can censor
> someone from submitting BIPs? This question makes sense because they
> will have control over the whole improvement process for "bitcoin" by
> being moderators for mailing list and BIP editors.

If the only requirement is that a BIP shows up on the mailing list
first, then they can already censor them. Having them as BIP editors
wouldn't change that. It's not clear to me that this requirement is
strictly enforced anyways.

Furthermore, they would not have the permissions to delete PRs or
issues, so once a PR is opened, even if closed, would still be there.
The status quo w.r.t that would not be any different. At worst, they
could refuse to assign a BIP a number, but that's no different than what
already happens today. In fact, the situation would likely be better
because there would be multiple BIP editors and so what goes into the
repo is not at the whim of a single person.

> 2. How are numbers going to be assigned to BIPs?

Does it matter? The number that a proposal gets has no impact on
literally anything else. They could do it sequentially and it wouldn't
actually make a difference as long as there are no collisions.

> 3. Will there be copy of BIPs and pull requests maintained elsewhere
> like bitcoin core?

I'm not sure why this is relevant to this discussion, but presumably
there already are, and if there aren't, you can do it yourself. It's
just like any other repo on GitHub.

> 4. What are the expectations from new BIP editors? In what situation do
> we look for next BIP editors or in other words, what will be the process
> to remove an editor if lot of people are unhappy with their work?

The expectations are as outlined to BIP 2, and that they are actually
active. The situation for looking for new BIP editors in the future is
presumably similar to the one we are in currently - people who write
BIPs are frustrated with things taking a long time to be merged with the
root cause being slow response times from the current editor. The
process would likely be very similar: names are proposed, there is
discussion about those people, and eventually some are added.

As for removal, this has not been something we've ever done before, so
the process for this is undefined. However, it would presumably be a
similar procedure as for adding someone. It begins with someone raising
a complaint about one of the editors on this mailing list or some other
place a discussion, and a community discussion commences about whether
or not to remove them.

There are certainly situations where one of the GitHub org owners may
take emergency action and remove a maintainer's privileges. This is only
done when there is a clear danger than the account may do something
malicious, and the privileges would be returned if there is clarity that
it is safe to do so. For example, this was done when Luke was hacked -
all of his permissions were immediately removed as soon as the news came
out, and were only returned several months later once verified
communication with Luke were established and he was certain that his
GitHub account was no longer (at risk of being) compromised.

Ava

> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> [4]
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> [5]
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> [6]
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> [7]
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> [8]
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>

> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> [10]

> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>

> [11] 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/>

> [13]
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> [14]
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> [15]

> 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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> [17]
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails from it, send
> an email to bitcoindev+...@googlegroups.com
> <mailto:bitcoindev+...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tim Ruffing]

(Changing the subject line as this is mostly orthogonal to adding BIP
editors.)

On Thu, 2024-03-28 at 16:04 -0400, Matt Corallo wrote:
> BIP editors
> are not responsible for opining on the merit of a proposal. Their job
> is to assign numbers and
> occasionally suggest copy edits to ensure the documents are of high
> quality and readability.

As I said my previous email, this is what I'd prefer, but the current
BIP2, Section "BIP workflow" says this:

"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs include duplication of effort, disregard for formatting
rules, being too unfocused or too broad, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
must meet certain minimum criteria. It must be a clear and complete
description of the proposed enhancement. The enhancement must represent
a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly."

This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy?


By the way, Section "BIP Editor Responsibilities & Workflow" says this:

"For each new BIP that comes in an editor does the following:

- Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted. 

- [...]"

Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?

BIP2 has other problems (a lot of which date back to BIP1):
* It recommends licensing BIPs under BSD-2 or BSD-3, which are
software licenses. It's not even clear if they're applicable to
plain text. (The CC0 recommendation makes much more sense.)
* The Comments-URI thing is outdated and everyone seems to ignore it.
Comments-Summary is even weirder.
* "Informational BIPs do not necessarily represent a Bitcoin community
consensus or recommendation". Aha, does this imply that Standards
Track BIPs need to represent a Bitcoin community consensus or
recommendation?
* Ever tried to write pseudocode or LaTeX in mediawiki format? It's
more than annoying, believe me.

Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final"

* "A soft-fork BIP strictly requires a clear miner majority expressed
by blockchain voting (eg, using BIP 9)." That statement is highly
controversial. The point is that it simply doesn't belong in BIP2.
* "API/RPC and application layer BIPs must be implemented by at least
two independent and compatible software applications." same here
* Peer services BIPs should be observed to be adopted by at least 1%
of public listening nodes for one month.  

The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some Recommendation

There's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up in
the BIP header/metadata.

I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophical
merit of a BIP.

I ask everyone to read BIP2 carefully before replying here:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

Best,
Tim

[/dev /fd0]

>  Does it matter? The number that a proposal gets has no impact on
> literally anything else. They could do it sequentially and it wouldn't
> actually make a difference as long as there are no collisions.

Process followed to assign the number started this whole debate recently and creation of BINANA. Previous BIP editor refused to assign numbers to some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should be assigned number. So I am curious what process exactly would be followed by new BIP editors.

> For example, this was done when Luke was hacked -

> all of his permissions were immediately removed as soon as the news came
> out, and were only returned several months later once verified
> communication with Luke were established and he was certain that his
> GitHub account was no longer (at risk of being) compromised.

Thanks for sharing. I wasn't aware of this.

[0]: https://x.com/kanzure/status/1752663903715168280

/dev/fd0

floppy disk guy

[nvk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+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)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmKAukUZni40sZANzHN2toLREzdoFAmYMFPwACgkQHN2toLRE
zdqjqQgAsCLjBbVF505RJvIo2ZZqjWDjc0kn3pCs2+d9BHJNbd104CHUlb/TlbGL
+P1yTDTP9IJoDH833SaLlohtVFBUQbWZmBSav/rSi/4ricXg8XXXDoYb+wPgcdSo
243qh43kjMzL6gU6f4aslCS1fHVL/LDUHiRdarLekKfPsWWEE1BR+qdk+WUJiEkU
09pcZsGG+6osVDP3/oTCkkMH9/vzY+l8zwy8I3rtMByjlhk90t37YUi1dn5vrvhF
cSFkys+Um15Wnngb8W1yi4i/gfFYvHapn7KA1WaoeivbMtiJVL8XVWQiWf3Uzy+s
w3Tl+sQ3S69fIajI9StfO60Qe5dSJQ==
=w5DC
-----END PGP SIGNATURE-----

[Luke Dashjr]

No, there was no such refusal. The ONLY issue at hand with regard to more BIP editors is that I don't have time to keep up with it by myself. If your goal is anything else, please sit this discussion out (aside from perhaps reasonable objections to new editors). BIP number assignments are trivial and not a concern.

It seems there's an attempt to take advantage of the need for more BIP editors to change or bypass the BIP process without proper procedures followed. While there may be arguments for improving the BIP process, that is unrelated and would need to go through a BIP, not simply fiat of a new editor. Any potential new editor will need to follow the BIP process as it currently is defined until such a new BIP is accepted.

Luke

[Gloria Zhao]

> If we are all just in a holding pattern, perhaps we could timebox this

> decision process: how about we invite arguments for and against any

> candidates in this thread until next Friday EOD (April 5th). If any
> candidates find broad support, those candidates could be added as new
> editors to the repository on the following Monday (April 8th).

Thanks, ACK this timeline for moving forward.

Assuming they are willing, I am in favor of adding Murch, Ruben, and Kanzure as BIP editors. They have all demonstrated through years of experience contributing to / moderating {the mailing list, stack exchange, Optech} that they have the technical expertise, skills in technical documentation, and track record of good judgement appropriate for this role.

Best,

Gloria

[Luke Dashjr]

On the timeline, there has already been a very reasonable objection raised by Antoine. I'm also unlikely to be available around that time (and through the weekend) to actually do it. So it'll need to be next week at the earliest, but I don't see a problem with closer to May if that's important to some.

Luke

[Murch]

The BIP repository situation has been an on-going source of frustration
for an extended period of time, leading e.g. to Kalle being added as an
additional editor three years ago, and AJ created the BINANA repository
almost three months ago. Hence, I am not in a particular rush or
invested in the timeline of my casual proposal. My main goal was to
restart progress on the topic. However, I would prefer if objections
were accompanied by a concrete actionable alternatives as we will
otherwise just get bogged down again.

Given the concerns with the timeline, I propose that we extend the
timebox by another two weeks to solicit comments on editor candidates
until the 19th of April and aim to add more editors around the 22nd.
These dates would put the end of the comment period well after the Core
Dev meeting. If you have other concrete reasons why this timeline is
unreasonable, please state your reasons _and provide an alternative
proposal.

I agree though, that the discussion of adding additional editors and the
discussion of changing the process are two separate topics and should
not be intermingled.

Best,

Murch

[Juan Galt]

Hello there! I'm not an active contributor but I've been following the mailing list for years, and try to keep a close eye on the most important aspects of Bitcoin. 

Throwing in my support for Jon Atack and Kanzure, who's work I follow more closely. The others I am less familiar with.

Nevertheless I agree with NVK that the more editors this process has, the better. No need for this to be a bottleneck. 

Jon in particular I know has years of experience with copy editing, documentation and review of Bitcoin core code.

Cheers!

Juan Galt

[Vasil Dimov]

+1 on Jon Atack - he is familiar with the development process, has done excellent documentation before and his English is superb.

I do not know the others well enough.

Just my 2 sats.

[Fabian]

Hi,

I support the following candidates:

- Jon Atack: Jon has been a valuable contributor to Bitcoin Core for many years and has been particularly active as a reviewer there.

- Murch: Murch has been a valuable contributor to Bitcoin Core even longer and is a moderator and contributor to Bitcoin Stack Exchange as well as contributor to Bitcoin Optech.

- Kanzure and Ruben Somsen: Both have been contributing to the ecosystem overall for a long time and have also done a great job maintaining the mailing list.

I want to add that I particularly like that Jon does not have any other comparable administrative function in the Bitcoin ecosystem yet afaik. I think it's in everyone's interest that we distribute such workload to more shoulders and allow newer contributors to step into such tasks. If we only look at past references we will give all the administrative tasks to the same people. This means they will not be able to contribute as much to Bitcoin outside of those functions and could also be at higher risk of burnout.

For the others, I am either not familiar with them at all or I haven't followed their work enough lately to make a decision.

I also think it would be good to add more than one additional editor so that we have some redundancy, 2-3 sounds ideal to me.

Cheers,

Fabian

--

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 bitcoindev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9a3470ba-72dd-4466-a014-d3dede648e6dn%40googlegroups.com.

[Pieter Wuille]

Thank you for splitting off this discussion. I believe that lots of commentators who see problems with the BIPs process fail to distinguish between the editor being overloaded, and unclarity or disagreement about what the editor's job is supposed to be in the first place.

In particular, I've seen some comments akin to "assigning numbers shouldn't take that much work", while the BIP2 sections you highlight do show that the process does involve a lot more than that. Discussion about what the process is supposed to be should be separate from a discussion about who will facilitate that process.

More comments inline below.

On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing cry...@timruffing.de wrote:

BIP2, Section "BIP workflow" says this:

"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs include duplication of effort, disregard for formatting
rules, being too unfocused or too broad, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
must meet certain minimum criteria. It must be a clear and complete
description of the proposed enhancement. The enhancement must represent
a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly."

This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy?

Good point, this does seem to imply some value judgements. If we're open to making changes to what the criteria for a BIP are supposed to be, I think it ought to include:

• Formatting: contains necessary sections/headers, license, ...
• Editorial qualities: proper English, organized, ...
  
• Discussion: must have been presented on the ML or other common fora, received interest/discussion, ...
• Need for standardization: not every idea is worth publishing; if it isn't likely to affect multiple projects/pieces of software, it can just be software documentation instead.
• Scope: related to technology that supports the bitcoin currency.

This last one may be controversial, but I feel that some of the discussion the past months about the process has shown that there is unclarity/disagreement here, and it would be good to have some guideline written out here. I think scope will inevitably be somewhat of a grey zone, but I feel some limits (whether spelled out or not) will exist regardless (nobody would consider including the HTTP spec in scope for a BIP, I think?). One suggestion I have seen (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022072.html) is limiting to "extremely widespread standards used by the entire Bitcoin community", but I feel that suffers from a "no true Scotsman" fallacy (who gets to define what the "Bitcoin community" is, in a technology that to me seems designed for distrusting parties?), but would also under reasonable interpretations exclude several very useful BIPs today (some wallet standards are useful for some software and not others) and likely contribute to process friction (where do they move to?). I don't think that's a desirable situation.

I also don't think scope should be tied to specific technologies (e.g. it shouldn't just be about on-chain transactions, as e.g. that would exclude address formats), but if not that, what scoping is useful? And to me, restricting to technology that supports the bitcoin currency is fairly clear, reasonable, and avoids a circular definition. As an example, that would exclude OpenTimestamps from scope (which was suggested in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an unrelated application which happens to make use of the Bitcoin blockchain, which on itself is one of the technologies that supports bitcoin - but is an indirection too far to be in scope.

Note that however none of the criteria I list above are quality assessments; I think it is essential that BIP editors can accept BIPs they themselves find abhorrent. People can strongly disagree about whether a proposed standard is a good idea, or even whether it falls within the "Bitcoin philosophy", without disagreeing whether it is at all related to bitcoin (the currency).

By the way, Section "BIP Editor Responsibilities & Workflow" says this:

"For each new BIP that comes in an editor does the following:

- Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
- [...]"

Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?

I don't see a problem here; my interpretation is that this is exactly about excluding certain value judgements from what the editor is supposed to do: they must judge soundness and completeness, without​ trying to guess whether the community is likely to accept the idea. "sound and complete" is perhaps too vague as a criterion, but I'm in support of explicitly excluding guessing of acceptance.

BIP2 has other problems (a lot of which date back to BIP1):

* It recommends licensing BIPs under BSD-2 or BSD-3, which are
software licenses. It's not even clear if they're applicable to

plain text. (The CC0 recommendation makes much more sense.)

No strong opinion about this, but that sounds reasonable.

* The Comments-URI thing is outdated and everyone seems to ignore it.

Comments-Summary is even weirder.

Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.

* "Informational BIPs do not necessarily represent a Bitcoin community
consensus or recommendation". Aha, does this imply that Standards
Track BIPs need to represent a Bitcoin community consensus or

recommendation?

Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?

* Ever tried to write pseudocode or LaTeX in mediawiki format? It's

more than annoying, believe me.

I'd like permitting BIPs to be written in markdown.

Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final"

* "A soft-fork BIP strictly requires a clear miner majority expressed
by blockchain voting (eg, using BIP 9)." That statement is highly
controversial. The point is that it simply doesn't belong in BIP2.
* "API/RPC and application layer BIPs must be implemented by at least
two independent and compatible software applications." same here
* Peer services BIPs should be observed to be adopted by at least 1%

of public listening nodes for one month.

Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.

Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs. Instead, could we perhaps have a field that indicates objective evidence of acceptance, such as listing which software projects have implemented/adopted it?

As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about. But even then, it could be restricted to be an after-the-fact piece of evidence (whatever its activation rules are, they are met), rather than a judgement of community perception.

Regarding the "at least two independent and compatible software applications", I don't think this is a bad principle: good standards should be implementable by many, and having multiple implementations is an objective way of assessing that. I'm not sure that means being a requirement for its status, but at least an intent to have multiple implementations is a useful condition for the "Need for standardization" rule I suggest above.

The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some Recommendation

There's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up in

the BIP header/metadata.

Agreed.

I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophical

merit of a BIP

I think my view is somewhat more restrictive than yours, e.g. that BIPs ought to satisfy some scope and need for standardization criteria, but I agree that as written in BIP2 today, Editors have too many judgement calls to make.

--

Pieter

[Anthony Towns]

On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote:
> - Scope: related to technology that supports the bitcoin currency.

> This last one may be controversial, but I feel that some of the discussion the past months about the process has shown that there is unclarity/disagreement here, and it would be good to have some guideline written out here. I think scope will inevitably be somewhat of a grey zone, but I feel some limits (whether spelled out or not) will exist regardless (nobody would consider including the HTTP spec in scope for a BIP, I think?).

> I also don't think scope should be tied to specific technologies (e.g. it shouldn't just be about on-chain transactions, as e.g. that would exclude address formats), but if not that, what scoping is useful? And to me, restricting to technology that supports the bitcoin currency is fairly clear, reasonable, and avoids a circular definition. As an example, that would exclude OpenTimestamps from scope (which was suggested in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an unrelated application which happens to make use of the Bitcoin blockchain, which on itself is one of the technologies that supports bitcoin - but is an indirection too far to be in scope.

For BINANA I phrased that as "proposals only being rejected if they are
... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is
dumb and ignoring it wastes a lot less time than arguing about whether
it's a good thing for the monetary properties of Bitcoin (which is what
I'm interested in helping people work on).

For example, would adding script opcodes whose only purpose is to better
support moving BTC to/from sidechains like Liquid or WBTC on Eth, where
they can be used as collateral in market makers for trading other tokens
count as "supporting the bitcoin currency"? This might include such
things like Drivechains (BIP 300, 301), eg. Is such a feature more about
supporting asset trading, or is anything that involves buying/selling
things with Bitcoin count as supporting bitcoin as a currency?

Does it make a difference that a script opcode would be consensus
critical? Another way of allowing trading between BTC and other assets is
the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between
BTC and tokenized assets on the Bitcoin blockchain, but don't require
consensus changes. If the BIPS repo includes docs on Drivechains, is
excluding proposals about Taproot Assets or RGB or similar that valuable?

Those all seems arguable to me; but why force people to have those
arguments over making up a number and hosting a document in a git repo?

> > * The Comments-URI thing is outdated and everyone seems to ignore it.
> > Comments-Summary is even weirder.
> Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.

For BINANA I added a "Discussion" header where the BIN author can point to
locations where discussion has/can take place -- it seemed like a useful
thing to have beyond just links in the "rationale", both for researching
background into the proposals development, and as a pointer to somewhere
people can leave additional feedback. I don't think there's much value in
having a dedicated discussion area in the BINANA/BIP repo itself though.

> > * "Informational BIPs do not necessarily represent a Bitcoin community
> > consensus or recommendation". Aha, does this imply that Standards
> > Track BIPs need to represent a Bitcoin community consensus or
> > recommendation?
> Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?

Documenting consensus change activation seems useful if nothing else,
eg as in BIP 90.

> > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
> > more than annoying, believe me.
> I'd like permitting BIPs to be written in markdown.

This is already permitted, see https://github.com/bitcoin/bips/pull/1504

> Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.
>
> Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs.

I think "Proposed" is much more related to community acceptance than
"Active" -- you can reasonably say something is "Active" once a single
implementation has a released version that actively supports it, for
example; but describing a standard as "Proposed" seems to be pretty
clearly trying to achieve so form of community acceptance? Who else
would you be proposing it to?

I'd look at the lifecycle more as something like:

* Draft: author expects further changes, don't deploy this
* Proposed: author is hoping for multiple implementations to adopt this;
author thinks it's complete, but there may be objections and it may
need to go back to Draft state to resolve those objections
* Active: one or more implementations have deployed this feature as
specced. changes will usually be specified in a new proposal/standard.
acceptable changes might be fixing ambiguities, adding extra rationale
or test cases, etc.
* Withdrawn: no current implementations support this, author doesn't
think it should be adopted, author isn't planning on making further
changes to it

For comparison, BINANA currently has BINs marked Draft, Active and Info:
https://github.com/bitcoin-inquisition/binana

(Note that adding a consensus change in inquisition and doing a heretical
activation of that change on signet would still leave the spec in "Draft"
-- further changes are expected)

(As far as BIP 2's list goes, I think Deferred should just be Draft;
Rejected/Obsolete should just be Withdrawn; Final should just be Active;
and Replaced should either be Withdrawn or Active depending on whether
the replacement is backwards compatible, accompanied by Superseded-By)

> As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about.

How about BIP 148 or BIP 91? I think it's fair to call both of those
"Active" and would have been fair to mark them Active sometime in
April-July 2017 -- that doesn't mean there was necessarily community
consensus behind them: merely that there was software implementing
those standards active on the network, and that if someone wanted to do
something similar but different, that would warrant being a different
standard. If it had turned out there wasn't consensus behind either
proposal, and no one was mining a blockchain that those implementations
would accept, at most that would warrant the author marking the BIPs as
"Withdrawn" IMO.

The same argument applies to BIP 343 I think. I believe only one
implementation adopted it [0], and I don't believe any actively maintained
software implements that BIP as written, but if you did implement it
you'd continue to track the bitcoin blockchain, so I think it would
be fair to have marked that BIP as "Active" once it was adopted by an
implementation, and to have left it marked that way.

[0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist
in web.archive.org.
https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html

If the segwit2x fork had ever had a written spec, I likewise think it
would have been appropriate for it to be a BIP, perhaps being marked as
Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on
either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo
was marked as archived).

[1] https://github.com/btc1/bitcoin/pull/50
[2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

Cheers,
aj

[Niklas Goegge]

Hi,

Assuming they are willing, I am supportive of Kanzure, Ruben, Laolu and Murch as BIP editors.

Best
Niklas

[0xB10C]

I support Kanzure, Ruben, Atack, and Murch as new BIP editors. 

[Larry Ruane]

I support Atack and Murch as BIP editors. I know both personally; I don't know Kanzure, Ruben, or Roasbeef, but from my general impression and what I read here, they would be good choices too.

I'll mention some reasons for support for Jon Atack.

• He's neutral and independent; he does not align himself with factions
• He's written many excellent PR review comments, demonstrating good writing skills. Being a BIP editor doesn't involve (much) writing, but good writing skill allows one to evaluate others' writing
• His articles on https://jonatack.github.io/articles have been helpful to me; he's contributed to Optech and PR Review Club
• He's been highly committed to bitcoin and bitcoin core for many years, even living the bitcoin life in El Salvador
• He has many relationships in the bitcoin community and seems to get along well with everyone

My reasons for supporting Murch can be briefer because he's so well-known, and I agree with what others have written.

• He's contributed to bitcoin and core in myriad ways, too many to mention
• Many of his contributions have revolved around writing (Optech, StackExchange, conference presentations)
• He has a good "big picture" view of all of the bitcoin ecosystem while simultaneously having a deep technical understanding of several areas

[Ali Sherief]

> Just as you don't need to be a maintainer to provide high quality pull
request review in the Core repo you don't need to be a BIP editor to
provide high quality pull request review in the BIPs repo. There is
nothing to stop people who aren't BIP editors continuing to provide
review of your work in English and a BIPs repo in English only needs
BIP editors who are fluent in English.

Just thought I might pop in and make a comment about this. I think it's better to keep the main repository of BIPs in english, and then have a translations subdirectory for each language. Then you can have the BIPs translated on a volunteer basis, either with by pull requests or a platform like Transifex. But only have the english version as the authoritative reference.

Although I am in favor of having additional maintainers in general - it would make it easier to collaboratively review drafts like BIP322.
---
Ali

>> >> On Friday, March 29, 2024 at 1:47:41 AM UTC+5:30 Matt Corallo wrote:
>> >>>
>> >>> Please provide justification rather than simply saying "I like Bob!".
>> >>>

>> >>> Matt
>> >>>
>> >>> On 3/28/24 12:09 PM, /dev /fd0 wrote:
>> >>> > I support Jon Atack and Roasbeef from this list.
>> >>> >
>> >>> > On Thursday, March 28, 2024 at 6:57:53 PM UTC+5:30 Murch wrote:
>> >>> >
>> >>> > I just went through the thread, previously mentioned were:
>> >>> >
>> >>> > - Kanzure
>> >>> > - Ruben Somsen
>> >>> > - Greg Tonoski
>> >>> > - Jon Atack
>> >>> > - Roasbeef
>> >>> > - Seccour
>> >>> >
>> >>> > And Matt just suggested me for the role. Hope I didn’t overlook anyone.
>> >>> >
>> >>> > On 3/27/24 19:39, John C. Vernaleo wrote:
>> >>> > > That said, I would find it helpful if someone could go through the
>> >>> > > thread and list all the people who've been proposed so people know who
>> >>> > > they should be thinking about.
>> >>> >

>> >>> > --
>> >>> > 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

>> >>> > bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.

>> >>> > To view this discussion on the web visit

>> >>> > https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.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 bitcoindev+...@googlegroups.com.

>> > To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegroups.com.

[Sergi Delgado Segura]

> 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

--

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 bitcoindev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com.

--

Sergi.

[Matt Corallo]

Strongly agree with Sergi here,

I'd suggest 2-3 BIP editors who are actually responsible for things is more useful than 5 BIP
editors where no one is responsible for anything.

Again, I'm not convinced dumping this on more people is useful, folks like Roasbeef are great but
clearly don't have time to keep up with yet more things, and not sure why folks are on the list here
who haven't been active on the Bitcoin-dev ML and in BIPs for many years (eg no idea who Seccour is).

Matt

On 4/11/24 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 <rdl...@gmail.com <mailto:rdl...@gmail.com>> 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)

> 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/ad284018-e99c-4552...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> [17]
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails from it, send an email to

> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.

> 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?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

> bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.

> 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?utm_medium=email&utm_source=footer>.

[Tim Ruffing]

I fully agree with Sergi and Matt here. 

(Sorry, this is just a +1 message, but I really don't have anything
meaningful to add to their arguments.)

Tim

> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d979275
> > 5...@achow101.com/>
> >         [2]
> >        
> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >        
> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a6
> > 2...@dashjr.org/>
> >         [3]
> >        
> > https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f12
> > 9a...@googlegroups.com/>
> >         [4]
> >        
> > https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b
> > 7...@netpurgatory.com/>
> >         [5]
> >        
> > https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157
> > fa...@googlegroups.com/>
> >         [6]
> >        
> > https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d
> > 00...@googlegroups.com/>
> >         [7]
> >        
> > https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efb
> > ea...@googlegroups.com/>
> >         [8]
> >        
> > https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgL
> > EazRA5nVw...@mail.gmail.com/>

> >         [9]
> > https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >        
> > <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >         [10]
> >        
> > https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
> >        

> > <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9
> > b...@mattcorallo.com/>

> >         [11]
> > 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+EKMCP5oEb
> > HSKSXpq0V...@mail.gmail.com/>
> >         [13]
> >        
> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >        
> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e
> > 7...@murch.one/>
> >         [14]
> >        
> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0
> > 6...@achow101.com/>

> >         [15]
> >        
> > 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/ad284018-e99c-4552...@googlegroups.com/
> >        

> > <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340
> > 66...@googlegroups.com/>
> >         [17]
> >        
> > https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd
> > 9Qrst+nmy...@mail.gmail.com/>

[NVK]

I understand the skepticism with more people. I was also skeptical about having larger committees, but after doing working on the open stats board which is 9 people and it being extremely efficient and practical I've changed my outlook on the numbers.

What do you do gain is more people to be available to review applications. Which is often the bottleneck. I doubt there would be much contention on the opinions of the group.

Just my two 2 cents.

(mobile)

> On Apr 16, 2024, at 08:16, Tim Ruffing <cry...@timruffing.de> wrote:
>
> I fully agree with Sergi and Matt here.

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a7b4924d7148f85b1a7676a1c113eccc0b06cc86.camel%40timruffing.de.

[Ava Chow]

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

> - NVK (temp gmail account)

> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
> [2]
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> [3]
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> [4]
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> [5]
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> [6]
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> [7]
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> [8]
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>

> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> [10]

> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>

> [11] 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/>
> [13]
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> [14]
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> [15]
> 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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> [17]
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails from it,
> send an email to bitcoindev+...@googlegroups.com

> <mailto:bitcoindev+...@googlegroups.com>.

> 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?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 bitcoindev+...@googlegroups.com

> <mailto:bitcoindev+...@googlegroups.com>.

> 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?utm_medium=email&utm_source=footer>.

[nsvrn]

I would like to personally raise caution against Kanzure. I'm sure he's more than capable if so many people believe so but just want to highlight that based on his own public twitter thread, he claimed that he has better things to do. Unless he comes forward and doesn't hold that position anymore, I would think it might not end up being very fruitful if people chose him here based on the votes based on some assumptions.

https://x.com/kanzure/status/1766888650069967053

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com.

[Olaoluwa Osuntokun]

Hi y'all,

> 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.

I followed up on this with achow directly and realized that she reached out
to me via a DM on IRC. I haven't lurked on IRC for many many months now (but
this prompted me to lurk once again!), so I missed the original message.

After DM'ing on X back and forth a bit to get some clarity on the proposed
role, I'd be comfortable with being added as one of the (3?) new BIP
editors. I think it's unfortunate that the BIP process has decayed over the
past year or so (particularly with all the new dev activity), so if I can
lend my time to help restore the process, then I'd be happy to do so 🫡.

In terms of load, if I were to be added, given that we'd now have 4 (?)
total BIP editors, I don't envision the load would be concentrated on any
one individual.

-- Laolu

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com.

[Ava Chow]

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:

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com.

[NVK]

Good number of people.

Looking forward and congrats.

> On Apr 20, 2024, at 14:30, 'Ava Chow' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
>
> Since we're now past the deadline of April 19th, I'd like to inform

> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com.

[Michael Folkson]

Ava

> 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.

Is Luke happy with this? That is a lot of new editors to onboard. I
suspect you'd push back against adding 5 maintainers overnight to
Bitcoin Core and I'm not sure why this is any different. What happens
if there is disagreement between these now 6 BIP editors on merge
decisions? If Luke is fine with this ok but it seems like the BIPs
repo is going to be a free for all from now on.

Thanks
Michael

> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com.

[Ava Chow]

On 04/20/2024 03:59 PM, Michael Folkson wrote:
> Is Luke happy with this? That is a lot of new editors to onboard. I
> suspect you'd push back against adding 5 maintainers overnight to
> Bitcoin Core and I'm not sure why this is any different. What happens
> if there is disagreement between these now 6 BIP editors on merge
> decisions? If Luke is fine with this ok but it seems like the BIPs
> repo is going to be a free for all from now on.

My understanding is that he is okay with it, and I've talked to him
privately numerous times about this since this thread was started.

This is different from Bitcoin Core in that there is currently only one
BIP editor who has clearly stated more editors are needed. BIPs is also
a fairly low risk repo as it's just documentation.

The expectation is that each editor will be able to work independently;
obviously they should be communicating, but it's not a committee. I'm
sure there will be some disagreement eventually, but ultimately, I think
all of the candidates are professionals who can handle that maturely.
Obviously a revert war would be a problem, but I don't think it would
come down to that, and in that case, participants in that should be
promptly removed.

Ava

[Ava Chow]

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/83b69000-ca1e-4a58...@googlegroups.com/
[2]:
https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/

>
> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> Mailing List <bitco...@googlegroups.com

> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>

> >>          [2]
> >>
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
> >>          [3]
> >>

> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>
> >>          [4]
> >>
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>
> >>          [5]
> >>
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>
> >>          [6]
> >>
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>
> >>          [7]
> >>
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>
> >>          [8]
> >>
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@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/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >>          [10]
> >>

> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@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+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@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...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>
> >>          [14]
> >>
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/

> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>
> >>          [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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>
> >>          [17]
> >>
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails
> from it,
> >>      send an email to bitcoindev+...@googlegroups.com

> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >>      <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>>.

> >>      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 bitcoindev+...@googlegroups.com

> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >> <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>>.

> >> 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 bitcoindev+...@googlegroups.com

> <mailto:bitcoindev%2Bunsu...@googlegroups.com>.

> > 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 bitcoindev+...@googlegroups.com

> <mailto:bitcoindev%2Bunsu...@googlegroups.com>.

> 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>.
>

[Steve Lee]

Wasn't there evidence provided that Kanzure does not want this responsibility without being paid?

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?

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com.

[Steve Lee]

On Sat, Apr 20, 2024 at 2:08 PM Ava Chow <li...@achow101.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 him
about being a BIPs editor.

You should read this thread then before making a decision. 

> 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.

Ok good to know. Would've been nice to share this here so everyone was aware. 

[Ava Chow]

On 04/20/2024 05:11 PM, Steve Lee wrote:
>
> I am not aware of that, and it hasn't come up when I've talked to him
> about being a BIPs editor.
>
>
> You should read this thread then before making a decision.

Thank you for your snarky reply.

I have, in fact, read every email in this thread. But there's 80+ emails
in this thread and it's spread over 2 months, so it's possible I've
missed something. With that in mind, I've just spent the last 10 minutes
searching through the archive and cannot find any mention of Kanzure or
anyone else saying that he would only be a BIP editor for payment. If
you think I'm mistaken, I ask that you please provide a link to this
evidence.

> 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.
>
>
> Ok good to know. Would've been nice to share this here so everyone was
> aware.

You should read this thread before making such assumptions.

I informed the list[1] 4 days ago that I reached out privately to and
got responses from Kanzure and Ruben. While I did the same with Jonatack
and Murch, I did not feel the need to mention that because, if you've
read this thread, they had already publicly confirmed their willingness.

Ava

[1]:
https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8...@achow101.com/

>
>
>
> Ava
>
> [1]:
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/>
> [2]:
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>

>
> >
> > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> > Mailing List <bitco...@googlegroups.com
> <mailto:bitco...@googlegroups.com>

> > <mailto:bitco...@googlegroups.com

>  <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>>

> >      >>          [2]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >
>  <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
> >
>  <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>>
> >      >>          [3]
> >      >>
> >

> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>>
> >      >>          [4]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>>
> >      >>          [5]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>>
> >      >>          [6]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>>
> >      >>          [7]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>>
> >      >>          [8]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@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/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >      >>
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>>
> >      >>          [10]
> >      >>
> >

> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@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/>>
> >      >>
> >     <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+E...@mail.gmail.com/ <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+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@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...@murch.one/
> <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...@murch.one/> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>>
> >      >>          [14]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> >

>  <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>>
> >      >>          [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/>> <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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>>
> >      >>          [17]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails
> >     from it,
> >      >>      send an email to
> bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>

> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>
> >      >>      <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>>.

> >      >>      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 <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> <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 bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>

> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>
> >      >> <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>>.

> >      >> 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 <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> <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 bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>

> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>.

> >      > 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> <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 bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>

> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>.

> >     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> <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>>.
> >
>

[Steve Lee]

nsvrn posted a days ago. Here's the tweet 

https://x.com/kanzure/status/1766888650069967053

Ava, I'm just requesting people acknowledge legitimate concerns raised and be transparent. Do you disagree?

[Ava Chow]

I saw that email and read the tweet. It doesn't seem to me that nsvrn
was raising an objection to Kanzure, just pointing out something for
people to consider. No one else has said anything, so I'm assuming that
no minds have changed considering this information. It'd be ridiculous
if every time new information was presented that we went to everyone and
ask them whether their stance has changed. It's all the same email
thread, if their mind has changed, then they can inform us as a reply.

Furthermore, I fail to see how this tweet matches your claim that he
"does not want this responsibility without being paid". Saying that he
has better things to do with his time doesn't necessarily mean that he
won't do it, and other such tweets, including his own replies to this
one, indicate the he is.

If your concern is about his reply to the suggestion that being paid
would change things substantially, I still don't see how that matches
the statement you made earlier. Being paid to do any task would change
the calculus on whether someone wants to do something, but that doesn't
mean they won't do it even if unpaid.

Ava

> https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8...@achow101.com/>
>
> >
> >
> >
> >     Ava
> >
> >     [1]:
> >
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58...@googlegroups.com/>>
> >     [2]:
> >
> 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...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>

>  <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>>>

> >      >      >>          [2]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >
>  <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
> >      >
> >
>  <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>>
> >      >
> >
>  <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>>>
> >      >      >>          [3]
> >      >      >>
> >      >
> >

> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>>>
> >      >      >>          [4]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>>>
> >      >      >>          [5]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>>>
> >      >      >>          [6]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>>>
> >      >      >>          [7]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>>>
> >      >      >>          [8]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@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/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >      >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>>
> >      >      >>
> >      >
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >      >
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >
>  <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>>>
> >      >      >>          [10]
> >      >      >>
> >      >
> >

> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@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/>>
> >      >
>  <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/>>>
> >      >      >>
> >      >
>  <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/>>
> >      >
>  <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+E...@mail.gmail.com/ <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+E...@mail.gmail.com/> <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+E...@mail.gmail.com/ <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+E...@mail.gmail.com/>> <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+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@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...@murch.one/
> <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...@murch.one/>
> >
>  <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...@murch.one/ <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...@murch.one/>> <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...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>>>
> >      >      >>          [14]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> >
>  <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>
> >      >
> >

>  <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>>>
> >      >      >>          [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/>> <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/>>> <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/>> <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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>>>
> >      >      >>          [17]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@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 emails
> >      >     from it,
> >      >      >>      send an email to
> > bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>

> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>
> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>

> >      >      >>
> <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>
> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>

> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>>.

> >      >      >>      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 <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> <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> <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>> <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> <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
> bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>

> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>
> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>

> >      >      >> <mailto:bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>
> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>

> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>>.

> >      >      >> 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 <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> <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> <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>> <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> <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
> bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>

> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>
> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>.

> >      >      > 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> <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>> <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> <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
> bitcoindev+...@googlegroups.com
> <mailto:bitcoindev%2Bunsu...@googlegroups.com>
> >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>>

> >      >     <mailto:bitcoindev%2Bunsu...@googlegroups.com
> <mailto:bitcoindev%252Buns...@googlegroups.com>
> >     <mailto:bitcoindev%252Buns...@googlegroups.com
> <mailto:bitcoindev%25252Bun...@googlegroups.com>>>.

> >      >     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> <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>> <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> <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>>>.
> >      >
> >
>

[Michael Folkson]

Ava

> Obviously a revert war would be a problem, but I don't think it would
come down to that, and in that case, participants in that should be
promptly removed.

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.

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?

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.

> BIPs is also a fairly low risk repo as it's just documentation.

Lower risk than say the Bitcoin Core repo sure but just throwing a
large number of new editors at it makes it seem like you don't care
what happens there.

I've seen Wladimir is contributing again to Core. Is there a plan to
give him commit access again? 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.

Thanks
Michael

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/0d4d85e3-9fbb-4bd4-af0f-92225e699b63%40achow101.com.

[Ava Chow]

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

[Michael Folkson]

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/

[Ava Chow]

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.

[Michael Folkson]

> 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 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.

Michael

[Ava Chow]

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 Folkson]

> I did not say that they can write anything, do not put words in my
mouth.

Your statement was "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." I'm not putting
words into your mouth, those are your words.

> 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.

Indeed. I would rather that BIP process refinement had been completed
before we went from 1 BIP editor to 6 BIP editors, most of which have
barely participated in the BIP process in the past and will have very
different perspectives on what should or should not be merged. But
that is apparently "concern trolling" so agreed there is no point
continuing this.

[Antoine Riard]

> 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

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 bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.com.

[Matt Corallo]

I'm a bit confused, several people have suggested that Roasbeef clearly doesn't have the time
commitment to be added as a BIP editor, and I previously noted that of the list of people, only
Kanzure and Murch have been around for a long period of time and demonstrated depth in the kind of
Bitcoin technical nomenclature and copy-editing required for this role, largely via Kanzure's long
history of Bitcoin technical transcriptions and Murch's work on stack exchange and the nomenclature
BIP at https://github.com/murchandamus/bips/pull/1/files.

For the avoidance of doubt, this is an objection to the rest of the list.

Matt

[Ava Chow]

Okay, it was not clear to me that the questions about whether he had the
time were actually objections. However, his response[1] indicates that
he does not think that time will be an issue, so I think that complaint
is sufficiently addressed.

As for Ruben and Jon, I think it's clear that others on this list think
that they are well suited for the role.

Ava

[1]:
https://gnusha.org/pi/bitcoindev/CAO3Pvs8B+NVWFUxg6zfNXYrA...@mail.gmail.com/

[Steve Lee]

Hi Ava,

I hadn't seen until just now your post prior to nsvrn's post which stated:

"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."

This is exactly what I had a concern about, and I unfortunately hadn't seen it before replying to this thread. I apologize for the unnecessary responses from me.

Thanks for dealing with all of this and helping us drive to a conclusion.

Steve

[Ali Sherief]

Very good and hopefully this makes the BIPs repository more active.

I just have one suggestion though. Considering the backlog of BIP modification PRs on github, It is quite inconvenient to hold a discussion about one when there aren't other participants, particularly for the pull requests that are several months old. Perhaps the new editors could also facilitate clearing the backlog by means of discussion on these old pull requests? I don't see anyone else participating in the evaluation process for them except maybe the BIP author(s), but it takes more than one person to hold a discussion.

-Ali

[Anthony Towns]

On Sat, Apr 20, 2024 at 07:14:34PM +0000, 'Ava Chow' via Bitcoin Development Mailing List 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.

Thanks for pushing this forward, Ava!

One thing though:

> There has not been any actual objections to the nominees nor have there

When choosing personnel, asking for public objections is probably a
pretty bad approach. It's hurtful to the person being objected to, both
when the objections are accurate and when they aren't, and, especially
if the objections end up being ignored, it's harmful to the working
environment when the person who objected has to work with the person
they objected to in future.

Personally, I'd suggest focussing more on "are they demonstrably doing
useful work? yes, then they keep or increase their perms; no, then
decrease their perms". (Probably couldn't have done anything different
this time around, but maybe something to keep in mind for the future)

Along those lines, it might be worth having a review in six months or
so to see which of the editors and processes have been effective, and
which ones haven't, and see if there's anything worth changing further
to increase the wins and diminish the losses. Could be worth making
something like that a regular thing (once a year?); for the Debian
Technical Committee, we had somewhat similar problems with inactivity
and a lack of renewal, which (IMO) was fixed in a big part just by
having a policy of saying "okay, longest serving member gets booted,
remaining folks should invite someone new" once a year.

Anyway, it's easy to quibble about what the best process might be,
but actual results are more important, so thanks again Ava!

Cheers,
aj

[Antoine Riard]

Hi AJ,

> When choosing personnel, asking for public objections is probably a
> pretty bad approach. It's hurtful to the person being objected to, both
> when the objections are accurate and when they aren't, and, especially
> if the objections end up being ignored, it's harmful to the working
> environment when the person who objected has to work with the person
> they objected to in future.
>
> Personally, I'd suggest focussing more on "are they demonstrably doing
> useful work? yes, then they keep or increase their perms; no, then
> decrease their perms". (Probably couldn't have done anything different
> this time around, but maybe something to keep in mind for the future)

> Along those lines, it might be worth having a review in six months or
> so to see which of the editors and processes have been effective, and
> which ones haven't, and see if there's anything worth changing further
> to increase the wins and diminish the losses. Could be worth making
> something like that a regular thing (once a year?); for the Debian
> Technical Committee, we had somewhat similar problems with inactivity
> and a lack of renewal, which (IMO) was fixed in a big part just by
> having a policy of saying "okay, longest serving member gets booted,
> remaining folks should invite someone new" once a year.

I'm respectfully dissenting here. Decade(s)-old IETF / BIP standards

are kinda open-source commons after-all, and this is very expected than

someone who is aspiring to get perms in their maintenance have to answer

objections from the non-permissioned people enjoying  usage of the

commons.

Yes, it can hurt to have to answers public objections on your person

when you're aspiring to open-source perms. I think that's part of the

process, if you wish a comfortable job you can always go to work at

$YOUR_LOCAL_BIG_TECH (tm). Additionally, one can wish to be sure

that the candidate have sufficient level of ethics / personal integrity.

Especially, to serve as a check-and-balance when one has to conduct

privileged actions in the execution of permissions.

W.r.t, I can only invite anyone to read the ACM Code of Ethics:

https://www.acm.org/code-of-ethics

(Far from perfect as ethics is a dynamic concept after-all, though can

provide guidelines if you're entitled with perms in this space, and you

don't know how to act in a given instance).

Apart of that, I think the idea of the longest serving members in a

set of maintainers / editors without substantial activity getting booted

every X and remaining folks can invite someone new can serve as a not

so bad rule of thumb.

To conclude, I'm rejoicing too on seeing concrete results in the nomination

of BIP editors, which doesn't forbid ulterior discussions on improving its

process.

Best,

Antoine