Delivery-date: Tue, 23 Jul 2024 17:43:57 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 23 Jul 2024 17:35:59 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f9d17558-4b74-401b-bb64-fed34bd46619n@googlegroups.com>
In-Reply-To: <a8eac5f2-b85a-434f-868e-eba7fd2558c6@achow101.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>
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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
> > <mailto:bitcoindev+...@googlegroups.com>.
> > 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,<br /><br />Thanks for the additional thoughts.<br /><br />&gt; Pete=
r was not the only "senior" person on the security list. Obviously I<br />&=
gt; will not disclose non-public information, but certainly there are peopl=
e<br />&gt; on the security list who are just as, if not more, senior than =
Peter.<br /><br />Apart of sipa (who is arelady public on the security.md),=
 I think they are<br />2 more people with whom I had experience of interact=
ing on the list that I<br />think are as much "senior" than Peter, both of =
them from public notoriety<br />and on their own declaration they are less =
active in bitcoin protocol development<br />(while they keep my reasonable =
trust if I have to report security information).<br /><br />Apart of those =
3 people, I don't see who is most senior than Peter in bitcoin<br />protoco=
l development, and who an equivalent track records in matters of adversaria=
l<br />exploitation, consensus changes and use-cases protocol design (as on=
e needs a bit<br />of understanding of the "userspace" when you're handling=
 issues).<br /><br />I won't be a jerk to disclose in public people who I t=
hink are actually on the list,<br />and that you might think off in saying =
"just as", and here I have practical experiences<br />with a lot of people =
in the space who have been there since satoshi time or after.<br /><br />&g=
t; Furthermore, the "old parts" still do get changed, and someone who no<br=
 />&gt; longer actively contributes to the project is more likely to be una=
ware<br />&gt; of how the code actually works today, even if they are famil=
iar with<br />&gt; components that change infrequently.<br /><br />This is =
not incorrect to say that "old parts" get changed, though the frequency<br =
/>is far from being exceptional and the substantial changes are pretty rare=
. If you<br />take few iconic files and you run stats (all no merges):<br /=
>- net_processing.cpp, initial file creation 2016, number of commits 926, i=
n average 115 changes yearly<br />- validation.cpp, initial file creation 2=
016, number of commits 1075, in average 134 changes yearly<br />- scheduler=
.cpp, initial file creation 2015, number of commits 47, in average 5 change=
s yearly<br />- interpreter.cpp, initial file creation 2014, number of comm=
its 145, in average 14 changes yearly<br /><br />One can certainly run more=
 line code stats diff changes at each year point to get a<br />granularity =
how much substantial changes they are and if they are any trend like<br />s=
ubsystem being more stable than other.<br /><br />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<br />#13413, #16175 and #18963). And what of s=
ubstantial abstraction have been introduced in the past years<br />in valid=
ation ? Package support and a lot of block-relay mitigations and cleanup, n=
ot something like crazy.<br /><br />Consensus and its interfaces has by far=
 has a rythm of upgrades more slow, for an ecosystem impact<br />de-multipl=
ied in case of issues (and it's harder to evaluate they might have "horizon=
tal" effect on<br />use-cases like timelocks). Like I was saying evaluating=
 who is active on single-digit years timelines<br />(and more probably 2 th=
an 9) is short-sighted, and this does not match practical experiences in ot=
her<br />top open-source codebases like linux kernel.<br /><br />There is n=
ot only a necessity to be aware of how the code actually works today, thoug=
h also the<br />undocumented or unforseen scope of things like past attacks=
 vectors or plausible past misinteractions.<br /><br />I think this somethi=
ng that Peter full disclosure illustrates well as more "junior" security li=
st recipients,<br />whatever their competency and goodwill, have failed to =
point out a type of class of attack that have come<br />again and again in =
discussions about mempool rebroadcast years ago (see the PR link I was poin=
ting out in<br />one my Dave answer above).<br /><br />&gt; Not being on th=
e list does not preclude him from being consulted if the<br />&gt; need ari=
ses.<br /><br />"If the need arises" supposes a lot, as first it assumes th=
e report timeframes give you leeway to come as more<br />or less group deci=
sion to share the sensitive information to someone like Peter, being a defa=
ult recipient<br />it's always faster (one might have to deal with situatio=
ns where the security flaw is already half-mentioned<br />in public and it'=
s better to act fast).<br /><br />Secondly, "if the need arises" is a techn=
ical judgement in itself. One worst-case scenario could be for all<br />the=
 default recipients reading a no-spam report, though missing an angle of ex=
