Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 244C8C002A for ; Wed, 19 Apr 2023 00:57:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ED05B83F25 for ; Wed, 19 Apr 2023 00:57:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ED05B83F25 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=Hl/6OYqr X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDJ4omsBbLG2 for ; Wed, 19 Apr 2023 00:57:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5E8E883F18 Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5E8E883F18 for ; Wed, 19 Apr 2023 00:57:01 +0000 (UTC) Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-54fa1deb61dso4398777b3.1 for ; Tue, 18 Apr 2023 17:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20221208.gappssmtp.com; s=20221208; t=1681865820; x=1684457820; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/W66dQUi6Wx5zfcZAUoyQUT0XihjTEMNHuJQIIq52O8=; b=Hl/6OYqrAMG3yfCWe4RvCkKPoIWMlWm/TAppkLT/0seukopg0ZzSErTxtxHKh2uopK 41ZfaZNlnHb9Oyw4AOnJ/iY2CUHZzPlqzcQBEPPVfZZbavjKMDihH105GWKz5838gZCt zWmK5o/jja/ZjkgHHZmafsWHnQe9Um1J4ikTBEMMyLSj7LSWmKXVHRb/ZBgUNI35F+qJ A3R/8f9apSXfCxPji8bAko8D4GUN5+65hnyilAh3d/Cb98O6o6016t1DwsS7jVUYLN/w d+/zQeOuUZgqo7xjD21USpoT35MLZTpSzbWwOpaDbXp4LBSWDvYSyegvTvilLl/cckRJ pdxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681865820; x=1684457820; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/W66dQUi6Wx5zfcZAUoyQUT0XihjTEMNHuJQIIq52O8=; b=h8JBEymJiEfq+x74myNUBS3Xm/vsYBGPKEYnPBBf8KfZZjNimvADgzUwFTEQC0L4/v Zwif9Nd/qoZs/X/tqduFiW0Tjmm23vtF9G7kaSUmsiu22IsjNOSRYr6qAY/tTQgfR/CD LpK2yLxoUQ5g3iKzpIW61Fumc6XAx8MIFbbmmhXE3tQOyVE/ZYbBbEBpLDb5aJ1vbSiL 3tXO2M5qw1YOzdiXdTT8jOpK+y8kRVOWv6VXSH8eN3gJ3QQbBrsQn8TQz99I6UJ6d3w1 haRBlw05iTgb4wvWqB4FKNFkUPk7Q+6BMka3iXfwGu4sP2Fw5aJ7dqjZ8yS2VuNOemPj J+6g== X-Gm-Message-State: AAQBX9e5iWJLojDN5GRlcORAi0kZ9QUMGK9nWH8LMbsEMMO/Eyobgzmi iLjO30AGygTsV4p1ROmrCwRnYfWuS5vM8mXZlw6OWeExC8vg X-Google-Smtp-Source: AKy350ar43g/9lhOWoSgwHdrPF+XHu/eJ61DohGNbbgId7ClQX+tbiO6O0JJ0tyMVFNUnx7VbiH4dc+2ESIt2YXrG1E= X-Received: by 2002:a81:f88:0:b0:54f:b503:6e69 with SMTP id 130-20020a810f88000000b0054fb5036e69mr14585753ywp.5.1681865819912; Tue, 18 Apr 2023 17:56:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Tue, 18 Apr 2023 20:56:48 -0400 Message-ID: To: Michael Folkson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c182ea05f9a5e67d" X-Mailman-Approved-At: Wed, 19 Apr 2023 08:12:28 +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 00:57:03 -0000 --000000000000c182ea05f9a5e67d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@lists.linuxfoundation.org> wrote: > Communication has been a challenge on Bitcoin Core for what I can tell th= e > entire history of the project. Maintainers merge a pull request and provi= de > no commentary on why they=E2=80=99ve merged it. Maintainers leave a pull = request > with many ACKs and few (if any) NACKs for months and provide no commentar= y > on why they haven't merged it. I can only speculate on why and it probabl= y > 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 an= d > 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 man= y > ACKs from other maintainers and other long term contributors two > maintainers (fanquake and Gloria) refused to discuss it on the pull reque= st > 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=E2=80=99t attend. > > > A pull request to add a maintainer isn=E2=80=99t a normal pull request. G= enerally > 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 maintaine= rs > and long term contributors don=E2=80=99t comment on the pull request and = the pull > request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clearly it is the less= er 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 wh= en > it was clear it was contentious [3] but if you look at the pull request > comments it certainly isn=E2=80=99t clear it was. Maintainers and long te= rm > contributors (if they commented at all) were gently enthusiastic (Concept > ACKing etc) without ACKing that it was ready to merge. A long term observ= er > of the Core repo would have known that it wasn=E2=80=99t ready to merge o= r 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 =E2=80=9Cthe one and= only=E2=80=9D > 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 acto= rs > 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 straigh= t > 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 t= he > 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/02= 0921.html > > [6]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/02= 0948.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 > --000000000000c182ea05f9a5e67d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes, the code itself was far less contentious than the we= ird stab at=C2=A0 forking the network=C2=A0

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 we= ll because lightning is a killer app and it makes batch channels more effic= ient


