Expanding bitcoin into layers has proven to be the right option in protecting the base layer’s integrity and allowing for innovation to be built on top of it, creating a payment stack. The Lightning Network is firmly focused on tackling the “coffee crowd”, those who claim bitcoin isn’t useful until they can pay for a coffee with ease.
That’s already been happening with the likes of Lightning-enabled invoices, Lightning-enabled NFC’s and even Lightning Addresses, as more people around the world start to conduct their transactions on a bitcoin standard.
Lightning has made microtransactions possible with bitcoin even as it continues to scale, and as more people discover its obvious benefits, some are finding issues with its current payment structures. In Lightning, to pay someone, you either need to receive or generate an invoice; this isn’t exactly practical for someone who simply wants to pay an address as compared to someone using the base layer
You can pay a bitcoin address in any amount you choose as long as you have the address is an established user experience, so bringing that experience to second layers is important for congruency.
Pain points on Lightning
To make a Lightning payment, the payee needs to generate a BOLT 11 invoice and then send it to the payer by email, displaying it as a QR code or other means. You can think of this invoice as a Bitcoin address in the Bitcoin network, even though it works substantially differently.
The main difficulty is when the receiver can’t interact with the payer (e.g., because he doesn’t know who/when he’s getting paid, like anonymous donations, or when the receiver doesn’t have a channel to speak with the payer).
Another is if the payee needs to accept reoccurring payments with varying amounts.
What is Keysend?
This is where Lightning Keysend shines. Keysend removes the need for invoices when making payments. Instead, the receiver of the funds shares their node ID (a public key) once, and then the payer can pay any amount at any time in the future. Keysend doesn’t require changes to the network, but the receiving node needs to have Keysend support enabled.
Keysend allows users in the Lightning network to send payments to others, directly to their public key, as long as their node has public channels and has Keysend enabled. Keysend does not require the payee to issue an invoice.
- This payment type can also be used to attach messages and other data.
- With KeySend, a Lightning payment can be executed without having received an invoice from the payee beforehand.
- Normally, Lightning payment requires the payee to create a Lightning invoice in advance, in which all payment-related information is embedded
- This makes it possible to develop a new set of use cases for spontaneous payments.
- KeySend can be used to make payments for donations, grants and the like.
- But also the payout for affiliate commissions or kickback payments.
- KeySend allows Lightning Nodes to send Lightning to other Nodes without having to pay a bill.
Enabling Keysend
To enable receiving KeySend payments, the latest LND version must be used on the target server and the flag: –accept-key-send must be enabled.
If this flag is not set, Keysend payments are rejected.
Only the Lightning Node of the payer and the destination node must support KeySend. The intermediate nodes used to forward the payment do not need to be activated for KeySend payment. All LND nodes from version 0.71. support this function.
This is a feature that is currently fully supported in:
What else can Keysend enable?
With Keysend, Lightning users are able to more easily accept donations, report earnings, and build Lightning-only APIs. Further innovations leveraging Keysend are chat apps (ex. Sphinx Chat) and streaming payments like Podcasting 2.0 apps which use Keysend to send extra information with the onion packet that envelopes the payment information.
What does a Keysend payment look like?
The payment data that is sent into the network carries the required information. This information includes an encoded amount of sats to send, a message, and a preimage. After the payment reaches the destination and the receiving node accepts the payment, the preimage is revealed, and payment is confirmed.
A Keysend payment is end-to-end encrypted which means none of the nodes moving the payment can fully unwrap the package and discover the preimage. Only the final destination is able to do that.
How is Keysend data sent?
In a regular invoice-based Lightning payment, the receiver picks a preimage and then applies a cryptographic hash to it and then gives the invoice to the payer. The preimage acts as proof the payment was completed once paid due to the invoice being signed by the recipient.
For a Keysend payment, the payer picks the preimage instead and then uses onion wrapping to seal the data as it routes to the recipient. The onion-wrapped data is transmitted along a hidden route from the nodes moving the payment. This data package gets incrementally unwrapped as the payment travels to its final destination.
Privacy concerns using Keysend
To protect user privacy, the payment algorithm performs some randomisation.
1: Route randomisation
Route randomisation means the payment algorithm does not always use the lowest fee or shortest route. This prevents some highly-connected nodes from learning all of the user payments by reducing their fees below the network average.
2: Shadow route
Shadow route means the payment algorithm will virtually extend the route by adding delays and fees along it, making it appear to intermediate nodes that the route is longer than it actually is. This prevents intermediate nodes from reliably guessing their distance from the payee.
- Route randomisation will never exceed maxfeepercent of the payment.
- Route randomisation and shadow routing will not take routes that would exceed maxdelay.
Keysend shortcomings
Keysend might bring some great new features to the Lightning stack, but like EVERYTHING in bitcoin, it has its trade offers which users and developers need to consider when using it as a payment method.
No proof of payment
The preimage is sent with the payment, but only the receiver can read it. The receiver can then use the onion-wrapped preimage to settle the payment. Due to the payer picking the preimage, the payer can’t prove that they paid anything even after the payment is complete since no new information was gained.
No hop hints
By using Keysend your payment may utilise a less efficient route due to not knowing the channels of who you are paying. You still have the power to refuse payments.
Adds complexity
There is no enforced consensus on Lightning. As each implementation grows and develops its unique features, the complexity of the network will increase. The more complex the lightning network becomes in this regard, the harder it is to have a standard across all implementations.
Privacy
One important consideration before you begin to accept Keysend is whether or not you want the world to know all of your public channels and capacity. Your pubkey says a lot about you and your node, including total capacity, your peers, fee rates, and other information.
Although no one knows exactly how much of the total capacity of your node that you own, you may be in a position where you do not want this information out in the open and tied directly to you. It is important to note that a regular BOLT 11 invoice can also be decoded to expose your pubkey.
A smoother lightning experience
Lightning is slowly expanding to fulfil its promise as the “everyday experience” for bitcoiners and as more of these tools roll out, it gives users far more control and optionally over the experience they want and will attract more users who might have been alienated by the previous options.
As the Lightning base protocols already have it running and wallets and Lightning apps start to roll it out, Keysend will enable better payment functionality similar to what we experience in traditional finance.
Since the payer can specify the amount to be sent, the receiver node must enable this feature manually to reduce the number of requests which can pose a risk of spam or lack of proof of receipt.
A node that serves a merchant function arguably does not have a good reason to enable Keysend but would prefer something like AMP or fallback payments. However, an educator, blogger, podcaster, charity or developer may want to have Keysend enabled to receive ad hoc payments or donations, as the friction is on the receiver side and making the payment easier to conduct.
Keysend can be used with your own Lightning node. It also makes for a robust way of managing payments and remittances in regions that may fall under financial repression or have limitations on cross-border payments.
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Have you tried all the forms of Lightning payments? Which one do you prefer? Let us know in the comments down below.
