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: Sat, 20 Jul 2024 19:06:49 -0700 (PDT) [thread overview]
Message-ID: <2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn@googlegroups.com> (raw)
In-Reply-To: <4f7eddff-9e2d-4beb-bcc6-832584cb939d@achow101.com>
[-- Attachment #1.1: Type: text/plain, Size: 5883 bytes --]
Hi Ava,
Thanks for the answer and the additional information.
I think this is unclear to me if Peter himself was part of the discussion
amongst several members of the security list on re-examining if their
presence
and the ones of others was still worthy on the list, be it online or
offline.
I fully understrand this is a kind of conversation which certainly does not
warrant to be public, and I mostly agree with that. Yet I believe it's
ethically
bordeline to not invite someome to express its own viewpoint in asking to be
removal of its own access, especially in a project that aims to be
decentralized
and a technnical meritocracy (-- I believe an ideal we aspire all).
Beyond, and forgive the expression if it's a bit rude, I believe it's a bit
"naive",
"short-sighted" as a position of the members of the security list, with
whatever
level of true consensus such removal has being done (-- and I'm not aware
there
was operational security emergency that justified such removal).
"Naive", as saying this is the _Bitcoin Core_ project list only can only
provoke blind
spot among the list members if the security issues are either affecting old
part of
the codebases that younger members have less experiences with (some parts
like consensus
or block-relay are modified only every 5 years) or novel factors from
upstream or downstream
(e.g the internet networking stack or implications on deployed contract
protocols like
lightning). On both the former and latter criterias, I think Peter overly
meets the bar.
"Short-sighted", as it's making the members of the security list both party
and arbiter
of appreciating what is an _active_ contributor among themselves (all in a
very ethically
bordeline fashion). In my experience with lightning over the past years,
with discovering
more and more issues which in fact that arises from imperfect interfacting
with the base-layer,
I was progressively lead to spend more and more time on the core side as it
was natural to
have things fixed thhere (or at least advocate so). Of course, I was in
consequence less active
on the lighting development day-to-day side. Did it make be less competent
to be responsive when
issues affected lighting ? I don't believe so (though obviously I'll let
other lightning experts
corroborate or infirm this self-cogtratulory statement of mine).
Same for Peter, if he had make the choices to consencrate its open-source
time on more long-term
things like transaction denial-of-service vectors or analyzing new
consensus changes proposals
(whatever the long-erm outcome, R&D is a stochastic process -- his track
records with things like
bip65 shall give him a positive presumption)
I think as a community to give such cultural margin to do so, even if it's
as the trade-off of
less review on day-to-day core things with a more reduced global scope like
the gui or the wallet.
When you've big sh*t hitting the fan like inflation bugs or level DB 2013
unexpected fork you
prefer have experts with a decade of experience to collaborate with, and
sharing the same cultural
and ethical norms of the active contributors evaluated by numbers on
commits on the last single-digit
years.
I'll repropose Peter admission on the security list mailing list in the
coming weeks by opening an
issue on the bitcoin-meta repository, once this current mailing list thread
has slowed down a bit,
or at least the technical analysis has been dissociated from the
proceedings which have all been
bundle in a big message. In my very personal opinion, I still trust more
Peter competence and experience
than some other people I know who are on the security mailing list.
All that said I appreciate your answer and I'm satisfied from the personal
role you've have played
in the matter with, and be reassured I'll keep you among the recipient of
future security issues with
a potential impact on bitcoin core that I might find or be aware off.
Best,
Antoine
ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > As said in one my previous email, I'm still curious about achow101
> > explaining publicly
> > why you have been kicked-out of the bitcoin-security mailing list, when
> > you were certainly
> > more senior than achow101 in matters of base-layer security issues or
> > even hard technical
> > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > respect towards achow101
> > as a maintainer from years of collaboration, though this is a topic
> > worthy of an answer.
>
> I am not the one that removed Peter from the mailing list, nor do I even
> have the login(s) to do so.
>
> There was a discussion amongst several members of the security list
> about who was on the list, and who should be on the list. Given that the
> security list is the _Bitcoin Core_ security list, we determined that
> the people who should be on the list are people who still actively
> contribute to the project. As Peter Todd no longer actively contribute
> code nor code review to the project, we decided that it didn't make
> sense to continue to have him on the list.
>
> My recollection is that multiple other people were removed from the list
> for the same reason at the same time.
>
> Ava
>
>
--
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/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6638 bytes --]
next prev parent reply other threads:[~2024-07-21 18:03 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 [this message]
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
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=2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn@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