posure or that actually it's<br />a serious attack vector. It did happen to=
 me on the lightning side in the past as I pointed out the general<br />vul=
nerability and someone cc after comes up with novel observations that were =
worsening the issues, or any<br />hardening fix of it.<br /><br />&gt; With=
 the two examples you provide, I am not aware of Peter being<br />&gt; acti=
vely involved in the resolution of both of those, whereas there are<br />&g=
t; current members of the list who were.<br /><br />They were given as exam=
ples of situations where you prefer to have too much competent and responsi=
ble<br />security list recipient that far too less, as both have temporal c=
ontengencies far beyond the scope of<br />bitcoin core list to deal with th=
em (the first as the DB-switch provoked fork was already happenin, the<br /=
>second as the report was from a bitcoin core fork coin).<br /><br />On the=
 list of people being actively involved in the resolution of them, or who g=
ot privileged access<br />to information before disclosure, from my experie=
nce they're some names that I must say can be a bit<br />sloppy in terms of=
 reactiveness and implications in security issues resolution (whatever the =
independent<br />fact they're very skilled bitcoin engineers and pretty goo=
d reviewers).<br /><br />&gt; In general though, it is not clear to me how =
it was beneficial to have<br />&gt; Peter on the security list, nor how not=
 having him is directly harmful.<br />&gt; In the 2 years that I have been =
