Topic: How to force repeated payment of subscription cost using blockchain or LN? (Read 224 times)

I believe he is saying that a customer pre-signing transactions in advance would not be what he is looking for. The problem with having pre-signed transactions, even with lock times, is that the customer needs to set aside money for the entire length of the subscription when he subscribes. It is common for people to pay for a monthly subscription verses an annual subscription specifically because they don’t want to pay a years worth of payments in advance.

What exactly do you mean here? A zero-confirmation transaction still needs to be sent first, and it's not something the receiving party can "pull".

I can think of a way without using LN: you could sign locktime transactions up front. Say you want to subscribe for 12 months, and you want to pay a monthly amount. You could sign 12 different transactions that become valid at the start of each month, and give the receiving party the raw signed transactions.
Each month, they can broadcast one transaction and get paid. This requires 12 inputs in your wallet that won't be used for anything else, so it's not really practical. In case you want to cancel your subscription, you can just move all funds to a different address and the locktime-transactions become worthless.
If there would be a large demand for such a service, it could be included and automated in a wallet, but I doubt there's much demand. I have some recurring payments (loyce.club domain name for instance), but I just pay them manually.

Another argument against automated Bitcoin payments would be the large fluctuations in value.

If someone has open channel(s), they could use those channels to both send and receive coin via those channels, including any subscription payments. With that being said, a LN wallet could automatically send a set amount of coin every time period (more specifically, it could listen for an invoice from a specific merchant, and automatically pay the invoice up to a specified amount). The customer would need to keep sufficient balances in open channel(s) to pay the invoice, but this should be expected if the customer is receiving a regular income to their various LN channels.

To my knowledge, no such LN wallet currently exists.

You can use Lightning Loop style swaps to rebalance the channel. Essentially, after the subscriber runs out of funds on his side of the channel, he can perform a Loop In swap where he sends the balance with an on chain payment and then the service sends the same amount back to the subscriber over their payment channel. This swap is enforced by Bitcoin scripts so that it is atomic.

For example, if the user has paid 1 BTC in subscription fees and now his side of the channel is empty, he sends 1 BTC to the service on chain, and the service sends 1 BTC to him over their channel. The net result is that both sides have the same amount of money, the channel can continue to be used for payments, and the service now has BTC that they can actually use as it isn't tied up in the channel.

This means that channels don't need to be continually closed and reopened, just every so often a Loop In swap is made.

Most services on the internet charge an annual or monthly subscription fee for using their services and they are able to accomplish that by billing your credit card which "pulls" the payment from the payment processor company. But in bitcoin there is no such concept of "pulling" payment from your wallet as far as I know. The closest you get are zero-confirmation transactions which is obviously unacceptable. I also definitely wouldn't want to manually make the payment every month. And no Bitpay or other bitcoin-on-a-card services.

If Lightning Network is chosen, the seller and customer should be able to each fund the channel with the subscription fee in the channel every month, but due to funding transaction limitations the payment for as many months of subscription that are desired has to be put in the channel all at once, which is infeasible because it's not known how long the customer will subscribe for (remember this is supposed to happen automatically). So now there's the problem that the seller has to "know" how many months the customer will subscribe for. The customer's supposed to be paying but because unilateral channels can't be rebalanced, in case the seller adjusts the rate or customer changes subscription plans, a bidirectional channel would be needed.

So in the LN case, a way to increase the funds of the channel as well as multiple fund deposits are needed in order to make a solution.

Once that's done, then adjusting the subscription rate shouldn't be a problem because the channel can be rebalanced, seller empties funds, the two parties start over with the new fund amount. Decreasing the fee in particular can just bounce back the surplus UTXO to the customer. Customer changing to cheaper/more expensive subscriptions works the same way because the old subscription is kept until the end of the month. And that's how it works in the fiat world too: You cancel or change your subscription but you are still billed at the end of the month for the old one because your choice doesn't take effect until next month.