Topic: Recurring payments in Bitcoin wallets using timelocked transactions. (Read 371 times)

Easy fix: use different inputs

Now that I think about it: you can just as well send small funded private keys on a monthly schedule to pay for your subscription.

The problem with this is that as soon as you change the fee, you change the TXID. And as soon as you change the TXID, any child transactions will no longer be valid. This means you cannot create a chain of timelocked transactions, since as soon as the fee changes on one, all the other ones being held to a future date will no longer be valid.

Instead there should be auto debit of the fees. Like when we broadcast the transaction it will include the fees along with it. Instead of that, a code should be written which will just withdraw the fees automatically from the "subwallet" or some other ways and then broadcast it automatically.

Since the transactions for future payments are timelocked but cannot be broadcasted yet, it is trivial to change the fee: just periodically recreate the recurring transaction chain every week or so, and the wallet software should be intelligent enough to get the current fee estimates for that day, for example from an Electrum server or even possibly from Blockchain.info or Blockchair.

How do you figure out the appropriate amount of BTC to cover transaction fees accurately over a specified period of time?

So this post had ideas jumping to my head:


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....

The maximum nLockTime of 4,294,967,295 (0xFFFFFFFF) is 06:28:15 on February 7th, 2106.

I'm curious to know what the minimum and maximum values of an epoch-based timelock are.

But I guess that will also prevent you from spending them at all until that period, which is not so helpful

You can specify the nLockTime in Unix time rather than block height, which is an easier calculation and avoids issues with compounding variability in the average block time over a period of weeks or months.

Forgive me if I've misunderstood, but if you need your wallet to recreate the transaction chain on a weekly basis to get the most appropriate fee, then why do you need timelocks at all? Why not just have your wallet create a single transaction each week with an appropriate fee?

The biggest issue here (aside from not being able to access your money if you need it) is if a private key is leaked or compromised, you cannot move the funds to safety. You simply have to wait until the timelock expires and hope that your transaction beats the transaction belonging to the attacker. It also involves backing up and passing on both your private key and your redeem script, which is obviously more complex and more prone to error than a seed phrase.

The guy who put $15k in Bitcoin in a 125 year timelock got me thinking: this would be the first time you can distribute wealth to your descendant far down the line, without trusting third parties.

if you need your wallet to recreate the transaction chain on a weekly basis to get the most appropriate fee, then why do you need timelocks at all? Why not just have your wallet create a single transaction each week with an appropriate fee?

How will changes in fees be accounted for if it is done automatically?

I will not want to overpay

and I will not want to underpay

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.

just periodically recreate the recurring transaction chain every week or so, and the wallet software should be intelligent enough to get the current fee estimates for that day

although I don't know how you would "cache" LN payments so that they can be sent on a future date, but maybe it's more simple than in Layer 1.

You, the sender keep 2 of them, the merchant gets 1.
Since you have 2 of the 3 you can move the coins anytime.

I believe this implies that the "subscription coins" cannot be transferred until the final subscription payment has been made.

So why not consider opening a lightning channel to avoid the complications of on-chain fees? Gather UTXOs (subscription coins) and use them to open a channel with the payee. The only downside is that the payee needs to have a lightning node running. You're anyway going to periodically connect to your wallet to change the fee.

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

How will changes in fees be accounted for if it is done automatically?
At the time of creating the transaction the feerate averagely accepted by miners could be very different to the one at the time of broadcast. I will not want to overpay by a wide margin to accommodate for changes in the mempool and I will not want to underpay and not have my transaction added to any block.

- Jay -