Connect to nodes signaling full RBF about walletwasabi HOT 7 CLOSED

If the full-rbf network has been bootstrapped to the point where it propagates reasonably well the we could assume full-rbf transactions would reach us.

Problem is propagation probably works well because of people running my full-RBF peering forks. If you aren't running one of those forks, and especially if you aren't accepting incoming connections, propagation isn't so reliable.

That said, I think it's totally reasonable to skip doing any hacks like connecting to specific nodes and just accept that it won't work 100%

from walletwasabi.

It seems my memory was kidding me because by default Bitcoin Core nodes don't accept full-rbf transactions yet (the default value for -mempoolfullrbf is false and they don't signal support for it even if they support it.

This issue is then not possible. @kristapsk I would appreciate your comment here.

Note: all v3 transactions are considered replaceable but they are also not standard still (Wasabi uses v1 transactions)

from walletwasabi.

Yes, full RBF announcement is made only with @petertodd patch and also it can't be 100% trusted, any node can announce it, even with full RBF disabled.

Best solution to make sure you have connections to at least some full RBF peers is to addnode= such nodes in config.

Peter Todd maintains some list:

addnode=full-rbf1.btc.petertodd.net
addnode=full-rbf2.btc.petertodd.net
addnode=full-rbf3.btc.petertodd.net
addnode=full-rbf4.btc.petertodd.net

We could also try to build our own list. Note also that Peter doesn't provide .onion address.

from walletwasabi.

It doesn't work. The endpoints acknowledge and reset immediately.

$ tcpdump -i any port 8333 -n
16:04:12.163255 wlp4s0 Out IP 192.168.1.3.34481 > 91.231.182.136.8333: Flags [S], seq 333267214, win 64240, options [mss 1460,sackOK,TS val 16093440 ecr 0,nop,wscale 7], length 0
16:04:12.424788 wlp4s0 In  IP 91.231.182.136.8333 > 192.168.1.3.34481: Flags [R.], seq 0, ack 333267215, win 0, length 0

from walletwasabi.

Yes, it seems something is down there - full-rbf2.btc.petertodd.net disconnects immediatelly after connecting, to others I'm not even able to connect at all.

from walletwasabi.

Yes, full RBF announcement is made only with @petertodd patch and also it can't be 100% trusted, any node can announce it, even with full RBF disabled.

Best solution to make sure you have connections to at least some full RBF peers is to addnode= such nodes in config.

Peter Todd maintains some list:

addnode=full-rbf1.btc.petertodd.net
addnode=full-rbf2.btc.petertodd.net
addnode=full-rbf3.btc.petertodd.net
addnode=full-rbf4.btc.petertodd.net

We could also try to build our own list. Note also that Peter doesn't provide .onion address.

So all these nodes have been taken down, as full-RBF has been bootstrapped to the point where it propagates reasonably well and they were costing a decent amount to run every month.

I run the mainnet DNS seed, so I changed those domain names to all point to the mainnet DNS seed for nodes that advertise full-RBF. You should be able to reasonably reliably connect now with those addnodes (as you pointed out, service bits can be faked!). But if more people run full-RBF/Libre-Relay nodes that advertise the full-RBF service bit, that would help things. Wasabi also curating a list is a good idea too.

A better solution of course if for bitcoin/bitcoin#28132 to be merged. It's pretty silly for Bitcoin Core to have full-RBF disabled when ~80% of hash power mines full-RBF replacements.

from walletwasabi.

If the full-rbf network has been bootstrapped to the point where it propagates reasonably well the we could assume full-rbf transactions would reach us.

from walletwasabi.