At a high level the lightning network works by passing payments along a route of channels until it gets from sender to recipient. The payments are routed in an atomic way, meaning that, the payment either gets all the way to the recipient or it fails completely. This means that payments can’t get stuck or stolen at any point in the routing from sender to recipient.
The Standard Invoice #
Payments are made via invoices that are generated by the recipient and sent to the sender via some out of band method (QR code, text message etc.).
The following describes the technical bits relevant for routing. We should probably include notes on the other elements of an invoice as well e.g. amount, recipient node id, description etc.]
Invoices are made up of a few different pieces of information, but the two critical bits that we are usually concerned with are:
- The payment hash, and
- The payment preimage
Payment hash #
Think of this as a single blob that acts as a fingerprint that secures the invoice. It is not related to the rest of the invoice contents in any way and a single payment hash can optionally be used to make multiple invoices (see Hodl invoices below). For a standard payment, the payment hash is included as part if an invoice created by the recipient and the invoice is given to the sender for payment.
Payment hashes are created by first randomly selecting some secret (preimage) and then hashing this to the payment hash.
Payment preimage #
Think of this as the receipt that is provided on successful delivery of a payment. This receipt is held secretly by the recipient and only revealed on receipt of the payment that comes in across the network.
The way it is revealed is by passing the preimage back up the route to the nodes who forwarded the payment down. This preimage allows each node to trustlessly collect the fees for their part of the route, and the preimage is passed all the way back up to the sender. The sender can confirm that a given preimage is the correct one for a payment by calculating the hash and comparing to the payment hash included in the invoice.
If this secret is revealed before the payment is received, other participants in the network involved in routing this particular payment can steal the funds (note: confim this) en route before it gets to its destination. This could be done by passing the receipt (preimage) back up the chain without sending the payment forward to the recipient.
Expiry time #
This is effectively a time limit past which the invoice becomes invalid.
(Research how this is enforced. So far I’m only finding that the recipient discards the preimage, but this doesn’t make sense in cases where the recipient isn’t the one generating th preimage as with hodl invoices)
Amountless invoices Invoices without a payment secret, as with amountless invoices can be a security risk as the second to last hop is able to change the amount and steal the funds as it’s fee.[^1]