path: root/71/4d59545502b12dc28951c060a1129937b6756d

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DF7A1C000C;
 Mon, 21 Jun 2021 15:06:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CDCF240322;
 Mon, 21 Jun 2021 15:06:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9puKupso8wrl; Mon, 21 Jun 2021 15:06:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [IPv6:2a00:1450:4864:20::334])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 806414040A;
 Mon, 21 Jun 2021 15:06:11 +0000 (UTC)
Received: by mail-wm1-x334.google.com with SMTP id
 l18-20020a1ced120000b029014c1adff1edso14125106wmh.4; 
 Mon, 21 Jun 2021 08:06:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=bRbeQW74uM2s77QYzOm5crJI6xtSsRMH6Cp2hT5ZlEw=;
 b=oM8axCx3H0BP3dFUqnsTgM6V7bAYY+PZN+5qUaV8ypr+K6zt+Ngjswhe/QIGJiR7jy
 zThlSyv7nYsYlIMQOILbQ9oQSGAR/t02IDaDM2db6abXbC680QuoVQ0UJ+C5kwyoyfUC
 A0GX+vWFbFWtDWzDIQdN5fgkxgKPozD2Rb6JQk6lcF1nnvOSnQDgWR69HCheS955sg5y
 GB1Sl7CHsZC+cknM1aP7UpANHcuWWbIGAenvSPw/VAz39HNfSapL3AknI4B5r3xxZbcX
 B7Fi80K1BPMfNUBDXmvEsgcmx8iRdqtOjuvEJFYtwxK4gejt1Yz0HzswJWcE+TkPQ4sJ
 p3+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=bRbeQW74uM2s77QYzOm5crJI6xtSsRMH6Cp2hT5ZlEw=;
 b=gHz103G41/+vodDr9PO2QWo8dPoBcnYxMHEt0Gf+OoxDCTlzztl8Hpf3ZdKdhSRRgn
 xfwT5eomYN364laCdjOqWXboJHLR2wlnnw9ziFx71Ot0HVneL+nAgrxFFJp4l5Dn6BE9
 aNI3HRYynXZ9eLL2AsdmKEarG7dKv7Gr1lmXXLm6qSmTX6eAbaJyC9zwSHmf4eNe0Y/H
 ecRxifZpvJhVEKS/f55ujokJ91bOUFosWeL9Jeo7vbLV9ZO11v3LOXRJCZsboGqOw64r
 YcSvc9zng3eCeoZ3NcpJxEKYOObv944MRgYF84aGqId9Gx0hPEh1d9t/vxvcCb6Ns0gf
 RD+A==
X-Gm-Message-State: AOAM530zTp21brej6kSn1ADLkz5mpzHHGafQFtfWKnfKTWs1jiAFwAbM
 xr1Z0dyovHqMjygzoopTO8iN4udMZJbSGS0vFBYWVh3sbvU=
X-Google-Smtp-Source: ABdhPJzfeANj93kn9QXFDDxVUyFZPkRqrWMp5Qpil3A5XcBwknx2Ha3HNlUlWYAhogy/db5gY3x21CZik7rTYdJNzQg=
X-Received: by 2002:a1c:4c5:: with SMTP id 188mr14482905wme.1.1624287969051;
 Mon, 21 Jun 2021 08:06:09 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 21 Jun 2021 11:05:57 -0400
Message-ID: <CALZpt+H7fbocEm0uuCo=Xm7OEq0uT-A0D3R0GfEA1TwphM0iYw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>, dlc-dev@mailmanlists.org
Content-Type: multipart/alternative; boundary="00000000000068858c05c54803b9"
X-Mailman-Approved-At: Mon, 21 Jun 2021 15:37:06 +0000
Subject: [bitcoin-dev] On the recent softforks survey,
	forget to fulfill my answer!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 15:06:15 -0000

--00000000000068858c05c54803b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I was super glad to see the recent survey on potential softforks for the
near-future of Bitcoin! I didn't have time to answer this one but will do
so for the future. I wanna to salute the grassroots involvement in bitcoin
protocol development, that's cool to see :)

