Quote from: BlackHatCoiner on Today at 12:15:05 PM

Quote from: NotATether on Today at 12:11:04 PM

That will work, but what if you want to cancel and get a refund?

What's the problem with contacting your merchant and requesting a refund?

Well that's not exactly what I had in mind. You said locktime can be used on the transactions to force a delay of it being included into a block until a particular time, but what if you change your mind and decide not to continue paying for the service?

Example: suppose Twitter Verified (or whatever it's called now) has this futuristic infrastructure you can use to make these kind of bitcoin transactions with, so you make some locktimed transactions, but then mid-way through your subscription, you learn that the site is going to make a change you don't like, so you want to cancel the locktime and get a refund.

Now that I think about it, I guess that the refunds could be effected by moving the funds to one of your other addresses before the locktime expires, thus invalidating the locktime transaction. Doesn't sound like a bad idea after all.

Although another challenge that would be faced with any subscription strategy is where you would like to subscribe for multiple months in advance so that you don't have to remember to make a transaction every month, but you only have funds for let's say 2 months or something. The software would have to be intelligent enough to create more locktime transactions on top of those, when additional funds come, if you want it to allocate the money there.

Third challenge is similar to the second, you have multiple months paid in advance but you have not left any more UTXOs unlocked for you to make other transactions to unrelated stuff, so making any transaction means the entire subscription chain needs to be invalidated and re-constructed. So I guess its as easy to solve as the other challenges.

Fourth challenge and I think this is the most concerning one is, what if you create the subscription chain, and everything is fine except one month later, fees have shot up and your fee is too low to get it confirmed quickly. This will require user intervention to recreate another transaction manually, and to be honest, this is the kind of scenario where users should not have to intervene or do anything to make the subscription "just work". Maybe it can be solved by using higher-than-normal fees by default such as 50 sats/vbyte or maybe even 100 sats/vbyte - dynamically calculated by a decentralized network of servers as basically the "high" feerate x5 is a good setting - but that might be taxing for very small microtransactions.

But in the case of microtransactions I feel as though only Lightning Network is suitable for sending those. Not on-chain.