Feature Request: testmempoolaccept with an argument to ignore nLocktime/nSequence time-locking #32142

1. 
   oren-z0 commented at 11:07 pm on March 25, 2025: none

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

   Execute testmempoolaccept in a way that will ignore the time/block-height validations of the transactions’ nSequence and nLocktime.

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

   testmempoolaccept is a very useful tool to verify transactions that aren’t supposed to be broadcasted immediately - for example, for emergency recovery in case the seed is lost. nLocktime is also useful in such case, to prevent the recovery transaction from being broadcasted too early. However, after signing a transaction with a future nLocktime, I couldn’t be sure that it is indeed valid: testmempoolaccept considers this transaction as non-final because of its future nLocktime, without explaining whether it has other problems (i.e. invalid signatures etc.).

   Describe the solution you’d like

   A third optional parameter to testmempoolaccept (after rawtxs and maxfeerate) called ignoretimelocks, that will be a boolean.

   Describe any alternatives you’ve considered

   I’ve tried writing code that would parse the transaction and, given the current mempool utxos, verify its scripts. This becomes complicated to implement in multisig and segwit transactions, and doesn’t give me the guarantees that I want for such long-term transaction.

   Another suggestion is that testmempoolaccept will accumulate all the reasons a transaction is unacceptable, and not exit after the first reason.

   Please leave any additional context

   nSequence is a bitfield with multiple purposes, like RBF, and possibly other features in the future. My suggestion only regards BIP-68 validations of nSequence and not other features.

2. oren-z0 added the label Feature on Mar 25, 2025
3. maflcko added the label RPC/REST/ZMQ on Mar 26, 2025
4. maflcko added the label Mempool on Mar 26, 2025
5. 
   darosior commented at 8:02 pm on March 26, 2025: member

   Have you seen the discussion about this at #25434?
6. 
   oren-z0 commented at 10:15 am on March 27, 2025: none

   Thanks @darosior , no I did not see that discussion before (only searched for related issues, not related PRs). In the other discussion, the main use case for the feature is to simplify the development of L2 layers - which use scripts with pre-known structure. In my use case, I’m building a service that could broadcast future recovery-transactions uploaded by customers, and I want to verify in advance that these transactions could indeed be broadcasted when the time comes (unless, of course, the customer has spent the UTXOs after uploading the recovery-transactions). In this case the transaction could theoretically use any script that the customer wants.

   I understand the worry that the code of testmempoolaccept will diverge from the code of sendrawtransaction and some bug will cause an invalid transaction to appear as accepted by testmempoolaccept. A more generic alternative could be that testmempoolaccept will collect all the reasons a transaction appears to be invalid, without breaking on the first reason (unless this is a very basic failure like invalid transaction structure, that make the other verifications irrelevant).

   Therefore I would like to keep this issue open for debate.

Contributors
oren-z0 darosior

Labels
Feature RPC/REST/ZMQ Mempool