From: "'Anonymous User' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.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: Sun, 21 Jul 2024 18:59:52 -0700 (PDT) [thread overview]
Message-ID: <3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com> (raw)
In-Reply-To: <a8eac5f2-b85a-434f-868e-eba7fd2558c6@achow101.com>
[-- Attachment #1.1: Type: text/plain, Size: 9456 bytes --]
I came from some twitter discussion so I think this thread is trending. I
think we need to figure a way out onward.
Here is a last resort solution by launching this attack in production. We
should avoid making this last resort solution, but from what Peter Todd
said, below seems completely practical.
Please treat it as story reading and do not overthink that this is the way
to go.
- a few people in the list form a group and fork bitcoin core and apply the
patch from Peter Todd
- work with a few miners to massively perform the free relay attacks and
other mempool related attacks in an effort to force mining pools and miners
to switch from bitcoin core into the fork in order for their nodes to
continue running in a healthy manner
- build a free service for file transfer or VPN taking advantage of rbf in
the Bitcoin network and make it a public good that millions of users can
use, causing most of the mempool transactions to be conflicting (due to
different implementations of rbf) and therefore wallets have to eventually
stop broadcasting transactions to bitcoin core nodes (which could be using
a completely new list of seed nodes, disabling the existing seed node
list), and non-bitcoin-core nodes, in order to have more healthy
transaction flows and mempool data sharing, would start node-shopping by
disconnecting themselves from bitcoin core nodes and refusing to be their
peers
- core is forced to find a way onward, or the core gives up and archives
the bitcoin core repo
The damage is probably just a few days of slower transaction processing,
much smaller than the price spike caused by ordinals last year.
Democracy starts with people having different opinions that DO NOT need to
reconcile. So, it is not about how we get different people in this mail
list, or the non-public security list, to achieve the same opinions, like
whether full RBF is needed. It is about how Bitcoin can allow two groups of
people that have fundamentally different opinions and are unwilling and
impossible to reconcile. We can have 5-10 security disclosure mail lists by
different groups of people, and good-faith vulnerability reporters can
choose to exclusively report the bugs to some groups that the reporters
feel to be knowledgeable and responsive and, importantly, have the capacity
and the motivation to work on it.
I feel bad for Peter Todd. If I were him, I wouldn't report the bug. I
would sell the bug because I got nothing in return, but probably more
jealousy or more retaliation for being the only person serious about an
issue.
Btw, Peter already has a fork.
Ethereum has great software development process as well as its ecosystem.
Smart contracts get heavily audited not because people care about security.
It is because North Korea has successfully stolen probably hundreds of
millions of dollars from different projects and even causing some projects
to fall apart. This is in essence similar to, if one day Bitcoin has a
memory exploit issue that causes a massive amount of miners to lose coins
that they own, and the network again needs to decide whether to do a hard
fork, that is the time when we will be discussing if stopping development
in C/C++ and limiting Bitcoin core development to Rust and Rust only are
the way forward.
Thanks,
Anonymous user, as the floppy disk guy recommends this might be the best
way to engage in the mailing list onward
I strongly encourage people to try engaging in this email list anonymously.
It feels great to say things out loud without worrying about retaliation on
unrelated matters. Also, this should be permitted. We still don't know who
Satoshi is. If I were Satoshi, I probably also wouldn't report a bug I
know.
On Sunday, July 21, 2024 at 1:49:10 PM UTC-7 Ava Chow wrote:
> 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/3f7d43bd-af9e-4af5-860a-223504bb4fcan%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11764 bytes --]
next prev parent reply other threads:[~2024-07-22 12:07 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 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 [this message]
2024-07-24 0:44 ` Antoine Riard
2024-08-01 5:57 ` Garlo Nicon
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-30 4:57 ` David A. Harding
2024-07-30 19:38 ` Peter Todd
2024-08-16 4:45 ` Antoine Riard
2024-08-16 4:20 ` 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=3f7d43bd-af9e-4af5-860a-223504bb4fcan@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=situo@berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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