Recurring Payments

[Polyomino]

Does a standard for recurring payments belong here?

I think lnd can be made to support recurring payments by issuing macaroons with permissions to spend in the future. I think we should avoid a dependency on macaroons for BOLTs if they aren't already.

Is there an existing work stream in this direction?

[rustyrussell]

Recurring payments should work with discrete log payments (eg. scriptless scripts), and I've been toying with the idea of a bolt11 extension for 1.1. There are questions over whether we should allow specification of oracles for exchange volatility, but that may be trying to boil the ocean...

[Roasbeef]

What do you mean precisely by "recurring payments"?

[Roasbeef]

Or do you mean like "spontaneous payments"?

[Roasbeef]

In either case, it would seem that this is purely and end to end thing, and doesn't really require a BOLT. But if something emerges and is popular, then we can document it and start to standardize it.

[rustyrussell]

I assumed he's referring to an invoice which says "pay this amount this often". It's a common request in the Bitcoin world, and makes even more sense for lightning due streaming services.

[cdecker]

Adding this to the "someday" milestone since we need to first figure out a number of things. For once we need to agree on a format to specify recurring payment times.

Additional feedback from users is encouraged to better define the use-case and the requirements that this feature should consider.

[jb55]

For a lightning subscription/donation service I'm working on, all I would need is a way to do recurring spontaneous payments. Perhaps a clightning/lnd plugin that does this automatically.

The initial bolt11 could include what data needs to be encrypted in each spontaneous payment (account id, etc), and how often it should be sent.

The node could execute this spontaneous payment automatically until cancelled.

[xgzhc]

wo need a protocol that get dynimic code(an invoice) by static code,static code is address(eg http api) that can return signed invoice and it's public key

[fiatjaf]

@xgzhc lnurl-pay is exactly this: https://github.com/btcontract/lnurl-rfc/blob/master/spec.md#4-lnurl-pay

See also https://xn--57h.bigsun.xyz/lnurl-pay-for-everything.html#subscriptions

[rene78]

I have a similar use case: I'd like to pay my landlord via the Lightning network the equivalent amount of e.g. 20$ daily. Would be cool if that was possible 🙂.

[mateuszjarzewski]

You have no idea how this could rocketlaunch lightning adoption.
No recurring payments is by far the biggest disadvantage (businesswise) to credit cards and other solutions that got recurring payments.

[vincenzopalazzo]

No recurring payments is by far the biggest disadvantage (businesswise) to credit cards and other solutions that got recurring payments.

We have the support with a previous bolt12 support, I think it takes only some time to be integrated. N.B the bolt12 proposal was cut and the part of the recurrent payment was removed.

But I'm pretty sure that it will be an addition in the near future.

[adam248]

Any news on this issue?
To at least create a basic standard for allowing invoices to have a recurring option would be great!
It can be as simple as the protocol supporting a recurring message inside the invoice saying you are agreeing to a recurring term described by the invoice but it is fully controlled on the sender's node side (push-only not-pull payments). So the recurring terms are "copied" into the node from the invoice.
That way the sender at any time can log in to their node and cancel the recurring payment any time they wish.
Maybe an added option to notify the receiving party of the cancellation might be nice but not critical.

[t-bast]

This is part of the Bolt 12 scope: it was removed from the first Bolt 12 release to avoid feature creep, but @rustyrussell is working on this and will add this after the first Bolt 12 is merged (#798).