Quote from: Abbatty on May 27, 2025, 08:09:11 AM

I've been trying to understand Bitcoin better, and I've got some questions about nLockTime and RBF. From my understanding, nLockTime is like a delay timer for transactions, and miners can't confirm them until the set time is reached. RBF lets you replace an unconfirmed transaction with a new one that has a higher fee. Also I understand that transaction with nLock time set can be replaced by a new transaction with RBF feature so far the set time is not yet reached and has a higher fee. I'm okay with that but I have two questions:

1. Can a transaction with nLockTime be replaced with a new one that has a different nLockTime value? What happens if it gets replaced?
2. If a transaction with nLockTime is stuck in the mempool because of low fees, can I use RBF to replace it with a new transaction that has a higher fee?

Hope someone can help clarify this better for me here.

Already asked this in my local board but got a few replies so I thought I ask here for more explanation and understanding.

1. Can a transaction with nLockTime be replaced by a new one that has a different nLockTime value? What happens if it gets replaced?

Yes, a transaction with an nLockTime can be replaced by another transaction via RBF, even if the replacement has a different nLockTime value—as long as the replacement transaction follows RBF rules:

It must spend the same inputs.

It must pay a higher fee.

It must be valid according to consensus rules, including the new nLockTime.

Effectively:
If the original transaction had an nLockTime set in the future, but you replace it with a transaction that has an earlier nLockTime (or even no nLockTime), miners can include the replacement immediately, speeding confirmation.

On the other hand, if the replacement has a later nLockTime, it will still only be valid after that time is reached, so confirmation will be delayed accordingly.

Summary: RBF replacement overwrites the old transaction in the mempool with the new one, and miners treat the new nLockTime as the rule for when to confirm.

2. If a transaction with nLockTime is stuck in the mempool due to low fees, can I use RBF to replace it with a new transaction that has a higher fee?

Absolutely. That’s exactly one of the main use cases of RBF.

If your transaction is stuck because the fee is too low, and it has an nLockTime set that allows immediate or near-future inclusion (meaning the nLockTime has already passed or will soon pass), you can broadcast a replacement transaction:

Using the same inputs.

With a higher fee.

Possibly with the same or updated nLockTime.

Miners will then prioritize the new transaction over the old one, helping your payment confirm faster.

However, if the nLockTime has not yet been reached, neither the original nor the replacement can be mined until the locktime condition is met. So you can replace the transaction to increase the fee, but miners will still wait for nLockTime to pass before confirming.