on the security list, I was unaware that<br />&gt; Peter was a recipient un=
til shortly before he was removed. My<br />&gt; understanding is that other=
s who have been on the list longer than me<br />&gt; were also unaware.<br =
/><br />Personally, I think Peter has still one of the most furnished track=
 records in bugs findings around the mempool<br />(the segwit malleability =
PR #8312) and understanding of all timelocks issues with the authorship of =
bip65, which<br />is critical for contract protocols. That one disagrees wi=
th another security list member on its public technical<br />opinions for n=
ewer changes, I think it's something one has to abstract when all security =
issues handlers are coming<br />together to bring a mitigation to the issue=
.<br /><br />That one can be too much "cowboy" in matters of timelines full=
 disclosure, which I think have been a bit about the<br />last 3 "free rela=
y" disclosure, the best you can do is say so either publicly, or privately =
in all courtesy. No way<br />to make progress on responsible disclosure sta=
ndards, if no one never speaks up.<br /><br />I was aware that Peter was on=
 the list from conversations years ago with him on a reported issue, far be=
fore<br />all the present topics about V3 / TRUC / RBFR have been raised. I=
n my understanding, the fact that you were unaware<br />that Peter was on t=
he list can only reinforce impression had a very slow pace in terms of secu=
rity issues fixing,<br />especially when it's coupled with the disclosure o=
f all issues of past months with which you have been involved.<br /><br />M=
y number one recommendation would be to make the list of default security l=
ist recipient public, as it would<br />create more personal accountability =
(both internally among the list recipient and externally towards the securi=
ty<br />issues reporters / the wider community) and you can have a key fing=
erprint for each one which is good in terms of process.<br /><br />I certai=
nly don't wish to pour the blame on anyone specifically, as I think the cur=
rent "so-so" state of security<br />issues handling by bitcoin core has bee=
n more a background result of all the ups and downs of blocksize wars time,=
<br />where contributors didn't focus on it sufficiently. Yet, I think it's=
 very beneficial to think more about this process,<br />before we see eithe=
r more funds at stake with contract protocols and other applications (as it=
 was well pointed out by one<br />of the optech newsletter and sadly too kn=
own by lightning protocol devs, what can be a medium severity on the base l=
ayer<br />like transaction-relay censorship vector is very likely a high se=
verity on upper layer).<br /><br />Best,<br />Antoine<br />ots hash: b8b4ce=
2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736<br /><br /><div =
class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le dimanche 21=
 juillet 2024 =C3=A0 21:49:10 UTC+1, Ava Chow a =C3=A9crit=C2=A0:<br/></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On 07/20/2024 10:06 PM=
, Antoine Riard wrote:
<br>&gt; &quot;Naive&quot;, as saying this is the _Bitcoin Core_ project li=
st only can only=20
<br>&gt; provoke blind
<br>&gt; spot among the list members if the security issues are either affe=
cting=20
<br>&gt; old part of
<br>&gt; the codebases that younger members have less experiences with (som=
e=20
<br>&gt; parts like consensus
<br>&gt; or block-relay are modified only every 5 years) or novel factors f=
rom=20
<br>&gt; upstream or downstream
<br>&gt; (e.g the internet networking stack or implications on deployed con=
tract=20
<br>&gt; protocols like
<br>&gt; lightning). On both the former and latter criterias, I think Peter=
=20
<br>&gt; overly meets the bar.
<br>
<br>Peter was not the only &quot;senior&quot; person on the security list. =
Obviously I=20
<br>will not disclose non-public information, but certainly there are peopl=
e=20
<br>on the security list who are just as, if not more, senior than Peter.
<br>
<br>Furthermore, the &quot;old parts&quot; still do get changed, and someon=
e who no=20
<br>longer actively contributes to the project is more likely to be unaware=
=20
<br>of how the code actually works today, even if they are familiar with=20
<br>components that change infrequently.
<br>
<br>&gt; When you&#39;ve big sh*t hitting the fan like inflation bugs or le=
vel DB=20
<br>&gt; 2013 unexpected fork you
<br>&gt; prefer have experts with a decade of experience to collaborate wit=
h, and=20
<br>&gt; sharing the same cultural
<br>&gt; and ethical norms of the active contributors evaluated by numbers =
on=20
<br>&gt; commits on the last single-digit
<br>&gt; years.
<br>
<br>Not being on the list does not preclude him from being consulted if the=
=20
<br>need arises.
<br>
<br>With the two examples you provide, I am not aware of Peter being=20
<br>actively involved in the resolution of both of those, whereas there are=
=20
<br>current members of the list who were.
<br>
<br>
<br>In general though, it is not clear to me how it was beneficial to have=
=20
<br>Peter on the security list, nor how not having him is directly harmful.=
=20
<br>In the 2 years that I have been on the security list, I was unaware tha=
t=20
<br>Peter was a recipient until shortly before he was removed. My=20
<br>understanding is that others who have been on the list longer than me=
=20
<br>were also unaware.
<br>
<br>Ava
<br>
<br>&gt;=20
<br>&gt; I&#39;ll repropose Peter admission on the security list mailing li=
st in the=20
<br>&gt; coming weeks by opening an
<br>&gt; issue on the bitcoin-meta repository, once this current mailing li=
st=20
<br>&gt; thread has slowed down a bit,
<br>&gt; or at least the technical analysis has been dissociated from the=
=20
<br>&gt; proceedings which have all been
<br>&gt; bundle in a big message. In my very personal opinion, I still trus=
t more=20
<br>&gt; Peter competence and experience
<br>&gt; than some other people I know who are on the security mailing list=
.
<br>&gt;=20
<br>&gt; All that said I appreciate your answer and I&#39;m satisfied from =
the=20
<br>&gt; personal role you&#39;ve have played
<br>&gt; in the matter with, and be reassured I&#39;ll keep you among the r=
ecipient=20
<br>&gt; of future security issues with
<br>&gt; a potential impact on bitcoin core that I might find or be aware o=
ff.
<br>&gt;=20
<br>&gt; Best,
<br>&gt; Antoine
<br>&gt; ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd8=
67ccdd54
<br>&gt;=20
<br>&gt; Le samedi 20 juillet 2024 =C3=A0 01:50:25 UTC+1, Ava Chow a =C3=A9=
crit=C2=A0:
<br>&gt;=20
<br>&gt;     On 07/19/2024 07:58 PM, Antoine Riard wrote:
<br>&gt;      &gt; As said in one my previous email, I&#39;m still curious =
about achow101
<br>&gt;      &gt; explaining publicly
<br>&gt;      &gt; why you have been kicked-out of the bitcoin-security mai=
ling
<br>&gt;     list, when
<br>&gt;      &gt; you were certainly
<br>&gt;      &gt; more senior than achow101 in matters of base-layer secur=
ity
<br>&gt;     issues or
<br>&gt;      &gt; even hard technical
<br>&gt;      &gt; issues like consensus interactions (e.g bip65). I&#39;ll=
 re-iterate my
<br>&gt;      &gt; respect towards achow101
<br>&gt;      &gt; as a maintainer from years of collaboration, though this=
 is a topic
<br>&gt;      &gt; worthy of an answer.
<br>&gt;=20
<br>&gt;     I am not the one that removed Peter from the mailing list, nor=
 do I
<br>&gt;     even
<br>&gt;     have the login(s) to do so.
<br>&gt;=20
<br>&gt;     There was a discussion amongst several members of the security=
 list
<br>&gt;     about who was on the list, and who should be on the list. Give=
n that
<br>&gt;     the
<br>&gt;     security list is the _Bitcoin Core_ security list, we determin=
ed that
<br>&gt;     the people who should be on the list are people who still acti=
vely
<br>&gt;     contribute to the project. As Peter Todd no longer actively co=
ntribute
<br>&gt;     code nor code review to the project, we decided that it didn&#=
39;t make
<br>&gt;     sense to continue to have him on the list.
<br>&gt;=20
<br>&gt;     My recollection is that multiple other people were removed fro=
m the
<br>&gt;     list
<br>&gt;     for the same reason at the same time.
<br>&gt;=20
<br>&gt;     Ava
<br>&gt;=20
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google=
=20
<br>&gt; Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send=20
<br>&gt; an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+=
...@googlegroups.com</a>=20
<br>&gt; &lt;mailto:<a href data-email-masked rel=3D"nofollow">bitcoindev+.=
..@googlegroups.com</a>&gt;.
<br>&gt; To view this discussion on the web visit=20
<br>&gt; <a href=3D"https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-a=
e72-4aef-9fda-49e2f7c657abn%40googlegroups.com" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3D=
https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7=
c657abn%2540googlegroups.com&amp;source=3Dgmail&amp;ust=3D1721867630253000&=
amp;usg=3DAOvVaw2yLjkpeXTiukWLJ0nyOE6M">https://groups.google.com/d/msgid/b=
itcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com</a> &lt;=
<a href=3D"https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-=
9fda-49e2f7c657abn%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoin=
dev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%2540googlegroups.com?utm_medium%3=
Demail%26utm_source%3Dfooter&amp;source=3Dgmail&amp;ust=3D1721867630254000&=
amp;usg=3DAOvVaw0EUwpgDv5mqD6_KK45IBvJ">https://groups.google.com/d/msgid/b=
itcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medi=
um=3Demail&amp;utm_source=3Dfooter</a>&gt;.
<br>
<br></blockquote></div>

<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/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com</a>.=
<br />

------=_Part_1127251_1705006231.1721781359047--

------=_Part_1127250_1171932923.1721781359047--