Add keysend invoice

[akumaigorodski]

This adds a new type of invoice tailored specifically for keysend payments, it complements keysend scheme outlined at https://github.com/alexbosworth/keysend_protocols#keysend-protocol-2-basic-messages.

The idea is:

1. Routing hints are handled in a standard way so keysend invoice issuer may be a mobile wallet user with private channels only.
2. lnks prefix prevents it from being wrongly categorized as usual invoice (and failed since it does not contain a payment hash field which is required for usual invoices).
3. 5482373481 onion TLV field contents (32 Byte Predetermined Id for Grouping Messages) will be a payment secret tag provided by payee beforehand in keysend invoice. This will allow payee wallet to group different incoming payments belonging to the same keysend invoice.

[TheBlueMatt]

Shouldn't the BOLTs first support keysend itself? This is the first reference to "Keysend" in the BOLTs.

[akumaigorodski]

@TheBlueMatt yes, probably. Although the basis 5482373484 keysend onion TLV is present in Eclair, LND and CL, I was under impression it is a standard already.

[ysangkok]

@btcontract According to this comment by roasbeef keysend will be obsoleted by AMP. So since keysend isn't standardized, maybe the plan is to standardize AMP instead? I don't know.

[t-bast]

I'm not sure we'll want to standardize this version of keysend.
Let's see what @cfromknecht thinks, but waiting for AMP (which is a superset of keysend and builds on what was learnt from keysend in the wild) is probably a better idea.

[cdecker]

I agree with @TheBlueMatt that keysend is insufficiently documented / specced (see my recent trouble when enforcing featurebit 55 to check if recipients accept keysend which turned out to be a wrong assumption), making anything that builds on top of it underspecced as well.

In addition, like @t-bast, I was under the impression of the AMP proposal replacing keysend altogether, and it's proposal being close to being finished, so why add features to something we have absolutely no intention of maintaining longer term? The resulting fragmentation would be rather unpleasant.

Finally, from a nomenclature point of view it is counterintuitive to have invoices for what is supposed to be invoiceless payments. I consider these to be more of an address book annotation than an invoice, and presenting/serializing it like an invoice is not the way to go (plus adding new prefixes to all supported network is just plain weird...).

[akumaigorodski]

@cdecker not against any of these points except that I believe there is a place for something in between an ordinary invoice and a completely invoice-less payment, especially for private channel only nodes where nodeId alone is just not enough, and then using some payment secret/grouping id for accounting purposes is nice from UX point of view.

[Roasbeef]

Rather then do something like this that doesn't support payment splitting, I think a better option would be eventually implement the WIP AMP spec (which in our eyes replaces key send as mentioned above): https://github.com/cfromknecht/lightning-rfc/blob/bolt-amp/21-atomic-multi-path-payments.md. We're in the final draft/testing phases, but will open a PR on the spec very soon.

It's basically keysend but supports payment splitting and also has a few other features like subscriptions, etc. This is implemented in lnd here: lightningnetwork/lnd#5108. It does support an invoice as mentioned above, but it's a static one. As an example a site that wants to accept donations can have a user scan the invoice (vs manually typing in the pubkey or w/e) which then includes all the necessary information to complete the payment. It also supports recurring push payments since the payment address included is included for all payments that use that invoice, which lets the receiver map that on the backend to say an account ID.