The timelock can only be cancelled if when you are broadcasting the timelocked transaction (that is RBF-enabled!), you broadcast another transaction without the timelock and place a higher transaction fee on it.
The timelocked transaction cannot be broadcast until after the timelock has expired. You can invalidate it with a transaction paying a lower fee prior to this, since the rest of the network know nothing about the timelocked transaction. The original transaction also does not need to be RBF enabled, since again, the network knows nothing about it.As we all know very well, Bitcoin Layer 1 can send one-time payments, but recurring subscription payments are a bit of a thorn in the eye, because the Bitcoin protocol doesn't provide us with primitives for solving all of these things.
However, we do have locktime, so let's see how a Bitcoin wallet can emulate the recurring payments feature:
1. First, the wallet should come with a daemon or background program whose only function is to store signed transactions and attempt to broadcast them. That will free users from the necessity from leaving their wallet open 24/7.
2. When a service wants you to pay bitcoins, we currently have the bitcoin: URI, which encodes fields such as address, amount, and expiration date. New fields can be created: quantity= which dictates the number of payments, and interval= to describe the payment interval in days.
These fields can just be directly created and used immediately, since there is empirical evidence that shows that just deploying the stuff yourself (disappointingly) gets adoption much faster than trying to formalize it first (ZeroSync, Ark, Bitcoin transaction relay over Nostr, etc).
3. The wallet ensures that the UTXO set available in the wallet is enough to cover the fixed BTC costs over the specified time frame, and then signs a transaction for each payment, each one containing a UTXO from the previous transaction AND a locktime of the current block height plus (2016 - 100)*(interval/14) to prevent them from being spent all at once. This particular locktime also ensures that transactions can be broadcasted several hours before payday.
4. These transactions are then sent to the background program to be broadcasted in due time.
5. If you make a new transaction somewhere else using one of the UTXOs that are being used, the currently timelocked transactions are discarded and you have the option of lowering the recurring payment quantity, for any of your recurring payments (or even discarding them all together), in order to accommodate the new transaction, while a new set of recurring timelocked payments are created with the new time constraints and UTXO set.
So, I guess that really does it. Now let's see how long it takes for a wallet to pick up on this idea, as the infrastructure for handling this can easily be created server-side....