Communication has been a challenge on Bitcoin Core for what I can tell the 
entire history of the project. Maintainers merge a pull request and provide no 
commentary on why they’ve merged it. Maintainers leave a pull request with many 
ACKs and few (if any) NACKs for months and provide no commentary on why they 
haven't merged it. I can only speculate on why and it probably depends on the 
individual maintainer. Sometimes it will be poor communication skills, 
sometimes it will be a desire to avoid accountability, sometimes it will be 
fear of unreasonable and spiteful legal action if they mistakenly merge a pull 
request that ends up containing a bug. But search through the pull requests on 
Bitcoin Core and you will rarely see a rationale for a merge decision. The 
difference between say previous maintainers like Wladimir and some of the 
current maintainers is that previous maintainers were extremely responsive on 
IRC. If you disagreed with a merge decision or thought it had been merged 
prematurely they would be happy to discuss it on IRC. In present times at least 
a subset of the current maintainers are not responsive on IRC and will refuse 
to discuss a merge decision. One farcical recent example [0] was the pull 
request to add Vasil Dimov as a maintainer where despite many ACKs from other 
maintainers and other long term contributors two maintainers (fanquake and 
Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 
months for Gloria to comment on the pull request despite many requests from me 
on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC 
meeting to discuss it which they didn’t attend.

A pull request to add a maintainer isn’t a normal pull request. Generally pull 
requests contain a lot more lines of code than a single line adding a trusted 
key. Not merging a pull request for a long period of time can be extremely 
frustrating for a pull request author especially when maintainers and long term 
contributors don’t comment on the pull request and the pull request is stuck in 
“rebase hell”. Clearly it is the lesser evil when compared to merging a harmful 
or bug ridden pull request but poor non-existent communication is not the only 
way to prevent this. Indeed it creates as many problems as it solves.

Another farcical recent(ish) example was the CTV pull request [1] that 
ultimately led to a contentious soft fork activation attempt that was called 
off at the last minute. If you look at the comments on the pull request there 
were 3 individuals (including myself) who NACKed the pull request and I think 
it is fair to say that none of us would be considered long term contributors to 
Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to 
pursue a soft fork activation attempt when it was clear it was contentious [3] 
but if you look at the pull request comments it certainly isn’t clear it was. 
Maintainers and long term contributors (if they commented at all) were gently 
enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A 
long term observer of the Core repo would have known that it wasn’t ready to 
merge or ready to attempt to activate (especially given it was a consensus 
change) but a casual observer would have only seen Concept ACKs and ACKs with 3 
stray NACKs. Many of these casual observers inflated the numbers on the site [4] signalling support for a soft fork activation attempt.

I set out originally to write about the controls and processes around merges on 
the default signet (bitcoin-inquisition [5]) but it quickly became obvious to 
me that if communication around Core merges/non-merges is this weak you can 
hardly expect it to be any better on bitcoin-inquisition/default signet where 
there is no real monetary value at stake. I will probably write about 
bitcoin-inquisition/default signet in a future email as I do think the 
perception that it is “the one and only” staging ground for consensus changes 
is dangerous [6] if the maintainer(s) on that project have the same 
inclinations as a subset of the Core maintainers.

As I stated at the beginning there is an element to this which is not 
individual(s) specific and an adverse reaction to outright malicious actors 
external to any of these projects. I do not think any of the current 
maintainers on Core or bitcoin-inquisition are outright malicious even if a 
subset of them consistently frustrate me with their lack of transparency and 
accountability. But this issue isn't going away and I'm sure we'll hear more on 
this from others in the coming months. To me it is a straight choice of taking 
transparency and accountability much more seriously or failing that investing 
more heavily (time and resources) in consensus compatible forks of Core and 
treating Core like it is a proprietary "open source" project where merge 
decisions are not explained or justified in the open.








Michael Folkson
Email: michaelfolkson at [](
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
bitcoin-dev mailing list

Reply via email to