Delivery-date: Tue, 23 Jul 2024 17:46:08 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 23 Jul 2024 17:44:20 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1f6d6917-01f1-496d-9c97-8513fce24149n@googlegroups.com>
In-Reply-To: <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com>
 <Zpm73WHBNIkkIT0Y@petertodd.org>
 <CALZpt+HJvBXM_geK7JC8umrt1goq8bc+pnY0mk+o+r_+bjrtew@mail.gmail.com>
 <Zpp6U00Mp7Z/bOej@petertodd.org>
 <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com>
 <4f7eddff-9e2d-4beb-bcc6-832584cb939d@achow101.com>
 <2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn@googlegroups.com>
 <a8eac5f2-b85a-434f-868e-eba7fd2558c6@achow101.com>
 <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The
 Lack of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_933414_432050491.1721781860217"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_933414_432050491.1721781860217
Content-Type: multipart/alternative; 
	boundary="----=_Part_933415_390350297.1721781860217"

------=_Part_933415_390350297.1721781860217
Content-Type: text/plain; charset="UTF-8"

Hi Anonymous,

Let's add more characterization by zooming out on a 15 years timeline on
the situation for an external observer less versed in usual bitcoin core 
development.

Historically, the project has been cared of by veteran of open-source 
projects,
old cypherpunks and other contributors used to security system engineering. 
While
qualms on technical proposals have always been heated even in the early 
days (e.g
the infamous OP_EVAL or bloom-filters bip37), at the very least 
protagonists in
the conversation were taking technical arguments at their sound value and 
killing
weak ideas when a majority of contributors have came to the same conclusion.

The resistant to the arguments, if they did not have the intellectual 
honesty to
fully appreciate arguments, were slowly moving out of contributing to 
bitcoin or
projects around to go work on fork-coins or something else. From my 
experience,
historically bitcoin had some of the most scientifically grounded and 
software
skilled contributors sweating hard and ready to risk their professional 
careeers
to make the bitcoin core codebase advance. There is a bit of subjectivity 
involved
here though I worked on code changes and review with some people since the 
early
days and if you take the "old guard" the level is here.

With time, especially after the block size war which have been intense 
whatever
the camp you have followed, some more "senior" core contributors have take 
a more
or less step back, without necessarily taking the time to fully transmit 
the same
level of technical and ethical standard to newcomers making their dents on 
the project.
This trend has only been worsen with the Faketoshi lawsuits, where even 
more "senior"
contributors have take a step back.

All those "senior" folks, of which Peter is a good specimen, where very 
okay when you
yelled at them that code was broken or a significant low-level proposal was 
weak and
it was better to fix them before to move forward. Without always 
necessarily caring
about following the utmost courtesy and politeness.

At the very same time of the end of the block size war and when faketoshi 
lawsuits where
taking the most of their toll among the contributors, there has been more 
the growth
of a culture of "professionalizing" the bitcoin core space. That have 
translated in a
number of dimensions, e.g we have started to seen a myriad of 
"money-helicopter" open-source
grants (most of the times attributed to hard working folks, sometimes 
giving the impression
that attribution has been done on more external "social" factors). In 
parallel, there
has been an emphasis in the core developnment process to ship complex code 
in low-level
subsystems, whatever the thoroughness of the design and code review, as 
landing complex
code not only make good story to tell on podcasts and twitter but it has 
also become a
self-sustaining argument to grap more open-source grants for some less 
regarding contributors.

(I don't know if a lot of folks are familiar with the school of public 
choice in economics
and the concept of rent-seeking capture, one can wonder if it's not a 
phenomena affecting
bitcoin open-source stage too. This is not saying that it's great to have 
folks on open-source
grants to handle releases, refactor the old parts of the codebase or write 
more tests,
I think just to be more far conservative when it comes to implementation of 
new mechanism and
minimizing the impact of incentives nurturing complacency).

