Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id EE8FEC002A for ; Wed, 19 Apr 2023 20:06:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B660F400EF for ; Wed, 19 Apr 2023 20:06:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B660F400EF X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iOK86ldahLO for ; Wed, 19 Apr 2023 20:06:27 +0000 (UTC) X-Greylist: delayed 04:30:01 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 29209404BF Received: from 4.mo548.mail-out.ovh.net (4.mo548.mail-out.ovh.net [188.165.42.229]) by smtp2.osuosl.org (Postfix) with ESMTPS id 29209404BF for ; Wed, 19 Apr 2023 20:06:27 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.108.20.243]) by mo548.mail-out.ovh.net (Postfix) with ESMTPS id D7DAB20541; Wed, 19 Apr 2023 15:17:03 +0000 (UTC) Received: from peersm.com (37.59.142.103) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 19 Apr 2023 17:17:03 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-103G005f66d372a-1cb3-47b4-8aaa-d4bf91264c87, 10553A8F8EAAD79A4F34D62EC79DDEE74908F878) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.112.229 To: Michael Folkson , Bitcoin Protocol Discussion References: From: Aymeric Vitte Message-ID: <514d39eb-4ebe-b2cf-a976-d1c80c15b422@peersm.com> Date: Wed, 19 Apr 2023 17:17:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8D9DC305332CDD520009B867" X-Originating-IP: [37.59.142.103] X-ClientProxiedBy: DAG8EX1.mxp6.local (172.16.2.71) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: 169329ec-22f6-49d3-9526-4a6577d53196 X-Ovh-Tracer-Id: 427560491800486810 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrfedttddgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepteejgfelfeffgefhtddtfeehvdejfeeuveduuedvfefhjedukeffffekieejvedunecuffhomhgrihhnpehgihhthhhusgdrtghomhdpuhhtgihoshdrohhrghdplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphhrohhtohhnmhgrihhlrdgtohhmpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdefpdelvddrudekgedrudduvddrvddvleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpmhhitghhrggvlhhfohhlkhhsohhnsehprhhothhonhhmrghilhdrtghomhdpoffvte fjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht X-Mailman-Approved-At: Wed, 19 Apr 2023 20:08:46 +0000 Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2023 20:06:30 -0000 --------------8D9DC305332CDD520009B867 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable The different emails are overlong, it's difficult to follow It is super surprising to see that Bitcoin has only 4 maintainers funded by Brink and Blockstream, but I think the decisions are taken elsewhere And I think the job of the maintainers is not only to be maintainers but to do the PR sometimes, since the process is too complicate and they are supposed to know well the code And it seems like bitcoin is betting its future on lightning and/or super clever (non understandble) changes to bitcoin scripting While some simple changes can allow bitcoin to surpass ethereum, as usual, like "Allow several OP_RETURN in one tx and no limited size" https://github.com/bitcoin/bitcoin/issues/27043 How long it will take remains mysterious Le 18/04/2023 =E0 14:40, Michael Folkson via bitcoin-dev a =E9crit : > > 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=92ve 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=92t attend. > > > A pull request to add a maintainer isn=92t 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=92t comment > on the pull request and the pull request is stuck in =93rebase hell=94.= > 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 solv= es. > > > 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=92t 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=92t 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 =93the one and only=94 staging ground for consens= us > changes is dangerous [6] if the maintainer(s) on that project have the > same inclinations as a subset of the Core maintainers.=20 > > > 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/0203= 86.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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=20 Sophia-Antipolis, France CV: https://www.peersm.com/CVAV.pdf LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 GitHub : https://www.github.com/Ayms A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ay= ms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b= eed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac= tions torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor Anti-spies and private torrents, dynamic blocklist: http://torrent-live.p= eersm.com Peersm : http://www.peersm.com --------------8D9DC305332CDD520009B867 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit The different emails are overlong, it's difficult to follow

It is super surprising to see that Bitcoin has only 4 maintainers funded by Brink and Blockstream, but I think the decisions are taken elsewhere

And I think the job of the maintainers is not only to be maintainers but to do the PR sometimes, since the process is too complicate and they are supposed to know well the code

And it seems like bitcoin is betting its future on lightning and/or super clever (non understandble) changes to bitcoin scripting

While some simple changes can allow bitcoin to surpass ethereum, as usual, like "Allow several OP_RETURN in one tx and no limited size" https://github.com/bitcoin/bitcoin/issues/27043

How long it will take remains mysterious


Le 18/04/2023 à 14:40, Michael Folkson via bitcoin-dev a écrit :

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
--------------8D9DC305332CDD520009B867--