357 sats \ 2 replies \ @BTCNautilus 24 Nov 2022 \ on: Are you going to run full-rbf? bitcoin
I know there has been a lot of noise about this issue, but in terms of my self interest, my nodes will continue doing whatever is currently default.
When I do update, the full rbf flag will have no bearing on any of the use cases my nodes are used for. So, I won’t bother one way or the other. I imagine most node runners will be like me.
most node runners will be like me.
Fortunately, it doesn't require every node to run FULLRBF, ... and not even a majority of them is needed.
If my node connects to eight peers, I would only need one of those eight peers to run FULLRBF, which would then relay my replacement transaction to that node's eight peers (or whatever number of peers that node connects to). So somewhere between 12.5% and oh ... maybe I'ld guess 25% of nodes running FULLRBF are nearly as good as 100% of nodes running FULLRBF. My replacement transaction is then very likely to get relayed time and again and it becomes very likely that eventually it will reach a miner that runs FULLRBF.
Now whether miners are actually running FULLRBF (or planning on it) remains to be seen. I would think the miners and pools running FULLRBF will be well connected with the intent to miss as few replacement transactions as they can (to maximize revenue), but I've no idea how welcome FULLRBF is by miners. I would assume they are nearly all for it though.
reply
So suppose that there are N potential outgoing peers in total, M of which run full-rbf. That means the probability of any one peer not running full-rbf is (1-M/N), so the probability of all 8 peers not being full-rbf is (1-M/N)⁸
There are approximately 5000 IPv4 listening nodes. So for 50% probability of connecting to at least one full-rbf node, you need 415 full-rbf nodes, or 8.3%. For 95% probability, you need 1561 full-rbf nodes, or 31%
Of course, if you are running a listening node third-parties can ensure full-rbf replacements get to you by just connecting to a high % of the entire network. With just a few thousand public listening nodes, that's entirely feasible.
Also, if those odds aren't good enough for you, you can also just run the preferential peering patch: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0
It advertises a FULLRBF service bit, and ensures that you have at least 4 connections to other full-rbf nodes.
reply