With that accumulation of uncoordinated cultural changes, and open-source 
grants becoming
the norm as a mode of compensation among the majority of bitcoin core 
contributors (rather
than exercising their skills on the market or being good with their btc 
stack), in my
impression there has been more and more a wind of spontanous 
self-censorship arising among
the current generation of contributors. After all, what one would take the 
risk of being
far too negative or adverserial in the review of one's co-contributors 
patchset, when that
very co-contributor might judge for your grant re-attribution at the end of 
the year ?

Better to not take the risk, and if it's coupled with having a small btc 
stack even if there
is a major security failure X years from now, you wouldn't personally pay 
the cost as your
fiat-denominated grant will be still dump on you. All you have to do in 
case of security failure
is run away from any responsibility and engage in a heavy public 
relationship effort saying
everything is all right, bragging about the fact that you're a maintainer 
or that you've seen
worst in the past (were indeed you were not the ones doing the hard work at 
the time).

It might be a very personal opinion, though I think there have been a 
serious downgrade in
bitcoin core culture about technical proposals, where it was estimated that 
the code was broken
to a more current culture of first not making wawe and to be always 
"constructive" (even if no
ones knows exactly what does it mean to be constructive when a technical 
proposal has been analyzed
to be broken and when it's reasonably wiser to abandon months of 
engineering effort rather to
jeopardize end users funds safety) [0].

[0] https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md

Quote: "One can just have a look on the newer moderation rules, where it is 
explicitly said "on the
understanding that it is easier to rephrase deleted comments to be 
constructive and respectful
than to replace long term contributors who are burnt out from a discussion 
culture that is
unnecessarily contentious and overbearing" [0].

I think here some astute minds could observe that progress in the domain of 
scientific ideas if one
complete history on few centuries are driven a lot by controversy, 
overbearing experiments done again
and again and argumentation layout repeated multiple times in front of many 
audiences, as some brilliant
ideas might be counter-intuitive at first.

With all said and joining on your suggestion to fork core or have in-place 
multiple security
mailing lists. On the former this does not abstract from gathering enough 
dedicated experts
behind the same codebase, though more importantly maintaining a culture of 
collaboration among
the different full-node implementation. If it's go back to the situation of 
Bitcoin XT fork
and Bitcoin Segwit2X, where experts are fighting each other to "dictate" 
the consensus rules
this is not worth it. New civil war in bitcoin is a situation where 
everyone will be at loss.

On the latter suggestion, multiple security list is more or less already 
the current dynamics
as historically you had coordination among lightning implementations or 
with the mining ecosystem.
Whatever the reality of a single endpoint, at the end of the day it's more 
a "peer-to-peer" dynamic,
after a while you know you can personally trust and who is very skilled in 
area X or area Y or bitcoin. 

Degree and goodwill of collaboration is more important that the 
communication channel itself, as some
bitcoin core contributors reveals publicly recently what was more or less 
known in internal circles about
the project management of security issues [1]:

[1] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Quote: "The project has historically done a poor job at publicly disclosing 
security-critical bugs, whether externally
reported or found by contributors. This has led to a situation where a lot 
of users perceive Bitcoin Core as
never having bugs. This perception is dangerous and, unfortunately, not 
accurate."

I hope certainly there will be some cultural electro shocks, of which 
Peter's present disclosure email
can consistute an opportunity for a lot of people to medidate on, that we 
improve the security of the bitcoin
ecosystem at large by adopting good security issues handling process. And 
that before we're seeing massively
contract protocols and second layers being p0wned by North Korea sponsored 
hacking groups -- if the evidences
gathered by the wider cybersecurity community is correct on this front.

Reader beware - All those historical considerations on the evolution of 
bitcoin core culture only represents
my own opinion, this is necessarily the reflect of my subjective experience 
as a contributor and there is no need
to trust me.

Best,
Antoine
ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com.

------=_Part_933415_390350297.1721781860217
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Anonymous,<br /><br />Let's add more characterization by zooming out on =
a 15 years timeline on<br />the situation for an external observer less ver=
sed in usual bitcoin core development.<br /><br />Historically, the project=
 has been cared of by veteran of open-source projects,<br />old cypherpunks=
 and other contributors used to security system engineering. While<br />qua=