Though softforks are what shine in the media and social networks, one
should not ignore they represent the aggregation of thousands of hours of
sweat from contributors all across the ecosystem with discussion extending
from IRC public or private chans, mailing list, medias, etc.

What makes softfork discussion especially hard is that no one is following
all those communications channels to collect the trace of information and
as such it can be hard to reason on the Big Picture(tm). That's why
soft-forks take time, and we might somehow be prepared for them to take
even more time in the future...

That said, where I would like to draw awareness of the community is about
the submerged part of bitcoin protocol development iceberg. Softforks are
sexy, though you have far more areas of Bitcoin dev who would benefit from
a gentle boost by happy hands :p

For e.g, if you take Bitcoin Core, you have few ongoing projects were folks
have a hard time moving forward, e.g assumeutxo/mempool
refactos/addr-relay/rebroadcasting module/mutation testing/
multiprocess/wallet external signer/GUI maintenance/libbitcoin_kernel[0]

Those projects start to be "softfork"-in-itself-size-of-engineering, and
for a lot of them might  require more than pure "coding" skills, such as
specification, simulations, extensive code coverage, up-to-date meeting
documents. See what is currently done with the Core wiki [1]

All those projects are modifying critical areas of Bitcoin such as the
validation engine or the p2p stack and AFAICT, they deserve more care.
Hopefully, by drawing the light there, more folks are going to understand
them, we'll have more skilled reviewers, reducing the reliance on a few
segments of the codebase being only understood by some seen experts and
ideally, ingenious, "Many Eyes Make All Bugs Shallow" :)

That said, it's only the technical ground and I believe the human layer of
Bitcoin dev might be the one where grassroots-involvement might be the most
fruitful.

I would say the Bitcoin dev stage has changed a bit since the last 18
months, especially w.r.t to few factors, the arrival of massive development
funding, the sudden mediatisation of protocol developers and the pursued
geographical spreading, diversification and education of the poolset of
contributors.

When I did arrive on the stage a few years ago, funding was still a hard
question, even for well-known, long-term contributors and only a few actors
were taking care of Bitcoin. Really differently, from what we have seen on
the last months, where we have seen a plethora of new organisations
entering the game and benefiting from the generosity of the Bitcoin
industry [2]

Things have been so fast that sometimes one can wonder if there isn't a
bubble around Bitcoin dev ? Few OGs might suggest we're back to 2017, with
ICO-like webpage pinning "developers-as-brands".  In reality, we see new
grant announcements every month or week, but still the number of reviewers
on Core doesn't seem to increase ? [3]

Hopefully, a lot of those new structures pretending to work for Bitcoin
betterness will get out of their childerness phase and slowly mature to
something as sound as Chaincode or Square Crypto. Small, friendly,
politics-free engineering teams with years-long stability, solving bitcoin
problems with a "forever" perspective mindset.

Though, as of today, you do have the opposite with the grant model. Being
funded on the rational that yours peers "appreciate" your work is more
going to generate implicit compliance at review time where you should
instead spot their errors. Bitcoin development process is highly contrarian
per nature, and constantly challenging your peers assumptions has been
preserving software robustness.

Time will separate the wheat from the chaff though how to make things
better in the short term ? I don't know, maybe those structures could be
exemplary and outsource their grant allocation decisions framework ? Or ask
them to publish grant contract under which contributors are engaging
themselves to observe if the usual independence provisions are present [4]

In another direction, I believe the ongoing mediatization increase of the
Bitcoin dev stage in the last months or so didn't improve the current state
of affairs. We now see technical proposals, of which the soundness have not
been thoroughly discussed in the traditional venues, being announced in big
pump as some kind of "done-deal", potentially sustaining the false belief
it has been already blessed or approved by the rest of the development
community.

And honestly, it's quite easy to approach any Bitcoin media today once
you're a bit technical, and rely on lingo to create a perception of
competency towards your interlocutors. In fact, your talking isn't going to
be debunked by your peers as most of the time they have other,
on-the-ground, engineering issues to care about. Or say differently, if
you're a Bitcoin journalist today, it's quite easy for smart ass like me to
hijack your production :p

