On Tue, Dec 06, 2022 at 12:39:40AM -0500, Peter Todd via bitcoin-dev wrote: > 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by > default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes > on > the network. When a node learns of a new block, it tells all it's peers that > the new block exists. > > For your censorship to work, there has to be a substantial propability that a > miner *only* runs a single node (they don't), that has no incoming peers, and > all 8 peers of that node happen to be one of your 20 censoring nodes. > Obviously, since the probability of a given peer being a censoring node is > 20/5000, all 8 being censored is extraordinarily unlikely. > > Even if you ran so many nodes that 20% of the entire network was censoring, > the > probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256% > > > This is an example of information being hard to censor and easy to spread. In > fact, for full-rbf this same math works in our favor: for a node to have a 50% > chance of connecting to at least one full-rbf peer, just 8.3% of the network > needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes. > > The percolation threshold doesn't need to be met for this to be succesful, > because someone to just run a full-rbf node that connects to every single > listening node simultaneously.
FYI here's a percolation simulator for full-rbf: https://github.com/mzumsande/fullrbf_simulation It finds similar results to my math above. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
