Closes #26526
Currently, in Bitcoin Core, given an original transaction A and its replacement B, we refer to backdating when the locktime of A is higher than the locktime of B (A.locktime > B.locktime). This can happen because Bitcoin Core enables anti-fee-sniping by default, which sets the transaction's locktime to the current block height. For privacy, 10% of the time, it instead sets a different locktime, randomly chosen between the current height and the current height minus 100 blocks. This can lead into having a replacement of a transaction with a locktime older than its original transaction. This is unrealistics and can be used as a wallet fingerprint.
You can find a functional test to reproduce the behaviour mentioned here
The approach proposed in this PR adds a new parameter to CoinControl to keep track of the previous locktime in the case of a bumpfee. We then pass this parameter to the DiscourageFeeSniping function through a new parameter, minimum_height, whose default value is set to 0.
<details> <summary>Alternative approach:</summary> Since the locktime of the new transaction is 0, we also considered setting it to the previous locktime value and then, inside `DiscourageFeeSniping`, saving the previous locktime and setting the transaction's locktime to the block height before applying any of the backdating logic. This way, we could avoid passing a new parameter to the function. We ultimately decided not to go with this approach, as it makes the code more difficult to follow. </details>
The only RPC that is affected by this changes is bumpfee.
The pr also includes a functional test in wallet_bumpfee.py to test that when replacing a transation using bumpfee the locktime is not backdated.
<details> <summary>We also conducted a small analysis to see how many the backdating in RBF transactions actually happen.</summary> We have data on the replaced transactions from 2025-05-01 to 2026-06-01. With that we have been able to detect this many backdatings: <img width="1782" height="891" alt="image" src="https://github.com/user-attachments/assets/1d2a83d5-aa61-4850-82e5-cb434b9ee958" />
We took the date of the last transaction of the replacement chain (A replacement chain are all the transactions that replace themselves)
In total we have over 1,000,000 rbf transactions, but we see that on average there are only about 200-300 hundred replaccements backdating per week. Looking at the percentages we see that on average is less than 2% of all the transactions that have been replaced.
So, it is clear that backdating in replacement transactions is unusual. However, the few transactions that do exhibit backdating are easily fingerprintable as having been replaced using bumpfee in Bitcoin Core or Electrum.
</details>