Don't trust, verify :)

Another bottleneck in Bitcoin development is the ongoing spreading of
contributors around many geographical areas and timezones, making
intra-communication far harder. Lightning dev or Bitcoin Core technical
meetings might happen at the end of your local day but another attendee
might just get started, and with time you feel how divergence in level of
energies influences the serendipity of engineering discussions.

Communication might not flow smoothly through all the development
stakeholders and how do we make communications more distributed and
fault-tolerance without losing on the quality ? I don't have the
answers...Yes, the Earth isn't flat and that's an issue for Bitcoin dev :/

The ongoing increase in developer diversity is also something to salute.
Anyone is invited to contribute without regards to technical experience,
race, "expertise", OSS experience, age, gender, language or any other
social concern. I believe diversity is a force for Bitcoin development and
I would like to congrat my fellow female Bitcoin hackers of which the
continuous hard work and smartness should inspire more women to follow
their tracks in the coming years. Pioneering has always been hard :/

Another remaining issue is developer education. The development of
cryptocurrencies demands a high-level of rigor, adversarial thinking,
thorough testing and risk-minimization development strategy. Any bug may
cost users real money and disrupt folks' lives. We still have a lot to
learn from the Old Guard, which sadely are less and less active on the
daily ground and I would say the ecosystem infrastructure would be far more
sane with more security-oriented folks.

As a young developer, even armed with the best intentions it takes years to
adopt a security-first mindset and continuously extend and mature your
technical stack. One has to become fluent through a wide variety of areas
to be an efficient contributor, distributed systems, internet protocol,
applied cryptography, database, game theory, professional english,
quality-assurance best practices, the list is never ending and there is
always a nice chunk of knowledge to go after :)

Lastly, another uncomfortable issue to talk about is direct pressure
exercised on the developers themselves to bend their works, as the ongoing
CSW case sadly recalls. Flavors of those concerns  have been mentioned a
lot through Bitcoin archives [5].

So far, I've never heard about angry calls passed backstage to Bitcoin
contributors, deliberately made to influence the expression of their public
technical opinions. Though in the future, if that kind  of thorny situation
happens to you as a Bitcoin FOSS contributor, remember that you're always
free to discuss discretely about potential conflict of interests you
observe with folks of confidence around you. Or if you prefer to keep the
anonymity, reach out to some investigative journalists under a cover
identity.

Here is, I think that's all the area where I would be glad to see more
grassroot-engagement or even any coming from the industry with eager
motivation to help on those fronts.

Ask not what Bitcoin can do for you - ask what you can do for Bitcoin :)

Cheers,
Antoine

PS: oh, and SIGHAsH_PURPLE for the win :p

[0] That's a joke on mutation testing, it's a trillion-dollar codebase, but
we don't do
mutation testing. Sad :/

[1] See https://github.com/bitcoin-core/bitcoin-devwiki/wiki

[2] Disclaimer: I'm not open to outbound sponsorship proposals.

[3] As backed by data here :
https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-retro/

[4] For e.g, a lot of grant legal frameworks don't have clauses
guaranteeing the independence of the
general Bitcoin Core or Lightning development, just a smaller subset around
validity of block rules,
inspired from the BitMex open one. Clearly a hole if you ask any competent
lawyer...

[5] Flavors of those concerns have been mentioned a lot through Bitcoin
archives:

See "Bitcoin in 2021":
https://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021

" After all, if you can replace all the people who would=E2=80=99ve objecte=
d to
what you want to do, there=E2=80=99s
no need to sneak it in and hope no one notices in review, you can just do
it, and even if you don=E2=80=99t
getrid of everyone who would object you at least lower the chances that
your patch will get a thorough
review by whoever remains. There are a variety of ways you can do that. One
is finding way of making
contributing unpleasant enough that your targets just leave on their own:
constant arguments about
hings that don=E2=80=99t really matter, slowing down progress so it feels l=
ike
you=E2=80=99re just wasting time,
and personal attacks in the media (or on social media), for instance.
Another is the cancel-culture
approach of trying to make them a pariah so no one else will have anything
to do with them."

