OpenBIPs: A New Process for BIP Management

[JaimeCaring]

It has become necessary to reclaim the BIP process from the current editorship. There are no defined processes, procedures, or rules for doing so.

I have created OpenBIPs to resolve the lack of a defined procedure.

I will serve as the initial BIP Editor, but I will remove my access by June 1st, 2021 or as soon as replacements have been appointed. During my tenure as BIP Editor, I intend to process PRs neutrally and fairly. In the interest of efficiency, should authors choose not to open their own PRs on OpenBIPs, I will pull and merge Taproot related patches to bitcoin/bips that have been ACK'd sufficiently by April 29th. My singular goal as editor of OpenBIPs is to ensure that the BIP repository's master branch is a canonical and unbiased source of information for the community.

Details of how OpenBIPs intends to select new editors can be found here:
https://github.com/JaimeCaring/OpenBIPs/blob/master/bip-0002.mediawiki#bip-editor-replacement-and-stewardship

If you are on the list of names below, you have been selected as a Steward to the process.

For some, this merits a congratulations. For others, it comes with my sincerest and deepest apologies. I have tried to make the OpenBIPs process accommodating for you to not have to participate should you so choose. It would be helpful if you do choose not to participate if you could do so explicitly by either naming a successor Steward or by explicitly noting that you will not participate at your earliest convenience.

@achow101 Andrew Chow
@ajtowns Anthony Towns
@dongcarl Carl Dong
@Empact Ben Woosley
@gmaxwell Gregory Maxwell
@harding David A. Harding
@hebasto Hennadii Stepanov
@instagibbs Gregory Sanders
@jnewbery John Newbery
@jonasschnelli Jonas Schnelli
@jonatack Jon Atack
@kallewoof kallewoof
@laanwj W. J. van der Laan
@MarcoFalke MarcoFalke
@morcos Alex Morcos
@practicalswift practicalswift (Thomas J)
@promag João Barbosa
@ryanofsky Russell Yanofsky
@sdaftuar Suhas Daftuar
@sipa Pieter Wuille
@Sjors Sjors Provoost
@TheBlueMatt Matt Corallo
@theuni Cory Fields

Stewards have the ultimate authority as defined via the OpenBIPs process, but the true ultimate authority rests with the community to accept this process. Stewards may make their decisions however they choose, and may even prefer to vote to restore OpenBIPs to the current governance structure and editorship of bitcoin/bips.

There was no pre-communication or planning among the above names before this action was taken. It is initiated as an individual effort. As such, please do not harass or otherwise abuse any of the above individuals if you consider this attempt at fixing the BIP process as contemptible. Any blame rests solely with myself. You should focus your criticisms on the "how, why, and when" as opposed to the "who".

Best,

@JaimeCaring

[casey]

I appreciate the sentiment behind this proposal, but I think it's premature at the moment. Although there have recently been issues with the existing BIP repository, there's a good chance that those can be resolved to everyone's satisfaction. I think that alternate BIP repositories should be considered only if the issues with the existing BIP repository cannot be resolved.

[JaimeCaring]

It's rough social consensus that @luke-jr is unfit to continue serving in this role. It's merely unpleasant to see through that he's actually removed. The purpose of this proposal now is to avoid getting to the point of preposterous conduct where there's no other path and we have less ability to engender a smooth transition of power. That the changes have been merged reduces the urgency, but it doesn't change what we must do.

I've attached some bits and pieces below that make the need absolutely clear that the work begin now to replace @luke-jr and ensure that the BIP process never becomes captured by a centralized editor; and that we begin the work of repairing the reputation damage from @luke-jr's procedural lapses that would cause @TheBlueMatt and @gmaxwell to believe the BIP process is dead.

---

@gmaxwell

Maybe if you don't know whats going on you ought to ask questions or not comment? :P

Years ago I appointed luke BIPs editor. It's a clerical role with little editorial input. Currently, luke is abusing that position by ignoring updates to the taproot spec by its authors because he doesn't like the authors or the updates. He is ignoring most attempts to communicate or responding with useless insults. Instead of applying the updates ( as is required by process ) he instead went and released incompatible software (deceptively named similar to Bitcoin core and claiming to be taproot though it breaks the spec). That software is the subject of the thread.

The matter is pressing both because of the deceptive 'activation client' linked here but also because the actual taproot proposal signaling start date was a few hours ago.

