Make RPC nLocktime uniform across all PSBT creation pathways #34987

Please describe the feature you'd like to see added.

Currently the nLocktime default is set to the current height with a 10% chance to be spread back up to 100 blocks, but only in the send RPC command or GUI wallet flow. Other ways to create a tx like createrawtransaction or walletcreatefundedpsbt default to 0 instead of the anti-fee sniping default. I understand these are more complex user flows but it seems like bitcoin core should be uniform in its default here. Either be opinionated about anti-fee sniping or not.

Is your feature related to a problem, if so please describe it.

Seems like there could be some wallet fingerprint leaks if a tx set uses currentHeight nLocktimes unless the tx has any additional level of complexity and only then uses a 0 nLocktime indicating that a user created a tx using something other than send. Though realistically this seems like a weak link and ultimately I think wallet uniformity is enough of a reason for this change.

Describe the solution you'd like

I think that the rpc commands createrawtransaction and walletcreatefundedpsbt should both default to use anti-fee sniping nLocktimes to make them uniform with the send command.

Describe any alternatives you've considered

No response

Please leave any additional context

Its possible I have missed a more fundamental reason why these were not included but in the initial creation #2340 the comment

Set nLockTime on wallet transactions (only, no RPC changes)

Does not give any context or explanation to why they were not also included though this was a very long time ago so maybe there are some additional wallet architecture changes that happened in between then and now.

Was there any reason why createrawtransaction or walletcreatefundedpsbt do not use anti-fee sniping already?

I think that is the primary question I would like clarity on before there is any movement to submit a PR to unify them all

Adding to this, if there is a PR to change the behavior for the other RPC commands regarding nLockTime, I would very much appreciate it if it includes named arguments to all of the RPC commands to override the automatic nLockTime behavior. Primarily because it would be much easier to avoid nLockTime-related privacy leaks if you could control it without fiddling with createrawtransaction or similar.

I guess it may be fine to try to set it more broadly. According to https://mainnet.observer/charts/transactions-height-based-locktime/ the usage is declining, which reduces the privacy anonymity set. So trying to counter seems worthwhile.

However, when expanding it, it could make sense to think how to avoid https://mainnet.observer/charts/transactions-not-enforced-locktime/ from going up, because unenforced locktimes will likely always be rare and using them will likely provide a tiny anonymity set, or no at all.

So I think the question to answer is: Are there any transactions that will be off worse with the anti-sniping applied more broadly?

if a tx set uses currentHeight nLocktimes unless the tx has any additional level of complexity and only then uses a 0 nLocktime indicating that a user created a tx using something other than send

I agree this can leak information about how the transaction was created. However, as I'm understanding it, for that to happend it would be first needed to detect that the transaction comes from core (as the anti fee sniping is only active in core and electrum). Only then the locktime can leak information about the trasnaction was created.

Are there any transactions that will be off worse with the anti-sniping applied more broadly?

If we were to use anti-fee sniping more broadly it would come at a cost. As explained in the pr #34480 and the issue #26527 when we backdate the locktime, it makes the trasnaction susceptible to wallet fingerprinting since only core and electrum do that. This does not happen very often, but it must be cconsidered.

I think we should discuss if it is better to have the fingerpriting problem with backdating the locktime in more transactions, or leak infomration about if the trasnaction was created with the send method or not. Personally, I belive it is better to have the backdating-locktime problem so I agree to use more broadly the anti-fee sniping.

Just to keep this issue on topic let's try to keep discussion about the usefulness of anti-fee-sniping and the intricacies of improving it in a separate issue. This issue should really just be simply focused on making the RPC calls consistent across the API.

The difference with send and the other RPC calls you mention is that send does actually create and broadcast the transaction at the moment, so the anti-fee sniping makes sense.

In the other cases the user or the software using the RPC should set the locktime to the height they want in case they want to use anti-fee snipping. Because the time of the creation of the transaction is likely not going to be the broadcast time.

Regarding privacy, if we set anti-fee sniping for other transactions than just the ones created with send they will be easily finger-printable as Core Wallet transactions because it would be the only wallet setting the anti-fee sniping for those.