Or see "Working on social contracts (was: Paper currency)" :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-May/005851.htm=
l

"I promise that if bad people show up with a sufficient pointy gun that
I'll do whatever they tell me to do. I'll make bad proposals, submit
backdoors, and argue with querulous folks on mailing lists, diverting
them from real development and review work, all as commanded. Maybe
I'll try to sneak out a warning of some kind, maybe... but with my
life or my families or friends lives on the line=E2=80=94 probably not.

... and I think that anyone who tells you otherwise probably just
hasn't really thought it through.  So what is the point of commitments
like that?  People change, people go crazy, people are coerced. Crap
happens, justifications are made, life goes on=E2=80=94 or so we hope."

--00000000000068858c05c54803b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>I was super glad to see the recent survey on po=
tential softforks for the near-future of Bitcoin! I didn&#39;t have time to=
 answer this one but will do so for the future. I wanna to salute the grass=
roots involvement in bitcoin protocol development, that&#39;s cool to see :=
)<br><br>Though softforks are what shine in the media and social networks, =
one should not ignore they represent the aggregation of thousands of hours =
of sweat from contributors all across the ecosystem with discussion extendi=
ng from IRC public or private chans, mailing list, medias, etc.<br><br>What=
 makes softfork discussion especially hard is that no one is following all =
those communications channels to collect the trace of information and as su=
ch it can be hard to reason on the Big Picture(tm). That&#39;s why soft-for=
ks take time, and we might somehow be prepared for them to take even more t=
ime in the future...<br><br>That said, where I would like to draw awareness=
 of the community is about the submerged part of bitcoin protocol developme=
nt iceberg. Softforks are sexy, though you have far more areas of Bitcoin d=
ev who would benefit from a gentle boost by happy hands :p<br><br>For e.g, =
if you take Bitcoin Core, you have few ongoing projects were folks have a h=
ard time moving forward, e.g assumeutxo/mempool refactos/addr-relay/rebroad=
casting module/mutation testing/ multiprocess/wallet external signer/GUI ma=
intenance/libbitcoin_kernel[0]<br><br>Those projects start to be &quot;soft=
fork&quot;-in-itself-size-of-engineering, and for a lot of them might=C2=A0=
 require more than pure &quot;coding&quot; skills, such as specification, s=
imulations, extensive code coverage, up-to-date meeting documents. See what=
 is currently done with the Core wiki [1]<br><br>All those projects are mod=
ifying critical areas of Bitcoin such as the validation engine or the p2p s=
tack and AFAICT, they deserve more care. Hopefully, by drawing the light th=
ere, more folks are going to understand them, we&#39;ll have more skilled r=
eviewers, reducing the reliance on a few segments of the codebase being onl=
y understood by some seen experts and ideally, ingenious, &quot;Many Eyes M=
ake All Bugs Shallow&quot; :)<br><br>That said, it&#39;s only the technical=
 ground and I believe the human layer of Bitcoin dev might be the one where=
 grassroots-involvement might be the most fruitful.<br><br>I would say the =
Bitcoin dev stage has changed a bit since the last 18 months, especially w.=
r.t to few factors, the arrival of massive development funding, the sudden =
mediatisation of protocol developers and the pursued geographical spreading=
, diversification and education of the poolset of contributors.<br><br>When=
 I did arrive on the stage a few years ago, funding was still a hard questi=
on, even for well-known, long-term contributors and only a few actors were =
taking care of Bitcoin. Really differently, from what we have seen on the l=
ast months, where we have seen a plethora of new organisations entering the=
 game and benefiting from the generosity of the Bitcoin industry [2]<br><br=
>Things have been so fast that sometimes one can wonder if there isn&#39;t =
a bubble around Bitcoin dev ? Few OGs might suggest we&#39;re back to 2017,=
 with ICO-like webpage pinning &quot;developers-as-brands&quot;.=C2=A0 In r=