I would have loved to have a conversation with luke elsewhere but he has been completely unresponsive. At some point the community is going to need to remove him if he continues like this, and from past experience I know it's better if it doesn't look like it came out of nowhere.

Edit: 17 hours after thins comment. It's now been merged. What an absurd waste of time.

https://www.reddit.com/r/Bitcoin/comments/mruopv/bitcoincorebased_bip8_lottrue_taproot_activation/gvscx0c/?utm_source=reddit&utm_medium=web2x&context=3

Luke's response?

Liar

---

@TheBlueMatt

There appears to be some severe lack of understanding of the point of the BIP process here.

The BIP process exists to be a place for those in the Bitcoin development community (which includes anyone who wishes to
participate in it!) to place specifications which may be important for others in the Bitcoin development community to
see, to ensure interoperability.

It does not, should not, and has never existed to take any positions on...anything. It has always existed to allow those
who wish to participate in the Bitcoin development community to publish proposed standards or deployed protocols, in
whatever form the authors of the BIPs seem fit.

If anyone suggests changes with a BIP's proposed form in a way the original author does not agree with, they have always
been free to, and should simply create a new BIP with their proposed form.

The BIP editor's role has always been, and should continue to be, to encourage BIP authors to respond to (either by
dismissing or accepting) feedback on their BIPs, and encourage formatting in a standard form. The BIP editor's role has
never included, and should not include, taking a stance on substantive changes to a BIP's contents - those are up to the
author(s) of a BIP, and always have been.

If the BIP editor is deliberately refusing to accept changes which the author's approval (which appears to be occurring
here), the broader development community (us) should either remove the BIP editor and replace them, or simply ignore the
BIP repository entirely (which seems like the most likely outcome here). There really should be no debate over this
point, and I'm not entirely sure why anyone would think there should be.

Luckily BIPs aren't really all that critical in this instance - they exist to communicate protocols for
interoperability, and in this case the protocol changes as proposed have been broadly communicated already.

Still, given the apparent lack of desire to remove the BIP editor in this case, I'd suggest we all move on and simply
ignore the BIP repository entirely. Simply sending notices of protocol systems to this mailing list is likely sufficient.
/---------------------
In general, I think its time we all agree the BIP process has simply failed and move on. Luckily its not really all that
critical and proposed protocol documents can be placed nearly anywhere with the same effect.

---

@gmaxwell again

@michaelfolkson Luke-jr was asked a while ago if he would be okay with one of the BIP authors simply merging the change if, for whatever reason, he didn't want to do it himself (since among the authors there are already people who have the technical ability to do so, but won't bother if it's just going to create more drama). He failed to respond, as he has with essentially every other attempt to communicate (or in a just responded with some few words insults).

I believe that every opportunity has been granted to luke here to help him navigate whatever conflict he feels here, certainly if something has been missed he could freely speak up himself rather than you speaking for him. He has consistently responded in an unprofessional and unreasonable manner. If he is unable to faithfully execute the role I granted him, he should return it.

As it stands, the obstruction here has spanned past the start time. As such it would be reasonable to say that at the moment the BIP process is currently in a failed state, because its supposed to allow authors to publish specifications needed for inter-operation with their proposals, particularly live ones and the BIP in the unmerged state is unusable for inter-operation with the author's proposal. Now-- since people are free to ignore the BIPs repository and often do, this failure is not especially cosmic in its importance but this is only because the entire BIP process is relatively unimportant. Absent it, authors will continue to write specifications-- but they will just be somewhat less consistently written, more difficult to locate, and more prone to falling offline when their authors lose interest (as is the case for other projects without an analogous setup).

As far as kallewoof's comment I'm not sure of what to say. I saw the proposal, had reservations, and figured it would be prudent to check if he even intended to touch this thing before even bothering to go into the reservations. So I wrote to him directly and he gave a position which was diametrically opposed to the one posed here. After I posted he responded privately with another message saying that he was still considering luke's counterarguments. I'm happy to hear the public revised position, but it remains my view that yanking him into this is not a great idea (and not particularly fair to kallewoof either). ... but this is way off-topic for this PR.

---

@ariard

Hi Luke,

For the records and the subscribers of this list not following #bitcoin-core-dev, this mail follows a discussion which did happen during yesterday irc meetings.
Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log

