Consider not enabling RBF by default

[thunderbiscuit]

I know I know 🤣🤣 we just merged this.

But our timing for this PR (the one that made RBF signalling by default) was in a way quite late to the game. Bitcoin Core 0.28 now ships with full transaction replacement regardless of the RBF flag. This on its own doesn't really change anything for us, but after speaking with Murch on the Optech live podcast, his take on the RBF signalling is that in time, signalling for RBF will actually fingerprint your wallet (because only few libraries will do that by default).

This is not really a pressing issue, but it's good to get the conversation going early. Over time if all transactions can always be RBF-ed and the ratio of RBF-signalling transaction keeps going down, it would probably make sense to revert the default to not signalling for RBF.

BTW does anyone know if there is an easy place to find data on this? Like the ratio of transactions that signal for RBF over a given period of time? I wonder what's the proportion of tx in 2024 that do signal for it.

[thunderbiscuit]

Also related to this discussion (probably warrants a separate issue?) is how the new rules impact the bump fee transaction builder. I'm not sure if the current builder requires a transaction signals for RBF to then be used by the replace by fee txbuilder?

[notmandatory]

This is a good suggestions let's evaluate doing this for the 2.0 milestone.

[thunderbiscuit]

I have found the data for RBF-signalling: https://transactionfee.info/charts/transactions-signaling-explicit-rbf/.

Currently around 70% of transactions signal RBF.

[ValuedMammal]

A little surprised to see the comparatively low figures for absolute locktime https://transactionfee.info/charts/transactions-height-based-locktime/, notice the sharp decline after 2023

[luisschwab]

Also related to this discussion (probably warrants a separate issue?) is how the new rules impact the bump fee transaction builder. I'm not sure if the current builder requires a transaction signals for RBF to then be used by the replace by fee txbuilder?

This is on the docs for build_fee_bump():

Bump the fee of a transaction previously created with this wallet.
Returns an error if the transaction is already confirmed or doesn’t explicitly signal replace by fee (RBF). If the transaction can be fee bumped then it returns a TxBuilder pre-populated with the inputs and outputs of the original transaction.

My rationale is that it should fail, because the user explicitly changed n_sequence.