eality, we see new grant announcements every month or week, but still the n=
umber of reviewers on Core doesn&#39;t seem to increase ? [3]<br><br>Hopefu=
lly, a lot of those new structures pretending to work for Bitcoin betternes=
s will get out of their childerness phase and slowly mature to something as=
 sound as Chaincode or Square Crypto. Small, friendly, politics-free engine=
ering teams with years-long stability, solving bitcoin problems with a &quo=
t;forever&quot; perspective mindset.<br><br>Though, as of today, you do hav=
e the opposite with the grant model. Being funded on the rational that your=
s peers &quot;appreciate&quot; your work is more going to generate implicit=
 compliance at review time where you should instead spot their errors. Bitc=
oin development process is highly contrarian per nature, and constantly cha=
llenging your peers assumptions has been preserving software robustness.<br=
><br>Time will separate the wheat from the chaff though how to make things =
better in the short term ? I don&#39;t know, maybe those structures could b=
e exemplary and outsource their grant allocation decisions framework ? Or a=
sk them to publish grant contract under which contributors are engaging the=
mselves to observe if the usual independence provisions are present [4]<br>=
<br>In another direction, I believe the ongoing mediatization increase of t=
he Bitcoin dev stage in the last months or so didn&#39;t improve the curren=
t state of affairs. We now see technical proposals, of which the soundness =
have not been thoroughly discussed in the traditional venues, being announc=
ed in big pump as some kind of &quot;done-deal&quot;, potentially sustainin=
g the false belief it has been already blessed or approved by the rest of t=
he development community.<br><br>And honestly, it&#39;s quite easy to appro=
ach any Bitcoin media today once you&#39;re a bit technical, and rely on li=
ngo to create a perception of competency towards your interlocutors. In fac=
t, your talking isn&#39;t going to be debunked by your peers as most of the=
 time they have other, on-the-ground, engineering issues to care about. Or =
say differently, if you&#39;re a Bitcoin journalist today, it&#39;s quite e=
asy for smart ass like me to hijack your production :p<br><br>Don&#39;t tru=
st, verify :)<br><br>Another bottleneck in Bitcoin development is the ongoi=
ng spreading of contributors around many geographical areas and timezones, =
making intra-communication far harder. Lightning dev or Bitcoin Core techni=
cal meetings might happen at the end of your local day but another attendee=
 might just get started, and with time you feel how divergence in level of =
energies influences the serendipity of engineering discussions.<br><br>Comm=
unication might not flow smoothly through all the development stakeholders =
and how do we make communications more distributed and fault-tolerance with=
out losing on the quality ? I don&#39;t have the answers...Yes, the Earth i=
sn&#39;t flat and that&#39;s an issue for Bitcoin dev :/<br><br>The ongoing=
 increase in developer diversity is also something to salute. Anyone is inv=
ited to contribute without regards to technical experience, race, &quot;exp=
ertise&quot;, OSS experience, age, gender, language or any other social con=
cern. I believe diversity is a force for Bitcoin development and I would li=
ke to congrat my fellow female Bitcoin hackers of which the continuous hard=
 work and smartness should inspire more women to follow their tracks in the=
 coming years. Pioneering has always been hard :/<br><br>Another remaining =
issue is developer education. The development of cryptocurrencies demands a=
 high-level of rigor, adversarial thinking, thorough testing and risk-minim=
ization development strategy. Any bug may cost users real money and disrupt=
 folks&#39; lives. We still have a lot to learn from the Old Guard, which s=
adely are less and less active on the daily ground and I would say the ecos=
ystem infrastructure would be far more sane with more security-oriented fol=
ks.<br><br>As a young developer, even armed with the best intentions it tak=
es years to adopt a security-first mindset and continuously extend and matu=
re your technical stack. One has to become fluent through a wide variety of=
 areas to be an efficient contributor, distributed systems, internet protoc=