lms on technical proposals have always been heated even in the early days (=
e.g<br />the infamous OP_EVAL or bloom-filters bip37), at the very least pr=
otagonists in<br />the conversation were taking technical arguments at thei=
r sound value and killing<br />weak ideas when a majority of contributors h=
ave came to the same conclusion.<br /><br />The resistant to the arguments,=
 if they did not have the intellectual honesty to<br />fully appreciate arg=
uments, were slowly moving out of contributing to bitcoin or<br />projects =
around to go work on fork-coins or something else. From my experience,<br /=
>historically bitcoin had some of the most scientifically grounded and soft=
ware<br />skilled contributors sweating hard and ready to risk their profes=
sional careeers<br />to make the bitcoin core codebase advance. There is a =
bit of subjectivity involved<br />here though I worked on code changes and =
review with some people since the early<br />days and if you take the "old =
guard" the level is here.<br /><br />With time, especially after the block =
size war which have been intense whatever<br />the camp you have followed, =
some more "senior" core contributors have take a more<br />or less step bac=
k, without necessarily taking the time to fully transmit the same<br />leve=
l of technical and ethical standard to newcomers making their dents on the =
project.<br />This trend has only been worsen with the Faketoshi lawsuits, =
where even more "senior"<br />contributors have take a step back.<br /><br =
/>All those "senior" folks, of which Peter is a good specimen, where very o=
kay when you<br />yelled at them that code was broken or a significant low-=
level proposal was weak and<br />it was better to fix them before to move f=
orward. Without always necessarily caring<br />about following the utmost c=
ourtesy and politeness.<br /><br />At the very same time of the end of the =
block size war and when faketoshi lawsuits where<br />taking the most of th=
eir toll among the contributors, there has been more the growth<br />of a c=
ulture of "professionalizing" the bitcoin core space. That have translated =
in a<br />number of dimensions, e.g we have started to seen a myriad of "mo=
ney-helicopter" open-source<br />grants (most of the times attributed to ha=
rd working folks, sometimes giving the impression<br />that attribution has=
 been done on more external "social" factors). In parallel, there<br />has =
been an emphasis in the core developnment process to ship complex code in l=
ow-level<br />subsystems, whatever the thoroughness of the design and code =
review, as landing complex<br />code not only make good story to tell on po=
dcasts and twitter but it has also become a<br />self-sustaining argument t=
o grap more open-source grants for some less regarding contributors.<br /><=
br />(I don't know if a lot of folks are familiar with the school of public=
 choice in economics<br />and the concept of rent-seeking capture, one can =
wonder if it's not a phenomena affecting<br />bitcoin open-source stage too=
. This is not saying that it's great to have folks on open-source<br />gran=
ts to handle releases, refactor the old parts of the codebase or write more=
 tests,<br />I think just to be more far conservative when it comes to impl=
ementation of new mechanism and<br />minimizing the impact of incentives nu=
rturing complacency).<br /><br />With that accumulation of uncoordinated cu=
ltural changes, and open-source grants becoming<br />the norm as a mode of =
compensation among the majority of bitcoin core contributors (rather<br />t=
han exercising their skills on the market or being good with their btc stac=
k), in my<br />impression there has been more and more a wind of spontanous=
 self-censorship arising among<br />the current generation of contributors.=
 After all, what one would take the risk of being<br />far too negative or =
adverserial in the review of one's co-contributors patchset, when that<br /=
>very co-contributor might judge for your grant re-attribution at the end o=
f the year ?<br /><br />Better to not take the risk, and if it's coupled wi=
th having a small btc stack even if there<br />is a major security failure =
X years from now, you wouldn't personally pay the cost as your<br />fiat-de=
nominated grant will be still dump on you. All you have to do in case of se=
curity failure<br />is run away from any responsibility and engage in a hea=
vy public relationship effort saying<br />everything is all right, bragging=
 about the fact that you're a maintainer or that you've seen<br />worst in =
