From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 23 Jul 2024 17:43:57 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWQ6m-0004qK-7J for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:43:57 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e03a694ba5asf12653816276.3 for ; Tue, 23 Jul 2024 17:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721781830; x=1722386630; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=dTterGpqSdZRvp/qoF50SXgYbl33T/XX4DFO9bJwP10=; b=SD1zI3SL88hLo7EMSqlvYrdHXBF+nkTLWV7SQBATaUopCBzUbJGTfLPPPJHNn6mfrf al3qbBAj9xgY/eQlJT4rbIMjPZojTcUnj4xmmZwAXnSieRIVUYSmEmdRjWS0qpjWAfrt yt2DHF52Rixc0CiluDEsyja0DvC2LKkZkZk+rel69ke3uOSVyyRDdx8A6L0y3Og/uOmi HMZkhaxhzH6Q+x/vl2uPk9Is+KpJAqkeWoaj+7GdTdLlUGuLYBL2D8SR2K630NHRkLc7 +ED7WuahKXV2JZ6Sp7FzhQ+fLjqO8o1v4aQWW/wyMhHfdRHFRRHkJzH0AVpa9jGNwZXX yO/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721781830; x=1722386630; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=dTterGpqSdZRvp/qoF50SXgYbl33T/XX4DFO9bJwP10=; b=frQ995XIB+wtMF52aw3EVw1jp/lZGQB0a/kdWXYTXtWtdIhzfnKddUfSciol3S4wnt wWegofLodxR4eG8wqZ2fgrPYZXWqC9tCauZxgwhDQKJiKNaFMe7N+xACpdmEd5v+7fbC dlml3jMiKs9q8/1oNdfEvgjf5855x0h+l1MT7hX6tcyuqWgNDBJLVujg/u528GYW7pF0 +eJvqgXWBvmd7HDqxp048vrtAoCfjum3I1Rd+C84vYyjpQFA91mCiKt7YoEPNC5/jf9j StZN8RCKj5UPBhIJqXxHskFU2qtJZ7v1j4PQTpoDy6RBQQrNIHDOYijXLXTAK2/DiD0m etIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721781830; x=1722386630; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=dTterGpqSdZRvp/qoF50SXgYbl33T/XX4DFO9bJwP10=; b=BhPcEz+7qrpaG6L3y+B8C9yO3q8VAITyTF1RNIzLPERSmIykxPwwEkThTlQi/EK8YK IcInU5LhOcMKzwB54KW6jsufNmtHYfh69W/FfD89+PZoJORQPAdmWHJWFQig67fftt3f 7O2tLNtBPzV4VKDzstnQ3VbHt92hUC2E29hxrv7WeYoiY9bT1/mrknaJzw7TrjwOTV7W 1NfFzrO5lKgPLakgMIf0LRtYD0rfpjrYYHpoD271CfKmkSeqVSXM8H6s/iQz+mbDCTcR lJbp80qLU9WyaJbcTtxNSfFkIzZSuCYPV+WRhkw1RAyNLgzeb8kP3Qa03IYHWZnV09xu OpHw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXPJqy6RXAydv8t9ZbpGXNopE/mA97e66DyQ2szrIQKQW5oQqtT541WBjfV3PjiCrZu7y1A1jGXfc7x3jCu20+fWkR3hRc= X-Gm-Message-State: AOJu0YzwKCp7azKMH/uLtu7i9U0cWbdqCx8Qf/aAnQqddY8iDYI5FvT5 wByT55pVmwUqBJuhhjz4EkcuveH3NrNnOZ7Q5ToXs8IaNx7s70ws X-Google-Smtp-Source: AGHT+IFlMxxcBMRelT1szFvb5nDMgIFoNAT91q75jdbbC/7wytLafhDkcjFXYh0sYZoAlERxje6XGw== X-Received: by 2002:a05:6902:240b:b0:e07:2e88:d88a with SMTP id 3f1490d57ef6-e0b0e383269mr805764276.1.1721781829907; Tue, 23 Jul 2024 17:43:49 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:53c2:0:b0:e03:aa7a:bb87 with SMTP id 3f1490d57ef6-e05fd8ce7fals9428311276.0.-pod-prod-09-us; Tue, 23 Jul 2024 17:43:48 -0700 (PDT) X-Received: by 2002:a05:690c:660d:b0:648:afcb:a7ce with SMTP id 00721157ae682-66a63f4a795mr4891607b3.3.1721781828356; Tue, 23 Jul 2024 17:43:48 -0700 (PDT) Received: by 2002:a05:690c:3104:b0:664:87b6:d9e0 with SMTP id 00721157ae682-66918fcc18cms7b3; Tue, 23 Jul 2024 17:36:01 -0700 (PDT) X-Received: by 2002:a25:6602:0:b0:e05:65b7:32d9 with SMTP id 3f1490d57ef6-e0870063c1fmr169239276.6.1721781359275; Tue, 23 Jul 2024 17:35:59 -0700 (PDT) Date: Tue, 23 Jul 2024 17:35:59 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com> <4f7eddff-9e2d-4beb-bcc6-832584cb939d@achow101.com> <2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn@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_1127250_1171932923.1721781359047" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_1127250_1171932923.1721781359047 Content-Type: multipart/alternative; boundary="----=_Part_1127251_1705006231.1721781359047" ------=_Part_1127251_1705006231.1721781359047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ava, Thanks for the additional thoughts. > Peter was not the only "senior" person on the security list. Obviously I > will not disclose non-public information, but certainly there are people > on the security list who are just as, if not more, senior than Peter. Apart of sipa (who is arelady public on the security.md), I think they are 2 more people with whom I had experience of interacting on the list that I think are as much "senior" than Peter, both of them from public notoriety and on their own declaration they are less active in bitcoin protocol=20 development (while they keep my reasonable trust if I have to report security=20 information). Apart of those 3 people, I don't see who is most senior than Peter in=20 bitcoin protocol development, and who an equivalent track records in matters of=20 adversarial exploitation, consensus changes and use-cases protocol design (as one needs= =20 a bit of understanding of the "userspace" when you're handling issues). I won't be a jerk to disclose in public people who I think are actually on= =20 the list, and that you might think off in saying "just as", and here I have practical= =20 experiences with a lot of people in the space who have been there since satoshi time or= =20 after. > Furthermore, the "old parts" still do get changed, and someone who no > longer actively contributes to the project is more likely to be unaware > of how the code actually works today, even if they are familiar with > components that change infrequently. This is not incorrect to say that "old parts" get changed, though the=20 frequency is far from being exceptional and the substantial changes are pretty rare.= =20 If you take few iconic files and you run stats (all no merges): - net_processing.cpp, initial file creation 2016, number of commits 926, in= =20 average 115 changes yearly - validation.cpp, initial file creation 2016, number of commits 1075, in=20 average 134 changes yearly - scheduler.cpp, initial file creation 2015, number of commits 47, in=20 average 5 changes yearly - interpreter.cpp, initial file creation 2014, number of commits 145, in=20 average 14 changes yearly One can certainly run more line code stats diff changes at each year point= =20 to get a granularity how much substantial changes they are and if they are any trend= =20 like subsystem being more stable than other. Validation and net processing are obviously beefy files ongoing regular=20 changes (as there has never been a patchset landing successs of the many attempts from many authors to= =20 break them further like #13413, #16175 and #18963). And what of substantial abstraction have been= =20 introduced in the past years in validation ? Package support and a lot of block-relay mitigations and=20 cleanup, not something like crazy. Consensus and its interfaces has by far has a rythm of upgrades more slow,= =20 for an ecosystem impact de-multiplied in case of issues (and it's harder to evaluate they might=20 have "horizontal" effect on use-cases like timelocks). Like I was saying evaluating who is active on=20 single-digit years timelines (and more probably 2 than 9) is short-sighted, and this does not match=20 practical experiences in other top open-source codebases like linux kernel. There is not only a necessity to be aware of how the code actually works=20 today, though also the undocumented or unforseen scope of things like past attacks vectors or=20 plausible past misinteractions. I think this something that Peter full disclosure illustrates well as more= =20 "junior" security list recipients, whatever their competency and goodwill, have failed to point out a type of= =20 class of attack that have come again and again in discussions about mempool rebroadcast years ago (see the= =20 PR link I was pointing out in one my Dave answer above). > Not being on the list does not preclude him from being consulted if the > need arises. "If the need arises" supposes a lot, as first it assumes the report=20 timeframes give you leeway to come as more or less group decision to share the sensitive information to someone like= =20 Peter, being a default recipient it's always faster (one might have to deal with situations where the=20 security flaw is already half-mentioned in public and it's better to act fast). Secondly, "if the need arises" is a technical judgement in itself. One=20 worst-case scenario could be for all the default recipients reading a no-spam report, though missing an angle of= =20 exposure or that actually it's a serious attack vector. It did happen to me on the lightning side in the= =20 past as I pointed out the general vulnerability and someone cc after comes up with novel observations that=20 were worsening the issues, or any hardening fix of it. > With the two examples you provide, I am not aware of Peter being > actively involved in the resolution of both of those, whereas there are > current members of the list who were. They were given as examples of situations where you prefer to have too much= =20 competent and responsible security list recipient that far too less, as both have temporal=20 contengencies far beyond the scope of bitcoin core list to deal with them (the first as the DB-switch provoked=20 fork was already happenin, the second as the report was from a bitcoin core fork coin). On the list of people being actively involved in the resolution of them, or= =20 who got privileged access to information before disclosure, from my experience they're some names=20 that I must say can be a bit sloppy in terms of reactiveness and implications in security issues=20 resolution (whatever the independent fact they're very skilled bitcoin engineers and pretty good reviewers). > In general though, it is not clear to me how it was beneficial to have > Peter on the security list, nor how not having him is directly harmful. > In the 2 years that I have been on the security list, I was unaware that > Peter was a recipient until shortly before he was removed. My > understanding is that others who have been on the list longer than me > were also unaware. Personally, I think Peter has still one of the most furnished track records= =20 in bugs findings around the mempool (the segwit malleability PR #8312) and understanding of all timelocks=20 issues with the authorship of bip65, which is critical for contract protocols. That one disagrees with another=20 security list member on its public technical opinions for newer changes, I think it's something one has to abstract when= =20 all security issues handlers are coming together to bring a mitigation to the issue. That one can be too much "cowboy" in matters of timelines full disclosure,= =20 which I think have been a bit about the last 3 "free relay" disclosure, the best you can do is say so either=20 publicly, or privately in all courtesy. No way to make progress on responsible disclosure standards, if no one never=20 speaks up. I was aware that Peter was on the list from conversations years ago with=20 him on a reported issue, far before all the present topics about V3 / TRUC / RBFR have been raised. In my=20 understanding, the fact that you were unaware that Peter was on the list can only reinforce impression had a very slow=20 pace in terms of security issues fixing, especially when it's coupled with the disclosure of all issues of past=20 months with which you have been involved. My number one recommendation would be to make the list of default security= =20 list recipient public, as it would create more personal accountability (both internally among the list=20 recipient and externally towards the security issues reporters / the wider community) and you can have a key fingerprint= =20 for each one which is good in terms of process. I certainly don't wish to pour the blame on anyone specifically, as I think= =20 the current "so-so" state of security issues handling by bitcoin core has been more a background result of all=20 the ups and downs of blocksize wars time, where contributors didn't focus on it sufficiently. Yet, I think it's very= =20 beneficial to think more about this process, before we see either more funds at stake with contract protocols and other= =20 applications (as it was well pointed out by one of the optech newsletter and sadly too known by lightning protocol devs,=20 what can be a medium severity on the base layer like transaction-relay censorship vector is very likely a high severity on= =20 upper layer). Best, Antoine ots hash: b8b4ce2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736 Le dimanche 21 juillet 2024 =C3=A0 21:49:10 UTC+1, Ava Chow a =C3=A9crit : > On 07/20/2024 10:06 PM, Antoine Riard wrote: > > "Naive", as saying this is the _Bitcoin Core_ project list only can onl= y=20 > > provoke blind > > spot among the list members if the security issues are either affecting= =20 > > old part of > > the codebases that younger members have less experiences with (some=20 > > parts like consensus > > or block-relay are modified only every 5 years) or novel factors from= =20 > > upstream or downstream > > (e.g the internet networking stack or implications on deployed contract= =20 > > protocols like > > lightning). On both the former and latter criterias, I think Peter=20 > > overly meets the bar. > > Peter was not the only "senior" person on the security list. Obviously I= =20 > will not disclose non-public information, but certainly there are people= =20 > on the security list who are just as, if not more, senior than Peter. > > Furthermore, the "old parts" still do get changed, and someone who no=20 > longer actively contributes to the project is more likely to be unaware= =20 > of how the code actually works today, even if they are familiar with=20 > components that change infrequently. > > > When you've big sh*t hitting the fan like inflation bugs or level DB=20 > > 2013 unexpected fork you > > prefer have experts with a decade of experience to collaborate with, an= d=20 > > sharing the same cultural > > and ethical norms of the active contributors evaluated by numbers on=20 > > commits on the last single-digit > > years. > > Not being on the list does not preclude him from being consulted if the= =20 > need arises. > > With the two examples you provide, I am not aware of Peter being=20 > actively involved in the resolution of both of those, whereas there are= =20 > current members of the list who were. > > > In general though, it is not clear to me how it was beneficial to have=20 > Peter on the security list, nor how not having him is directly harmful.= =20 > In the 2 years that I have been on the security list, I was unaware that= =20 > Peter was a recipient until shortly before he was removed. My=20 > understanding is that others who have been on the list longer than me=20 > were also unaware. > > Ava > > >=20 > > I'll repropose Peter admission on the security list mailing list in the= =20 > > coming weeks by opening an > > issue on the bitcoin-meta repository, once this current mailing list=20 > > thread has slowed down a bit, > > or at least the technical analysis has been dissociated from the=20 > > proceedings which have all been > > bundle in a big message. In my very personal opinion, I still trust mor= e=20 > > Peter competence and experience > > than some other people I know who are on the security mailing list. > >=20 > > All that said I appreciate your answer and I'm satisfied from the=20 > > personal role you've have played > > in the matter with, and be reassured I'll keep you among the recipient= =20 > > of future security issues with > > a potential impact on bitcoin core that I might find or be aware off. > >=20 > > Best, > > Antoine > > ots hash:=20 > db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54 > >=20 > > Le samedi 20 juillet 2024 =C3=A0 01:50:25 UTC+1, Ava Chow a =C3=A9crit = : > >=20 > > 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. > >=20 > > I am not the one that removed Peter from the mailing list, nor do I > > even > > have the login(s) to do so. > >=20 > > 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. > >=20 > > My recollection is that multiple other people were removed from the > > list > > for the same reason at the same time. > >=20 > > Ava > >=20 > > --=20 > > You received this message because you are subscribed to the Google=20 > > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > > an email to bitcoindev+...@googlegroups.com=20 > > . > > To view this discussion on the web visit=20 > >=20 > https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2= f7c657abn%40googlegroups.com=20 > < > https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2= f7c657abn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter > >. > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com. ------=_Part_1127251_1705006231.1721781359047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ava,

