public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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