{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-04-18\n🗒️ 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.\n📝 Original message:yes, the code itself was far less contentious than the weird stab at\nforking the network\n\nthere remains a real chance that bip 119 is the simplest and most flexible\nand reasonably safe covenant tech for many use cases\n\nalthough im partial to 118 as well because lightning is a killer app and it\nmakes batch channels more efficient\n\n\n\nOn Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Communication has been a challenge on Bitcoin Core for what I can tell the\n\u003e entire history of the project. Maintainers merge a pull request and provide\n\u003e no commentary on why they’ve merged it. Maintainers leave a pull request\n\u003e with many ACKs and few (if any) NACKs for months and provide no commentary\n\u003e on why they haven't merged it. I can only speculate on why and it probably\n\u003e depends on the individual maintainer. Sometimes it will be poor\n\u003e communication skills, sometimes it will be a desire to avoid\n\u003e accountability, sometimes it will be fear of unreasonable and spiteful\n\u003e legal action if they mistakenly merge a pull request that ends up\n\u003e containing a bug. But search through the pull requests on Bitcoin Core and\n\u003e you will rarely see a rationale for a merge decision. The difference\n\u003e between say previous maintainers like Wladimir and some of the current\n\u003e maintainers is that previous maintainers were extremely responsive on IRC.\n\u003e If you disagreed with a merge decision or thought it had been merged\n\u003e prematurely they would be happy to discuss it on IRC. In present times at\n\u003e least a subset of the current maintainers are not responsive on IRC and\n\u003e will refuse to discuss a merge decision. One farcical recent example [0]\n\u003e was the pull request to add Vasil Dimov as a maintainer where despite many\n\u003e ACKs from other maintainers and other long term contributors two\n\u003e maintainers (fanquake and Gloria) refused to discuss it on the pull request\n\u003e or on IRC. It took almost 5 months for Gloria to comment on the pull\n\u003e request despite many requests from me on the PR and on IRC. I even\n\u003e requested that they attend the weekly Core Dev IRC meeting to discuss it\n\u003e which they didn’t attend.\n\u003e\n\u003e\n\u003e A pull request to add a maintainer isn’t a normal pull request. Generally\n\u003e pull requests contain a lot more lines of code than a single line adding a\n\u003e trusted key. Not merging a pull request for a long period of time can be\n\u003e extremely frustrating for a pull request author especially when maintainers\n\u003e and long term contributors don’t comment on the pull request and the pull\n\u003e request is stuck in “rebase hell”. Clearly it is the lesser evil when\n\u003e compared to merging a harmful or bug ridden pull request but poor\n\u003e non-existent communication is not the only way to prevent this. Indeed it\n\u003e creates as many problems as it solves.\n\u003e\n\u003e\n\u003e Another farcical recent(ish) example was the CTV pull request [1] that\n\u003e ultimately led to a contentious soft fork activation attempt that was\n\u003e called off at the last minute. If you look at the comments on the pull\n\u003e request there were 3 individuals (including myself) who NACKed the pull\n\u003e request and I think it is fair to say that none of us would be considered\n\u003e long term contributors to Bitcoin Core. I have criticised Jeremy Rubin\n\u003e multiple times for continuing to pursue a soft fork activation attempt when\n\u003e it was clear it was contentious [3] but if you look at the pull request\n\u003e comments it certainly isn’t clear it was. Maintainers and long term\n\u003e contributors (if they commented at all) were gently enthusiastic (Concept\n\u003e ACKing etc) without ACKing that it was ready to merge. A long term observer\n\u003e of the Core repo would have known that it wasn’t ready to merge or ready to\n\u003e attempt to activate (especially given it was a consensus change) but a\n\u003e casual observer would have only seen Concept ACKs and ACKs with 3 stray\n\u003e NACKs. Many of these casual observers inflated the numbers on the\n\u003e utxos.org site [4] signalling support for a soft fork activation attempt.\n\u003e\n\u003e\n\u003e I set out originally to write about the controls and processes around\n\u003e merges on the default signet (bitcoin-inquisition [5]) but it quickly\n\u003e became obvious to me that if communication around Core merges/non-merges is\n\u003e this weak you can hardly expect it to be any better on\n\u003e bitcoin-inquisition/default signet where there is no real monetary value at\n\u003e stake. I will probably write about bitcoin-inquisition/default signet in a\n\u003e future email as I do think the perception that it is “the one and only”\n\u003e staging ground for consensus changes is dangerous [6] if the maintainer(s)\n\u003e on that project have the same inclinations as a subset of the Core\n\u003e maintainers.\n\u003e\n\u003e\n\u003e As I stated at the beginning there is an element to this which is not\n\u003e individual(s) specific and an adverse reaction to outright malicious actors\n\u003e external to any of these projects. I do not think any of the current\n\u003e maintainers on Core or bitcoin-inquisition are outright malicious even if a\n\u003e subset of them consistently frustrate me with their lack of transparency\n\u003e and accountability. But this issue isn't going away and I'm sure we'll\n\u003e hear more on this from others in the coming months. To me it is a straight\n\u003e choice of taking transparency and accountability much more seriously or\n\u003e failing that investing more heavily (time and resources) in consensus\n\u003e compatible forks of Core and treating Core like it is a proprietary \"open\n\u003e source\" project where merge decisions are not explained or justified in the\n\u003e open.\n\u003e\n\u003e\n\u003e [0]: https://github.com/bitcoin/bitcoin/pull/25871\n\u003e\n\u003e [1]: https://github.com/bitcoin/bitcoin/pull/21702\n\u003e\n\u003e [2]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html\n\u003e\n\u003e [3]:\n\u003e https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718\n\u003e\n\u003e [4]: https://utxos.org/signals/\n\u003e\n\u003e [5]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html\n\u003e\n\u003e [6]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html\n\u003e --\n\u003e Michael Folkson\n\u003e Email: michaelfolkson at protonmail.com\n\u003e Keybase: michaelfolkson\n\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/bcbd39a5/attachment-0001.html\u003e"}