rich1.0npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://nostr.ae📅 Original date posted:2023-04-18 🗒️ Summary of this message: Bitcoin Core's communication issues have caused frustration among contributors, with poor communication and lack of rationale for merge decisions. BIP 119 and 118 are potential solutions. 📝 Original message:yes, the code itself was far less contentious than the weird stab at forking the network there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases although im partial to 118 as well because lightning is a killer app and it makes batch channels more efficient On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > 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 > utxos.org 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. > > > [0]: https://github.com/bitcoin/bitcoin/pull/25871 > > [1]: https://github.com/bitcoin/bitcoin/pull/21702 > > [2]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html > > [3]: > https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 > > [4]: https://utxos.org/signals/ > > [5]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html > > [6]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/bcbd39a5/attachment-0001.html>