I'll reiterate my opinion expressed during the meeting. If this proposal to extend the bip editorship membership doesn't satisfy parties involved or anyone in the community, I'm strongly opposed to have the matter sliced by admins of the Bitcoin github org. I believe that defect or uncertainty in the BIP Process shouldn't be solved by GH janitorial roles and I think their roles don't bestow to intervene in case of loopholes. Further, you have far more contributors involved in the BIP Process rather than only Bitcoin Core ones. FWIW, such precedent merits would be quite similar to lobby directly GH staff...

Unless we harm Bitcoin users by not acting, I think we should always be respectful of procedural forms. And in the lack of such forms, stay patient until a solution satisfy everyone.

I would recommend the BIP editorship, once extended or not, to move in its own repository in the future.

Cheers,
Antoine

Antoine's call for procedural norms doesn't recognize that the only precedent is the Editor deciding to step down and appoint a successor. There is no process by which BIP-0002 can be amended to remove Luke, since it can only be modified by the author (Luke) or the editor (Luke). This is described by @JeremyRubin in the log below. This is an attempt at creating a procedure, which can live on even should it choose to re-appoint Luke.

---

jnewbery I'm happy to draft an email to the mailing list, but I'd like to understand the process. What's the process for adding an editor? How does it get decided?
ariard jeremyrubin: on the other point, I don't think bip2 recommend bitcoin-core-dev as a venue, maybe better suitted to #bitcoin or #bitcoin- wizards
luke-jr jnewbery: in the past, it's been the existing editor passes it on, but when I intended to do that in 2018 I found people privately didn't like it, so wider involvement might be better
jeremyrubin well I think it's sort of a weird bind, as luke-jr is the author of 0002 who has the only right to amend it
luke-jr jeremyrubin: BIP 2 doesn't need to be amended for this
jeremyrubin and he's also the editor who judge amendement
jeremyrubin so I think jnewbery is right to ask what the heck the process is
jeremyrubin I would expect https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-editors to be updated
michaelfolkson jeremyrubin: I agree it is a bind but binds aren't solved best overnight
luke-jr IMO what would make sense, is when the timing is reasonable/calm, I can just propose Kalle to the ML and if nobody objects we add him to the README or whatever
luke-jr jeremyrubin: ah, forgot about that
jnewbery it does seem somewhat of a centralization problem. The BIPs repo is a venue for sharing proposed changes to Bitcoin, and one person decides who can update it, and also decides whether or not they should ever be replaced/supplemented?
wumpus yes

---

In this exchange, Luke accuses there being a cabal of developers working against him, and notes that he will revert changes he doesn't like. He also never explains to yanmaani what the collusion is. This exchange is my personal motivation for doing it in this form. I do not believe such a cabal is colluding behind @luke-jr's back. A process that everyone hates but had nothing to do in setting up is better than dealing with a paranoid liar hell bent on bifurcating the bitcoin community.

ariard luke-jr: you know, if you think we should take more time to appoint another bip editor, you're entitled to say so
ariard unless not acting jeopardize users safety, i think we can do better than nagging folks to act quickly during public meetings, either bip editors, maintainers or github orgs admin
luke-jr ariard: aside from timing (which will hopefully be resolved sooner anyway), I think my only concern is that there appears to be some kind of collusion going on between some other devs, and I do not know the extent of who is involved in it
luke-jr ariard: besides, at the end of the day, it's just a git repo of docs - absolute worst case, it can be rolled back or reverted
luke-jr maybe I'm just naive, but a few weeks ago I would never have imagined the behaviour I'm seeing from some people now
yanmaani what is this collusion?

---

Log edited slightly for brevity. With @laanwj @jnewbery @JeremyRubin @ariard @glozow and others.

This makes it clear that there is no defined process for adding editors and that defining one is a difficult and necessary task. Perhaps @jnewbery can weigh in on this approach?

