Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8801 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 9584 bytes --]