Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-18 🗒️ Summary of this message: Bitcoin Core's ...
đź“… 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>;
🗒️ 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>;