mempoolfullrbf=159.0%
mempoolfullrbf=019.7%
I don't run a node6.6%
What?14.8%
61 votes \ poll ended
related

Fullrbf should just be called "reality", because that is what it is. Breaking the delusion that you cannot double spend on the mempool.

"the delusion that you cannot double spend on the mempool."

Strawman

64 sats \ 4 replies \ @gd 24 Nov

It has always been the case that transactions are not final until multiple confs. The protocol never gives any assurances of confirmation for any transaction in the mempool. Relying on 0conf will also expose you to purge risk, like we saw last week.

For example, f2pool mined two full-rbf double spends earlier today. I don't think they're running with mempoolfullrbf enabled. I think they just restarted a node or something similar and cleared their mempool.

Is there a setting in Bitcoin Core itself to log such events, especially double spends with different destinations?

Other than transactions relevant to your wallet, no. Bitcoin Core doesn't need that information for normal operation as double spends of mempool transactions are perfectly normal.

This is how you say it without the strawman.

My node, my policy.

If you disagree, keep the first seen policy.

Non sequitur, but anyway.

Cool! Do your thing.

I run 22.0

I also run 22 and probably will for a while just to make sure the new version doesn't hard fork with the old version for a year or two, but I'll probably upgrade to version 24 when version 28 comes out.

To continue running an older version with the full rbf flag tho, I've started running Bitcoin Knots version 23.

I actually run two v0.17 nodes, because I haven't bothered to upgrade my OpenTimestamps server software to support new Bitcoin Core versions.

Which is fine! The great thing about Bitcoin is we do backwards compatible soft forks, not hard forks.

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.

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.

101 sats \ 0 replies \ @Lumor 24 Nov

Happy to have the option but no rush.

Quite surprised that 6.5% of users on SN don't run nodes.

What are you doing with your life? RUN A NODE

20 sats \ 0 replies \ @cozy 24 Nov

I read some tweet that it's paternalistic (read: coercive). Dude, I don't think you know what coercion means if you think this voluntary software offering and option to default to helping protect you is coercive.

I'll turn it on, but one shouldn't rely on unconfirmed transactions anyway. It's like not wearing a seatbelt when driving a car. Full-RBF, is the seatbelt. I can see times where this is necessary if you're 007 or something and need to lean out the fire a gun (not show how this metaphor translates to Bitcoin anymore, lol), but wearing a seatbelt will save you in real life, if not from yourself, definitely from other drivers.

I have opinions about this as many of you know. But I'm curious what stacker.news readers will answer without prompting. :)

mempoolfullrbf=1 gang rise up

Based on the comments it seems like a summary of pros/cons would be helpful. For example I thought it's only miner mempools that really matter in this case

I'm working on a blog post.

Until I read that post I'm agnostic and will therefore use the default which is =0 I believe

"mempoolfullrbf=0" and "what?" have the same percentage. Great. That's exactly why there's this delusion anyway.