wumpus separately from that we probably need a new BIP editor, and a process for that, but rushing into that after years of no one showing a single interest in being BIP editor is also a bit strange
jnewbery wumpus: kallewoof has shown interest in helping
jeremyrubin wumpus: I've seen others express interest, but lack of clarity around process and not wanting to insult the current editor
jnewbery luke-jr: very good. Maybe having an extra editor would help
luke-jr jnewbery: again, I agree. we should add an editor. I just don't think doing so for this specifically is good timing.
jnewbery I'm not suggesting we do it for this specifically
michaelfolkson jeremyrubin: If there are other possible candidates other than kallewoof it needs a process
meshcollider luke-jr: in the meantime it seems very trivial to go and check the ACKs and then merge it then before proposing the new editor, which would solve the controversial timing issue
jeremyrubin michaelfolkson: are there other candidates?
wumpus meshcollider: right
jeremyrubin ANd I agree it can be discussed on the mailing list
jnewbery I'm still curious what the process is for adding a new BIP editor
jeremyrubin but jnewbery asked a simple question, what's the process
michaelfolkson jeremyrubin: "I've seen others express interest,"
luke-jr meshcollider: but with people trying to politicise it, passing it off as "the activation method" and such, I need to evaluate if the BIP process has any rules/precedent dealing with such things
jeremyrubin which isn't really a process
jeremyrubin I don't think that we need one or two editors, anyone who wants to and is qualified can be added with reasonable support
michaelfolkson jnewbery: The process has not been formalized. If you could draft up a formalized process for the mailing list that would be a productive step
luke-jr meshcollider: (I don't think it does, but I'm not certain.)
jeremyrubin I think 3-5 editors is probably a good amount, odd # preferred
michaelfolkson Next topic....?
ariard i think the best answer we have is we don't have a process to add a new bip editor for now and it's a wider community concern than scope of core dev meeting, so better mailing list
jeremyrubin luke-jr: if you think the optics of adding an editor now are bad, recognize your role in creating the neccessity of it
wumpus clearly there is no process for it at the moment
luke-jr jeremyrubin: that's nonsense.
wumpus like jeremyrubin says we could just add one if there is sufficient support for it
glozow so we are in agreement that jnewbery should draft a proposal for the process and send it to the mailing list?
wumpus then agin I'd prefer if luke-jr agreed
luke-jr glozow: sounds good to me
jeremyrubin I think that -- by your own admission -- you've said there is an appearance that you're holding the BIP hostage
luke-jr if jnewbery is okay with that
jnewbery wumpus: there is certainly sufficient support for it
luke-jr jeremyrubin: stop twisting my words
jeremyrubin That appearance serves to delegitimize the BIP process itself, which is also bad... remove yourself from the situation, just appoint a temporary editor for this BIP
jeremyrubin and then let jnewbery take his time to propose a new process
jeremyrubin this seems to be a natural compromise
wumpus jnewbery: that was fairly clear
wumpus jnewbery: I think you can just propose adding kallewoof as BIP editor on the mailing list and see what the response is
jeremyrubin wumpus: works for me
jnewbery wumpus: who is able to add an editor?
meshcollider Any admin of the Bitcoin org
wumpus if you mean as to github permissions: any admin of the github org
wumpus yes
jeremyrubin so you or sipa?
jnewbery So what would an admin need in order to be satisfied that such support existed?
jnewbery And therefore add a new editor
michaelfolkson Is this PR an emergency? Because I am not aware it is...
wumpus i would prefer if luke-jr agreed to it
jeremyrubin wumpus: by what process would you ignore your preference? it seems unlikely luke-jr would agree
luke-jr jeremyrubin: quit trolling
wumpus but also agree that this is very centralized right now and if he seems to be blocking things, that is not good optics and such either
luke-jr wumpus: I'm not blocking anything. Just doing the same as I have for every other PR for years.
jeremyrubin luke-jr: I don't think it's appropriate for you, the bip editor, to call trying to understand how you've ensconced yourself as editor, trolling.
jnewbery it's not that it's bad optics. It's bad process for the project. And it's a waste of everyone's time

---

General conduct:

luke-jr harding: how about you stop making false accusations and demands for special treatment, and I'll get to it in due time?
luke-jr all you're doing is convincing me you're engaging in bad faith
harding luke-jr: you are clearly stalling, which is negative special treatment and an abuse of your authority. Please address your failing or resign as BIPs editor.
luke-jr harding: liar
harding luke-jr: which part, that you're stalling or that your stalling is an abuse of your authority?
luke-jr as I already told you, I am not stalling.
harding luke-jr: liar.
luke-jr I don't lie.
harding luke-jr: liar.

• queip is stalling
• luke-jr is ignoring harding now

BIP Editors should be easy to work with.

---

Noting that it is not because of speed, but deliberate stalling and dishonesty:

harding michaelfolkson: I don't think anyone is angry about the overall speed of merging (although only once a month merges is slower than I think anyone would like); I think the anger is about the BIPs editor deliberately stalling on merging certain PRs, which indicates a broken process---the BIP editor is supposed to be a pure functionary, not someone with control over BIP content.

---

@luke-jr's comment on merging the BIP-341 changes:

