Keysend (no invoice)
The keysend
feature is a way for a sender to send a payment to a given recipient over the Lightning Network without first having an invoice from the recipient to send against (docs).
The way this works is the sender first needs the destination node id (node’s public key) for the recipient’s Lightning Network node. The sender then creates a preimage and uses it to construct a keysend payment that it then forwards along an appropriate route to the recipient.
When the recipient receives the keysend payment, they would decode the payment and extract the preimage to accept the payment (resolve the HTLC). The recipient would also create an ad-hoc invoice on their end that corresponds to the payment and store it in their local invoice registry.
The recipient would usually have no way of knowing who sent the keysend payment unless the sender somehow makes this explicitly known.
This is a feature that is currently fully supported in:
Note: Unlike when sending against a lightning invoice, if the same keysend is attempted multiple times then multiple fund transfers occur.
keysend
used to be previously called sphinx send
as a reference to the sphinx packets that the Lightning Network uses to onion route packets across the network.
Useful “additional data” mechanisms & applications #
- There is a
--data
flag for sending along data as well (needsrecord=hexvalue
)- This can potentially be used for including things like custom messages or sender info (e.g. see Whatsat’s usage of custom records)
- Custom tlv data records + keysend open up some interesting possibilities (see this tlvshop example)
Common criticisms #
No cryptographic proof of payment for the sender A common concern you would hear is that the sender does not have in hand a signed invoice that matches to the preimage they would hold for the payment as there would be in a standard transaction. This means that there is technically nothing proving that the preimage was given to the recipient and settled along a route back to the sender (see Rusty Russell’s response, tweet | img).
Not everyone agrees with this perspective though since not everyone puts the same level of importance on having this cryptographic linkage for a fulfilled payment.
In some cases you can actually prove stronger statements with AMP than MPP. In others, you can’t. TBH though w/o a formal definition of the schemes and the desired security properties, there isn’t a simple answer. FWIW I don’t consider invoice/preimage to be a “secure” receipt.
As researched by Conner Fromknecht from Lightning Labs
- Alex Bosworth from Lightning Labs (img)