the past (were indeed you were not the ones doing the hard work at the time=
).<br /><br />It might be a very personal opinion, though I think there hav=
e been a serious downgrade in<br />bitcoin core culture about technical pro=
posals, where it was estimated that the code was broken<br />to a more curr=
ent culture of first not making wawe and to be always "constructive" (even =
if no<br />ones knows exactly what does it mean to be constructive when a t=
echnical proposal has been analyzed<br />to be broken and when it's reasona=
bly wiser to abandon months of engineering effort rather to<br />jeopardize=
 end users funds safety) [0].<br /><br />[0] https://github.com/bitcoin-cor=
e/meta/blob/main/MODERATION-GUIDELINES.md<br /><br />Quote: "One can just h=
ave a look on the newer moderation rules, where it is explicitly said "on t=
he<br />understanding that it is easier to rephrase deleted comments to be =
constructive and respectful<br />than to replace long term contributors who=
 are burnt out from a discussion culture that is<br />unnecessarily content=
ious and overbearing" [0].<br /><br />I think here some astute minds could =
observe that progress in the domain of scientific ideas if one<br />complet=
e history on few centuries are driven a lot by controversy, overbearing exp=
eriments done again<br />and again and argumentation layout repeated multip=
le times in front of many audiences, as some brilliant<br />ideas might be =
counter-intuitive at first.<br /><br />With all said and joining on your su=
ggestion to fork core or have in-place multiple security<br />mailing lists=
. On the former this does not abstract from gathering enough dedicated expe=
rts<br />behind the same codebase, though more importantly maintaining a cu=
lture of collaboration among<br />the different full-node implementation. I=
f it's go back to the situation of Bitcoin XT fork<br />and Bitcoin Segwit2=
X, where experts are fighting each other to "dictate" the consensus rules<b=
r />this is not worth it. New civil war in bitcoin is a situation where eve=
ryone will be at loss.<br /><br />On the latter suggestion, multiple securi=
ty list is more or less already the current dynamics<br />as historically y=
ou had coordination among lightning implementations or with the mining ecos=
ystem.<br />Whatever the reality of a single endpoint, at the end of the da=
y it's more a "peer-to-peer" dynamic,<br />after a while you know you can p=
ersonally trust and who is very skilled in area X or area Y or bitcoin. <br=
 /><br />Degree and goodwill of collaboration is more important that the co=
mmunication channel itself, as some<br />bitcoin core contributors reveals =
publicly recently what was more or less known in internal circles about<br =
/>the project management of security issues [1]:<br /><br />[1] https://gro=
ups.google.com/g/bitcoindev/c/Q2ZGit2wF7w<br /><br />Quote: "The project ha=
s historically done a poor job at publicly disclosing security-critical bug=
s, whether externally<br />reported or found by contributors. This has led =
to a situation where a lot of users perceive Bitcoin Core as<br />never hav=
ing bugs. This perception is dangerous and, unfortunately, not accurate."<b=
r /><br />I hope certainly there will be some cultural electro shocks, of w=
hich Peter's present disclosure email<br />can consistute an opportunity fo=
r a lot of people to medidate on, that we improve the security of the bitco=
in<br />ecosystem at large by adopting good security issues handling proces=
s. And that before we're seeing massively<br />contract protocols and secon=
d layers being p0wned by North Korea sponsored hacking groups -- if the evi=
dences<br />gathered by the wider cybersecurity community is correct on thi=
s front.<br /><br />Reader beware - All those historical considerations on =
the evolution of bitcoin core culture only represents<br />my own opinion, =
this is necessarily the reflect of my subjective experience as a contributo=
r and there is no need<br />to trust me.<br /><br />Best,<br />Antoine<br /=
>ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891=
<br />

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com</a>.=
<br />

------=_Part_933415_390350297.1721781860217--

------=_Part_933414_432050491.1721781860217--