MIME-Version: 1.0
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
In-Reply-To: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 18 Apr 2023 20:56:48 -0400
Message-ID: <CAJowKgLU1OiMsDWn5A894=+szQKrQrr6HcwUU8bhXwDwSHN83w@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c182ea05f9a5e67d"
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
Precedence: list

--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

<div dir=3D"auto">yes, the code itself was far less contentious than the we=
ird stab at=C2=A0 forking the network=C2=A0<div dir=3D"auto"><br></div><div=
 dir=3D"auto">there remains a real chance that bip 119 is the simplest and =
most flexible and reasonably safe covenant tech for many use cases</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">although im partial to 118 as we=
ll because lightning is a killer app and it makes batch channels more effic=
ient</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, A=
pr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"font=
-family:Arial,sans-serif;font-size:14px"><p style=3D"margin:0px;font:12px H=
elvetica">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&#39;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.</p><p style=3D"margin:0px;font=
:12px Helvetica;min-height:14px"><br></p><p style=3D"margin:0px;font:12px H=
elvetica">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.</p><p style=
=3D"margin:0px;font:12px Helvetica;min-height:14px"><br></p><p style=3D"mar=
gin:0px;font:12px Helvetica">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 =
<a href=3D"http://utxos.org" target=3D"_blank" rel=3D"noreferrer">utxos.org=
</a> site [4] signalling support for a soft fork activation attempt.</p><p =
style=3D"margin:0px;font:12px Helvetica;min-height:14px"><br></p><p style=
=3D"margin:0px;font:12px Helvetica">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</p><p style=3D"margin:0px;font:12px Helveti=
ca"><br></p><p style=3D"margin:0px;font:12px Helvetica">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.<span>=C2=
=A0But this issue isn&#39;t going away and I&#39;m sure we&#39;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 &quot;open source&quot; =
project where merge decisions are not explained or justified in the open.</=
span></p><p style=3D"margin:0px;font:12px Helvetica"><span><br></span></p><=
p style=3D"margin:0px;font:12px Helvetica">[0]: <a href=3D"https://github.c=
om/bitcoin/bitcoin/pull/25871" target=3D"_blank" rel=3D"noreferrer">https:/=
/github.com/bitcoin/bitcoin/pull/25871</a></p><p style=3D"margin:0px;font:1=
2px Helvetica">[1]: <a href=3D"https://github.com/bitcoin/bitcoin/pull/2170=
2" target=3D"_blank" rel=3D"noreferrer">https://github.com/bitcoin/bitcoin/=
pull/21702</a></p><p style=3D"margin:0px;font:12px Helvetica">[2]: <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/0203=
86.html" target=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-April/020386.html</a></p><p style=3D"margin=
:0px;font:12px Helvetica">[3]: <a href=3D"https://gist.github.com/michaelfo=
lkson/352a503f4f9fc5de89af528d86a1b718" target=3D"_blank" rel=3D"noreferrer=
">https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718</=
a></p><p style=3D"margin:0px;font:12px Helvetica">[4]: <a href=3D"https://u=
txos.org/signals/" target=3D"_blank" rel=3D"noreferrer">https://utxos.org/s=
ignals/</a></p><p style=3D"margin:0px;font:12px Helvetica">[5]: <a href=3D"=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0209=
21.html" target=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-September/020921.html</a></p><p style=3D"ma=
rgin:0px;font:12px Helvetica">[6]: <a href=3D"https://lists.linuxfoundation=
.org/pipermail/bitcoin-dev/2022-September/020948.html" target=3D"_blank" re=
l=3D"noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
22-September/020948.html</a></p></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:&#39;SFMono-Regular&#39;,Consolas,&#39;Liberation Mono&#39;,Menlo,=
monospace,monospace"><span style=3D"font-size:14px">--<br>Michael Folkson<b=
r>Email: michaelfolkson at </span></span></span><a href=3D"http://protonmai=
l.com/" style=3D"line-height:normal;text-decoration:underline;font-family:&=
#39;SFMono-Regular&#39;,Consolas,&#39;Liberation Mono&#39;,Menlo,monospace,=
monospace;font-size:14px;font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing=
:0px" rel=3D"noopener noreferrer noreferrer" target=3D"_blank">protonmail.c=
om</a><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;=
letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-w=
rap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:i=
nline"><span style=3D"font-family:&#39;SFMono-Regular&#39;,Consolas,&#39;Li=
beration Mono&#39;,Menlo,monospace,monospace"><span style=3D"font-size:14px=
"> </span></span></span><br></div><div style=3D"font-family:arial;font-size=
:14px"><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400=
;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-=
wrap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:=
inline"><span style=3D"font-family:&#39;SFMono-Regular&#39;,Consolas,&#39;L=
iberation Mono&#39;,Menlo,monospace,monospace"><span style=3D"font-size:14p=
x">Keybase: michaelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 =
214C FEE3</span></span></span><br></div>
    </div>
   =20
            <div>
       =20
            </div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c182ea05f9a5e67d--