Make RPC nLocktime uniform across all PSBT creation pathways #34987

1. 
   benalleng commented at 4:25 pm on April 1, 2026: none

   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.

2. benalleng added the label Feature on Apr 1, 2026
3. 
   chriszeng1010 commented at 8:26 pm on April 1, 2026: none

   Was there any reason why createrawtransaction or walletcreatefundedpsbt do not use anti-fee sniping already?
4. 
   benalleng commented at 4:58 pm on April 2, 2026: none

   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
5. 
   ArmchairCryptologist commented at 8:58 am on April 4, 2026: none

   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.
6. HouseOfHufflepuff referenced this in commit 511daa9e7d on Apr 6, 2026
7. HouseOfHufflepuff referenced this in commit 11fdec6357 on Apr 8, 2026
8. 
   maflcko commented at 10:07 am on April 10, 2026: member

   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?

Contributors
benalleng chriszeng1010 ArmchairCryptologist maflcko

Labels
Feature