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:35:59 -0700 (PDT) [thread overview]
Message-ID: <f9d17558-4b74-401b-bb64-fed34bd46619n@googlegroups.com> (raw)
In-Reply-To: <a8eac5f2-b85a-434f-868e-eba7fd2558c6@achow101.com>
[-- Attachment #1.1: Type: text/plain, Size: 14217 bytes --]
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
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
protocol development, and who an equivalent track records in matters of
adversarial
exploitation, consensus changes and use-cases protocol design (as one 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 think 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.
> 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
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, in
average 115 changes yearly
- validation.cpp, initial file creation 2016, number of commits 1075, in
average 134 changes yearly
- scheduler.cpp, initial file creation 2015, number of commits 47, in
average 5 changes yearly
- interpreter.cpp, initial file creation 2014, number of commits 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
subsystem being more stable than other.
Validation and net processing are obviously beefy files ongoing regular
changes (as there has never
been a patchset landing successs of the many attempts from many authors to
break them further like
#13413, #16175 and #18963). And what of substantial abstraction have been
introduced in the past years
in validation ? Package support and a lot of block-relay mitigations and
cleanup, not something like crazy.
Consensus and its interfaces has by far has a rythm of upgrades more slow,
for an ecosystem impact
de-multiplied in case of issues (and it's harder to evaluate they might
have "horizontal" effect on
use-cases like timelocks). Like I was saying evaluating who is active on
single-digit years timelines
(and more probably 2 than 9) is short-sighted, and this does not match
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
today, though also the
undocumented or unforseen scope of things like past attacks vectors or
plausible past misinteractions.
I think this something that Peter full disclosure illustrates well as more
"junior" security list 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 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
timeframes give you leeway to come as more
or less group decision to share the sensitive information to someone like
Peter, being a default recipient
it's always faster (one might have to deal with situations where the
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
worst-case scenario could be for all
the default recipients reading a no-spam report, though missing an angle of
exposure 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
vulnerability 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
> 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
competent and responsible
security list recipient that far too less, as both have temporal
contengencies far beyond the scope of
bitcoin core list to deal with them (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 got privileged access
to information before disclosure, from my experience 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 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
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 with another
security list member on its public technical
opinions for newer 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 relay" disclosure, the best you can do is say so either
publicly, or privately in all courtesy. No way
to make progress on responsible disclosure standards, 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 before
all the present topics about V3 / TRUC / RBFR have been raised. In my
understanding, the fact that you were unaware
that Peter was on the list can only reinforce impression had a very slow
pace in terms of security issues fixing,
especially when it's coupled with the disclosure of all issues of past
months with which you have been involved.
My number one recommendation would be to make the list of default security
list recipient public, as it would
create more personal accountability (both internally among the list
recipient and externally towards the security
issues reporters / the wider community) and you can have a key fingerprint
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
the current "so-so" state of security
issues handling by bitcoin core has been 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 either 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 known by lightning protocol devs,
what can be a medium severity on the base layer
like transaction-relay censorship vector is very likely a high severity on
upper layer).
Best,
Antoine
ots hash: b8b4ce2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736
Le dimanche 21 juillet 2024 à 21:49:10 UTC+1, Ava Chow a écrit :
> On 07/20/2024 10:06 PM, Antoine Riard wrote:
> > "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.
>
> 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.
>
> 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.
>
> > 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.
>
> Not being on the list does not preclude him from being consulted if the
> need arises.
>
> 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.
>
>
> 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.
>
> Ava
>
> >
> > 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+...@googlegroups•com
> > <mailto:bitcoindev+...@googlegroups•com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>
--
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/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16769 bytes --]
next prev parent reply other threads:[~2024-07-24 0:43 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
2024-07-24 0:35 ` Antoine Riard [this message]
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=f9d17558-4b74-401b-bb64-fed34bd46619n@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