(For the avoidance of doubt: Merging this does not imply anything other than the BIP 2 criteria being met; the community has chosen a different activation method than that described here, and this specification does not change the network rules without community support any more than the BIP 10x sequence did)

and @gmaxwell's response:

What on gods green earth are you talking about? Support for ST has been overwhelming and most in discussions nearly close to unanimous barring a couple people (mostly yourself and folkson) seemingly gaslighting by opposing it with an argument that perplexingly "the community" has already chosen something else.
Even your deceptively stated-- deceptive because it explicitly promoted people to choose your option EVEN IF they preferred this proposal-- twitter poll found your own position in a minority: https://twitter.com/LukeDashjr/status/1384196789184581633 a more neutrally presented twitter poll is almost 4:1 against your proposal:
https://twitter.com/AaronvanW/status/1384205266737004558 discussion on the lists and in the PRs is even more stark.

[jnewbery]

@JaimeCaring I appreciate your efforts here. For a project that prizes decentralization so highly, it's obviously highly undesirable that a critical public forum is effectively under the control of one person.

I'm hopeful that by introducing an additional maintainer (and then maybe another one or two after that - I can think of many people Bitcoin technical contributors who'd do an excellent job) we can improve on that situation.

What you're proposing here is the nuclear option - that we abandon https://github.com/bitcoin/bips and try to build a new focal point for sharing technical proposals. That is of course always an option, but we shouldn't underestimate the costs and disruption of such a move.

[molxyz]

@JaimeCaring Excuse me but who are you? Not trying to doubt who you are but we as bitcoiners have a saying "Don't trust, verify" so I am wondering who you are and why do you want to offer a hand for this opportunity... But anyways, I agree with jnewberry that we don't need a new process for BIP management right now.

[JaimeCaring]

@molxyz Simply someone who cares. Long time Bitcoiner. Saw some of the posts by Greg complaining, dug into it, and realized that no one felt empowered to act. You're right to be sceptical and it is appreciated, but I have no intentions of being involved in this any longer than necessary. I'd happily transfer the repo at the earliest convenience of the Stewards. I'm using an alt because I'm not an idiot and I believe Luke to be somewhat dangerous.

[JaimeCaring]

@jnewbery I do not care about this repo. I do care about the process.

Adding editors (see NACK by @gmaxwell) will do little to fix these problems. There needs to be a defined process for replacement.

After this repo is used to define process it can be merged upstream and Luke can be stripped of his access. I do not think it needs to replace bitcoin/bips permanently. Luke should not be involved in setting the new rules.

I can open a PR to bitcoin/bips with what is contained here.

[JaimeCaring]

@molxyz Amir's responde to someone named James Caring and Caring is not a bitcoin user, he said he's using an alt coin

False.

[molxyz]

I'm using an alt because I'm not an idiot and I believe Luke to be somewhat dangerous.

@JaimeCaring ^^

[JaimeCaring]

How would "altcoin" have any relevance to the question you asked me? It is "alternate account". Clear the record; please do not create misinformation.

[molxyz]

@JaimeCaring Ah.. You didn't say "alternate account" in that post, and "alt" is often used in bitcoin social as a short word for "altcoin" so that was why I thought you said you were using an altcoin. My apology.

[luke-jr]

please do not create misinformation.

Your whole agenda here is based on nothing but misinformation...

[laanwj]

I don't mind innovation in alternative schemes for managing BIPs, I think any scheme that decentralizes while keeping signal/noise ratio approximately the same is an improvement.

That said: I'm trying to reduce my responsibilities with regard to bitcoin, so do not want to be involved myself, please remove me from the list.

[ryanofsky]

I noticed I'm on the list too, and would also prefer to be removed.

It's rough social consensus that @luke-jr is unfit to continue serving in this role.

FWIW, I am not part of this consensus, and want to stand up for Luke while I'm commenting. Luke's been maintaining BIPs for many years and substantially improving them in the process. If he's been too slow to respond at times, or made unwanted and misplaced technical comments at the same time as doing the work of maintaining the BIP repository, those should be reasons for new people to get involved and help speed up the process and for other people to make strong technical rebuttals in the appropriate places that will carry the day. They are not reasons to select entirely new editors.

[promag]

Same here, thanks.

[practicalswift]

If you are on the list of names below, you have been selected as a Steward to the process.

Please remove me from this steward list: I don't want to become a steward (or any other kind of cabin crew member).

Thanks!