Thanks for the additional thoughts.

> Pete= r was not the only "senior" person on the security list. Obviously I
&= gt; will not disclose non-public information, but certainly there are peopl= e
> on the security list who are just as, if not more, senior than = Peter.

Apart of sipa (who is arelady public on the security.md),= I think they are
2 more people with whom I had experience of interact= ing on the list that I
think are as much "senior" than Peter, both of = them from public notoriety
and on their own declaration they are less = active in bitcoin protocol development
(while they keep my reasonable = trust if I have to report security information).

Apart of those = 3 people, I don't see who is most senior than Peter in bitcoin
protoco= l development, and who an equivalent track records in matters of adversaria= l
exploitation, consensus changes and use-cases protocol design (as on= e needs a bit
of understanding of the "userspace" when you're handling= issues).

I won't be a jerk to disclose in public people who I t= hink are actually on the list,
and that you might think off in saying = "just as", and here I have practical experiences
with a lot of people = in the space who have been there since satoshi time or after.

&g= t; Furthermore, the "old parts" still do get changed, and someone who no> longer actively contributes to the project is more likely to be una= ware
> of how the code actually works today, even if they are famil= iar with
> components that change infrequently.

This is = not incorrect to say that "old parts" get changed, though the frequency
is far from being exceptional and the substantial changes are pretty rare= . If you
take few iconic files and you run stats (all no merges):
- net_processing.cpp, initial file creation 2016, number of commits 926, i= n average 115 changes yearly
- validation.cpp, initial file creation 2= 016, number of commits 1075, in average 134 changes yearly
- scheduler= .cpp, initial file creation 2015, number of commits 47, in average 5 change= s yearly
- interpreter.cpp, initial file creation 2014, number of comm= its 145, in average 14 changes yearly

One can certainly run more= line code stats diff changes at each year point to get a
granularity = how much substantial changes they are and if they are any trend like
s= ubsystem being more stable than other.

Validation and net proces= sing are obviously beefy files ongoing regular changes (as there has never<= br />been a patchset landing successs of the many attempts from many author= s to break them further like
#13413, #16175 and #18963). And what of s= ubstantial abstraction have been introduced in the past years
in valid= ation ? Package support and a lot of block-relay mitigations and cleanup, n= ot something like crazy.

Consensus and its interfaces has by far= has a rythm of upgrades more slow, for an ecosystem impact
de-multipl= ied in case of issues (and it's harder to evaluate they might have "horizon= tal" effect on
use-cases like timelocks). Like I was saying evaluating= who is active on single-digit years timelines
(and more probably 2 th= an 9) is short-sighted, and this does not match practical experiences in ot= her
top open-source codebases like linux kernel.

There is n= ot only a necessity to be aware of how the code actually works today, thoug= h also the
undocumented or unforseen scope of things like past attacks= vectors or plausible past misinteractions.

I think this somethi= ng that Peter full disclosure illustrates well as more "junior" security li= st recipients,
whatever their competency and goodwill, have failed to = point out a type of class of attack that have come
again and again in = discussions about mempool rebroadcast years ago (see the PR link I was poin= ting out in
one my Dave answer above).

> Not being on th= e list does not preclude him from being consulted if the
> need ari= ses.

"If the need arises" supposes a lot, as first it assumes th= e report timeframes give you leeway to come as more
or less group deci= sion to share the sensitive information to someone like Peter, being a defa= ult recipient
it's always faster (one might have to deal with situatio= ns where the security flaw is already half-mentioned
in public and it'= s better to act fast).

Secondly, "if the need arises" is a techn= ical judgement in itself. One worst-case scenario could be for all
the= default recipients reading a no-spam report, though missing an angle of ex= posure or that actually it's
a serious attack vector. It did happen to= me on the lightning side in the past as I pointed out the general
vul= nerability and someone cc after comes up with novel observations that were = worsening the issues, or any
hardening fix of it.

> With= the two examples you provide, I am not aware of Peter being
> acti= vely involved in the resolution of both of those, whereas there are
&g= t; current members of the list who were.

They were given as exam= ples of situations where you prefer to have too much competent and responsi= ble
security list recipient that far too less, as both have temporal c= ontengencies far beyond the scope of
bitcoin core list to deal with th= em (the first as the DB-switch provoked fork was already happenin, the
second as the report was from a bitcoin core fork coin).

On the= list of people being actively involved in the resolution of them, or who g= ot privileged access
to information before disclosure, from my experie= nce they're some names that I must say can be a bit
sloppy in terms of= reactiveness and implications in security issues resolution (whatever the = independent
fact they're very skilled bitcoin engineers and pretty goo= d reviewers).

> In general though, it is not clear to me how = it was beneficial to have
> Peter on the security list, nor how not= having him is directly harmful.
> In the 2 years that I have been = on the security list, I was unaware that
> Peter was a recipient un= til shortly before he was removed. My
> understanding is that other= s who have been on the list longer than me
> were also unaware.

Personally, I think Peter has still one of the most furnished track= records in bugs findings around the mempool
(the segwit malleability = PR #8312) and understanding of all timelocks issues with the authorship of = bip65, which
is critical for contract protocols. That one disagrees wi= th another security list member on its public technical
opinions for n= ewer changes, I think it's something one has to abstract when all security = issues handlers are coming
together to bring a mitigation to the issue= .

That one can be too much "cowboy" in matters of timelines full= disclosure, which I think have been a bit about the
last 3 "free rela= y" disclosure, the best you can do is say so either publicly, or privately = in all courtesy. No way
to make progress on responsible disclosure sta= ndards, if no one never speaks up.

I was aware that Peter was on= the list from conversations years ago with him on a reported issue, far be= fore
all the present topics about V3 / TRUC / RBFR have been raised. I= n my understanding, the fact that you were unaware
that Peter was on t= he list can only reinforce impression had a very slow pace in terms of secu= rity issues fixing,
especially when it's coupled with the disclosure o= f all issues of past months with which you have been involved.

M= y number one recommendation would be to make the list of default security l= ist recipient public, as it would
create more personal accountability = (both internally among the list recipient and externally towards the securi= ty
issues reporters / the wider community) and you can have a key fing= erprint for each one which is good in terms of process.

I certai= nly don't wish to pour the blame on anyone specifically, as I think the cur= rent "so-so" state of security
issues handling by bitcoin core has bee= n more a background result of all the ups and downs of blocksize wars time,=
where contributors didn't focus on it sufficiently. Yet, I think it's= very beneficial to think more about this process,
before we see eithe= r more funds at stake with contract protocols and other applications (as it= was well pointed out by one
of the optech newsletter and sadly too kn= own by lightning protocol devs, what can be a medium severity on the base l= ayer
like transaction-relay censorship vector is very likely a high se= verity on upper layer).

Best,
Antoine
ots hash: b8b4ce= 2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736

Le dimanche 21= juillet 2024 =C3=A0 21:49:10 UTC+1, Ava Chow a =C3=A9crit=C2=A0:
On 07/20/2024 10:06 PM= , Antoine Riard wrote:
> "Naive", as saying this is the _Bitcoin Core_ project li= st only can only=20
> provoke blind
> spot among the list members if the security issues are either affe= cting=20
> old part of
> the codebases that younger members have less experiences with (som= e=20
> parts like consensus
> or block-relay are modified only every 5 years) or novel factors f= rom=20
> upstream or downstream
> (e.g the internet networking stack or implications on deployed con= tract=20
> protocols like
> lightning). On both the former and latter criterias, I think Peter= =20
> overly meets the bar.

Peter was not the only "senior" person on the security list. = Obviously I=20
will not disclose non-public information, but certainly there are peopl= e=20
on the security list who are just as, if not more, senior than Peter.

Furthermore, the "old parts" still do get changed, and someon= e who no=20
longer actively contributes to the project is more likely to be unaware= =20
of how the code actually works today, even if they are familiar with=20
components that change infrequently.

> When you've big sh*t hitting the fan like inflation bugs or le= vel DB=20
> 2013 unexpected fork you
> prefer have experts with a decade of experience to collaborate wit= h, and=20
> sharing the same cultural
> and ethical norms of the active contributors evaluated by numbers = on=20
> commits on the last single-digit
> years.

Not being on the list does not preclude him from being consulted if the= =20
need arises.

With the two examples you provide, I am not aware of Peter being=20
actively involved in the resolution of both of those, whereas there are= =20
current members of the list who were.


In general though, it is not clear to me how it was beneficial to have= =20
Peter on the security list, nor how not having him is directly harmful.= =20
In the 2 years that I have been on the security list, I was unaware tha= t=20
Peter was a recipient until shortly before he was removed. My=20
understanding is that others who have been on the list longer than me= =20
were also unaware.

Ava

>=20
> I'll repropose Peter admission on the security list mailing li= st in the=20
> coming weeks by opening an
> issue on the bitcoin-meta repository, once this current mailing li= st=20
> thread has slowed down a bit,
> or at least the technical analysis has been dissociated from the= =20
> proceedings which have all been
> bundle in a big message. In my very personal opinion, I still trus= t more=20
> Peter competence and experience
> than some other people I know who are on the security mailing list= .
>=20
> All that said I appreciate your answer and I'm satisfied from = the=20
> personal role you've have played
> in the matter with, and be reassured I'll keep you among the r= ecipient=20
> of future security issues with
> a potential impact on bitcoin core that I might find or be aware o= ff.
>=20
> Best,
> Antoine
> ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd8= 67ccdd54
>=20
> Le samedi 20 juillet 2024 =C3=A0 01:50:25 UTC+1, Ava Chow a =C3=A9= crit=C2=A0:
>=20
> 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 mai= ling
> list, when
> > you were certainly
> > more senior than achow101 in matters of base-layer secur= ity
> 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.
>=20
> I am not the one that removed Peter from the mailing list, nor= do I
> even
> have the login(s) to do so.
>=20
> There was a discussion amongst several members of the security= list
> about who was on the list, and who should be on the list. Give= n that
> the
> security list is the _Bitcoin Core_ security list, we determin= ed that
> the people who should be on the list are people who still acti= vely
> contribute to the project. As Peter Todd no longer actively co= ntribute
> code nor code review to the project, we decided that it didn&#= 39;t make
> sense to continue to have him on the list.
>=20
> My recollection is that multiple other people were removed fro= m the
> list
> for the same reason at the same time.
>=20
> Ava
>=20
> --=20
> You received this message because you are subscribed to the Google= =20
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, = send=20
> an email to bitcoindev+= ...@googlegroups.com=20
> <mailto:bitcoindev+.= ..@googlegroups.com>.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/b= itcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com <= https://groups.google.com/d/msgid/b= itcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medi= um=3Demail&utm_source=3Dfooter>.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com.=
------=_Part_1127251_1705006231.1721781359047-- ------=_Part_1127250_1171932923.1721781359047--