On Tue, A= pr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> 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 a= nd provide no commentary on why they=E2=80=99ve merged it. Maintainers leav= e a pull request with many ACKs and few (if any) NACKs for months and provi= de 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 wil= l be poor communication skills, sometimes it will be a desire to avoid acco= untability, sometimes it will be fear of unreasonable and spiteful legal ac= tion 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 s= ee a rationale for a merge decision. The difference between say previous ma= intainers like Wladimir and some of the current maintainers is that previou= s maintainers were extremely responsive on IRC. If you disagreed with a mer= ge decision or thought it had been merged prematurely they would be happy t= o discuss it on IRC. In present times at least a subset of the current main= tainers are not responsive on IRC and will refuse to discuss a merge decisi= on. 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 l= ong term contributors two maintainers (fanquake and Gloria) refused to disc= uss 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=E2=80=99t attend.


A pull request to add a maintainer isn=E2=80=99t a normal pull re= quest. Generally pull requests contain a lot more lines of code than a sing= le 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 w= hen maintainers and long term contributors don=E2=80=99t comment on the pul= l request and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. C= learly it is the lesser evil when compared to merging a harmful or bug ridd= en 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 C= TV pull request [1] that ultimately led to a contentious soft fork activati= on attempt that was called off at the last minute. If you look at the comme= nts on the pull request there were 3 individuals (including myself) who NAC= Ked 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 Jerem= y Rubin multiple times for continuing to pursue a soft fork activation atte= mpt when it was clear it was contentious [3] but if you look at the pull re= quest comments it certainly isn=E2=80=99t clear it was. Maintainers and lon= g term contributors (if they commented at all) were gently enthusiastic (Co= ncept ACKing etc) without ACKing that it was ready to merge. A long term ob= server of the Core repo would have known that it wasn=E2=80=99t ready to me= rge or ready to attempt to activate (especially given it was a consensus ch= ange) 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-inquis= ition [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 bet= ter on bitcoin-inquisition/default signet where there is no real monetary v= alue at stake. I will probably write about bitcoin-inquisition/default sign= et in a future email as I do think the perception that it is =E2=80=9Cthe o= ne and only=E2=80=9D 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.=C2=A0


As I stated at the = beginning there is an element to this which is not individual(s) specific a= nd an adverse reaction to outright malicious actors external to any of thes= e projects. I do not think any of the current maintainers on Core or bitcoi= n-inquisition are outright malicious even if a subset of them consistently = frustrate me with their lack of transparency and accountability.=C2= =A0But 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.


<= p style=3D"margin:0px;font:12px Helvetica">[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/s= ignals/

[5]: https://lists.linuxfoundation= .org/pipermail/bitcoin-dev/2022-September/020921.html

[6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20= 22-September/020948.html

--
Michael FolksonEmail: michaelfolkson at protonmail.c= om
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 = 214C FEE3
=20
=20
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000c182ea05f9a5e67d--