[RFC] Push Invoices

[wbobeirne]

Description

To further enable a better user experience and open up more use cases for Lightning, I'd like to propose a concept of push invoices. The idea is that it would utilize the message layer to provide invoices directly to nodes, rather than requiring a roundabout way for the user to present an invoice to their node. (e.g. scanning a QR code, clicking a URI, copy and pasting.)

The only aspect of push invoices that would need to be standardized would be some kind of message sent to the node that receives the invoice, likely via a BOLT #1 message with an invoice as the payload, and feature bits to indicate that you support receiving push invoices.

From there, the Lightning node implementation could do whatever they want with it. They could provide RPC interfaces to access the list of pushed invoices, notify the user via a push notification to some application they have, store it in a list of pushed invoices for when the user next accesses their node, or automatically pay the invoice based on some configuration from the user to auto-pay invoices. None of these would have to be implemented by the node, they're just possibilities.

Since invoices are encrypted via the recipient's private key, a push invoice could be delivered by a request from anyone, not necessarily the invoice creator. This would allow for nodes that aren't online all the time to still be able to send and receive push invoices by having an always-on centralized service do the delivery of them even if the sender or receiver is offline.

Motivation

I also recently started working on an allowance feature for Joule, but want to open up these kinds of payment possibilities to non-browser extension use cases.

Likewise, Casa recently released the Sats app that tries to make payments between people a bit easier. Unfortunately the way they've implemented it is specific to software that runs on top of LND with Casa nodes, so it's unlikely that a standard will form around their payment UX improvements.

Use Cases

1) Venmo-style Payment Requests

Alice would like to request that Bob pay her back for lunch. Alice sends a push invoice from her node to Bob's, who is then alerted by his Lightning mobile app that he has a new payment request. Bob confirms it on his app, and makes the payment. Alice is then notified that her pushed invoice has been paid.

2) Subscription Services

Alice would like to pay a monthly subscription to Bobflix for access to content. She configures with her node to automatically accept pushed invoices of up to 100,000 satoshis per month from the Bobflix node. Every month, Bobflix pushes an invoice to Alice's node. If that invoice fails to be paid, Alice will be contacted via her Bobflix account and be notifed that she failed to pay her subscription.

3) Streaming Micro-Payments

Alice would like to gain access to a video stream that Bob is running, but must pay to access it. She configures her node to automatically accepted pushed invoices of up to 1,000 satoshis per minute from Bob's node for the next hour. Every time her streaming client makes a request for a chunk of the video stream, Bob's node sends a push invoice to Alice's node. Should the push invoice not be paid, Alice's requests to get video data will be denied.

---

Would like to hear if people feel that this belongs at the node level, or if it should only be facilitated by layers on top of nodes.

[t-bast]

Would like to hear if people feel that this belongs at the node level, or if it should only be facilitated by layers on top of nodes.

That was exactly what I was thinking while reading this. I think that this is very useful, but should probably not be done at the Lightning node layer.
There were some discussions on the mailing list concerning the creation of a "Lightning App Specifications" repository to centralize encoding choices for interoperable applications building on top of Lightning, maybe this proposal makes more sense there?

[wbobeirne]

A repo for that information sounds like a great idea. Definitely open to going that route instead. But the main benefit that I see for this being at the node layer is that you can leverage the peer to peer communication port that's already opened and discoverable on the network. Adding a layer on top would mean a new port with new mechanisms for finding other user's connection info for pushing invoices, and a new port that would require network configuration (ufw, router port forwarding etc.)

[t-bast]

That's true, I'm curious to see what other implementers think.

[joostjager]

Small remark: When reading the description I was initially confused by the term "push invoice". To me, "push payment request" would be clearer. In the real world, an "invoice" is a request for payment, but in Lightning it seems that invoice sometimes refers only to the record in the recipient's database.

[eupn]

Is keysend in any way relevant to this?

[nicolasburtey]

it does @eupn (at least to me). But it seems this discussion has stalled?

[dr-orlovsky]

This looks to be related to the new LN offers BOLT, which is WIP by @rustyrussell: #798

It comtains section on new messages for "pushing" invoice offers

[t-bast]

This is addressed by Bolt 12 (#798).