pull down to refresh
0 sats \ 4 replies \ @nerd2ninja 1 Jun 2023 \ on: Peter Todd releases Full-RBF Peering with Bitcoin Core v25.0 bitcoin
There are concerns I'm sure Peter is aware of with running this. If fullrbf nodes are sparse, it becomes easy for a single attacker to spin up a bunch of nodes and sybil attack the full rbf nodes that are out there.
I'll probably switch clients when receiving Bitcoin for this reason, but I might just accept risk on that idle but verifying time.
Sybil attacks aren't as easy as you probably think they are. Since nodes always make outgoing connections to diverse IP address space, to Sybil attack any node you need to run enough nodes that the entire IP address space is Sybil attacked. That's really difficult as getting access to that much IP address space is really difficult. It's also a risk that isn't related to full-rbf peering: any node has this risk. In fact, arguably full-rbf peering slightly reduces that risk as by default it connects to 14 outgoing peers rather than 10.
Now, if you run full-rbf peering and accept incoming connections you advertise that fact and maybe someone might do DoS attacks against you. But DoS attacks can't make you lose coins (with the one exception of certain Lightning setups).
Anyway, tl;dr: running a full-rbf peering node is having a small amount of bravery. We need people to be brave for society to work. Hell, running the first Bitcoin nodes required a bit of bravery.
Be brave.
reply
I'm brave Peter I'm brave! I also try my best to identify a full risk assessment before deciding to accept risk, and there are risks that people accept all the time. The problem is that most people accept risk without knowing what the risks are, but a fully informed person who can accept appropriate risk is much better protected.
Anyway, thanks for the information!
reply
That's a reasonable way to do it. :)
reply
✊
reply