ol, applied cryptography, database, game theory, professional english, qual=
ity-assurance best practices, the list is never ending and there is always =
a nice chunk of knowledge to go after :)<br><br>Lastly, another uncomfortab=
le issue to talk about is direct pressure exercised on the developers thems=
elves to bend their works, as the ongoing CSW case sadly recalls. Flavors o=
f those concerns=C2=A0 have been mentioned a lot through Bitcoin archives [=
5].<br><br>So far, I&#39;ve never heard about angry calls passed backstage =
to Bitcoin contributors, deliberately made to influence the expression of t=
heir public technical opinions. Though in the future, if that kind=C2=A0 of=
 thorny situation happens to you as a Bitcoin FOSS contributor, remember th=
at you&#39;re always free to discuss discretely about potential conflict of=
 interests you observe with folks of confidence around you. Or if you prefe=
r to keep the anonymity, reach out to some investigative journalists under =
a cover identity.<br><br>Here is, I think that&#39;s all the area where I w=
ould be glad to see more grassroot-engagement or even any coming from the i=
ndustry with eager motivation to help on those fronts.<br><br>Ask not what =
Bitcoin can do for you - ask what you can do for Bitcoin :)<br>=C2=A0<br>Ch=
eers,<br>Antoine<br><br>PS: oh, and SIGHAsH_PURPLE for the win :p<br><br>[0=
] That&#39;s a joke on mutation testing, it&#39;s a trillion-dollar codebas=
e, but we don&#39;t do <br>mutation testing. Sad :/<br><br>[1] See <a href=
=3D"https://github.com/bitcoin-core/bitcoin-devwiki/wiki">https://github.co=
m/bitcoin-core/bitcoin-devwiki/wiki</a><br>=C2=A0<br>[2] Disclaimer: I&#39;=
m not open to outbound sponsorship proposals.<br><br>[3] As backed by data =
here : <a href=3D"https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-=
retro/">https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-retro/</a>=
<br><br>[4] For e.g, a lot of grant legal frameworks don&#39;t have clauses=
 guaranteeing the independence of the<br>general Bitcoin Core or Lightning =
development, just a smaller subset around validity of block rules,<br>inspi=
red from the BitMex open one. Clearly a hole if you ask any competent lawye=
r...<br><br>[5] Flavors of those concerns have been mentioned a lot through=
 Bitcoin archives:<br><br>See &quot;Bitcoin in 2021&quot;: =C2=A0<a href=3D=
"https://www.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021">https://w=
ww.erisian.com.au/wordpress/2021/01/07/bitcoin-in-2021</a><br><br>&quot; Af=
ter all, if you can replace all the people who would=E2=80=99ve objected to=
 what you want to do, there=E2=80=99s<br>no need to sneak it in and hope no=
 one notices in review, you can just do it, and even if you don=E2=80=99t <=
br>getrid of everyone who would object you at least lower the chances that =
your patch will get a thorough <br>review by whoever remains. There are a v=
ariety of ways you can do that. One is finding way of making<br>contributin=
g unpleasant enough that your targets just leave on their own: constant arg=
uments about <br>hings that don=E2=80=99t really matter, slowing down progr=
ess so it feels like you=E2=80=99re just wasting time,<br>and personal atta=
cks in the media (or on social media), for instance. Another is the cancel-=
culture <br>approach of trying to make them a pariah so no one else will ha=
ve anything to do with them.&quot;<br><br>Or see &quot;Working on social co=
ntracts (was: Paper currency)&quot; : <a href=3D"https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2014-May/005851.html">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2014-May/005851.html</a><br><br>&quot;I pr=
omise that if bad people show up with a sufficient pointy gun that<br>I&#39=
;ll do whatever they tell me to do. I&#39;ll make bad proposals, submit<br>=
backdoors, and argue with querulous folks on mailing lists, diverting<br>th=
em from real development and review work, all as commanded. Maybe<br>I&#39;=
ll try to sneak out a warning of some kind, maybe... but with my<br>life or=
 my families or friends lives on the line=E2=80=94 probably not.<br><br>...=
 and I think that anyone who tells you otherwise probably just<br>hasn&#39;=
t really thought it through.=C2=A0 So what is the point of commitments<br>l=
ike that?=C2=A0 People change, people go crazy, people are coerced. Crap<br=
>happens, justifications are made, life goes on=E2=80=94 or so we hope.&quo=
t;</div>

--00000000000068858c05c54803b9--