From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Tue, 23 Jul 2024 17:44:20 -0700 (PDT) [thread overview]
Message-ID: <1f6d6917-01f1-496d-9c97-8513fce24149n@googlegroups.com> (raw)
In-Reply-To: <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.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 --]
next prev parent reply other threads:[~2024-07-24 0:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 [bitcoindev] " Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19 1:05 ` Peter Todd
2024-07-19 13:52 ` Antoine Riard
2024-07-19 14:38 ` Peter Todd
2024-07-19 23:58 ` Antoine Riard
2024-07-20 0:46 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21 2:06 ` Antoine Riard
2024-07-21 20:17 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22 1:59 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24 0:44 ` Antoine Riard [this message]
2024-07-24 0:35 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56 ` Antoine Riard
2024-07-20 5:57 ` /dev /fd0
2024-07-20 15:08 ` Peter Todd
2024-07-21 2:13 ` Antoine Riard
2024-07-21 6:16 ` /dev /fd0
2024-07-21 2:12 ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10 ` Peter Todd
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding
2024-07-21 20:25 ` Peter Todd
2024-07-24 0:38 ` Antoine Riard
2024-07-21 2:10 ` Antoine Riard
2024-07-22 15:10 ` Peter Todd
2024-07-24 0:41 ` Antoine Riard
2024-07-22 11:45 ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43 ` David A. Harding
2024-07-22 20:06 ` Peter Todd
2024-07-22 22:08 ` David A. Harding
2024-07-23 11:29 ` Peter Todd
2024-07-24 0:42 ` Antoine Riard
2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f6d6917-01f1-496d-9c97-8513fce24149n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox