This article briefly examines some aspects of trust and vulnerability on lightning networks. The observations herein are general and apply to multiple lightning networks, including those of Bitcoin and Litecoin. Questions answered in this article include:
When a payer coordinates a payment to a payee via a lightning network, the payer has to trust that the payee will at least:
In these respects, the payer is fully trusting of (vulnerable to) the payee. Even an honest payee can fail to protect the payment preimage from attack. A dishonest payee, even after having received payment, may simply repudiate a payment as there is not even a cryptographic proof provided to the payer that the payee acknowledged or received the payment. The maximum security level of a payment is bounded by the security of the payee's node/server/preimage datastore. When a payment preimage is not properly controlled, then an associated payment is susceptible to being claimed by an intermediate node on the payment route. Therefore, the actions of a payee can make the payer unknowingly vulnerable to other nodes that the payer selects to be on the payment route. How does a payer determine that a payment hash has not been reused, disclosed, or otherwise compromised? There is no way for the payer to know prior to attempting to send a payment. After sending payment, the vulnerability only becomes apparent when the payee claims that no payment was received. In this model, the payer is always vulnerable to intermediate nodes on the payment route and it is the case that the vulnerability of one node can increase the vulnerability of other nodes on the network.
To understand why the payer must trust the payee for the items above, let's review how payments on the network work. Each hop in a lightning network payment performs a contract where the current node says to the next node, "I'll pay you to disclose to me a preimage/secret that has this SHA256 hash value". Each node along the payment route performs this contract with the next node, until finally the next node knows the preimage and returns it in order to claim the promised payment. The payment stops propagating along the route at this point and the preimage propagates back to the payer node. This is how the guarantee of payment gets pulled along the route and incentivies off-chain updating of channel balances. In the best case, the only node that can disclose the preimage is the route's final intended payee node. But, that is not the case when the payee's recipient node is breached (or when a dishonest payee conspires to share the preimage) and the preimage is made available to an intermediate node on the payment route. Stated simply, a payment should only route as far along a payment route as the first node on the route that knows a preimage for the payment hash. Past that point, there is no incentive for the node to pay another node for the knowledge that it already has. Because of this, reused payment hashes have been referred to as "free money for relaying nodes". This is why it is not safe to accept tips/payment to, for example, a noninteractively published BOLT 11 invoice.
For more info, see the Developer documentation, that states:
"An attacker could save the preimages they’ve seen and reuse it for another payment that is reusing the invoice. Therefore, failure to generate new payment requests means that an on-path attacker can steal the payment en route."
The Lightning Network paper has this to say:
"In the event that R gets disclosed to the participants halfway through expiry along the path (e.g. day 2), then it is possible for some parties along the path to be enriched."
Note that even though a dishonest payee can always simply deny having received a payment, a dishonest payee may desire to conspire with intermediate nodes on the payment route in order to increase deniability. For example, if operators of intermediate nodes on the payment route are honest and contactable (or able to be subpoenaed) then they may be able to provide evidence that substantiates a payer's claim of payment. By sniping the payment via an intermediate node, the dishonest payee actually creates evidence contrary to such a claim of payment.
It follows that when the preimage can originate from an arbitrary node on the payment route, knowledge of a particular payment preimage does not provide sufficient proof that a successful payment occurred. Simply, the payer node promised to pay for some data that hashed to a particular value, and that data is what it received. Also, as can be plainly seen, knowledge of a payment preimage does not prove that payment of a lightning network invoice was attempted. Such knowledge can be obtained in other ways, such as via a data leak, an accident, reuse, dishonesty, use of non-unique or predictable hash inputs, etc...
When considering a payment being routed through at least one intermediate node, it is plainly obvious that knowledge of a payment preimage is shared with each node and is not individually linked to the payer of a lightning network invoice. That is, more than one node will necessarily have such knowledge. Therefore, a payment preimage should not normally be used alone to authenticate payment (especially for those transacting non-de minimis aggregate value). It is also possible to reuse a payment preimage for more than one invoice. In such a case, would knowledge of the preimage authenticate the payer of one, both, or neither invoice? As another example, when selling physical items, it is not advisable for a merchant to noninteractively publish a unique lightning network invoice for each unique item being sold. In such a case, the merchant might want to authenticate messages from customers (e.g.- to add destination shipping instructions) via knowledge of the payment preimage. As discussed already, it would not be advisable for the merchant to authenticate messages in this manner since operators of intermediate nodes could confuse the merchant and misdirect the shipment of the goods.
For the purposes of this article, a payment hash is simply the output of a single application of the SHA-256 message digest function to an input value. The input to the function is known as the payment preimage and is assumed to be unique, unpredictable, and chosen uniformly from the range of possible input values. For example:
Given an input having the qualities mentioned above, and assuming SHA-256 is preimage resistant, then given a hash value and the challenge to solve a puzzle by producing a corresponding preimage yielding the hash value, it is assumed that simply computing the preimage is infeasible. Also, due to SHA-256's conjectured second-preimage resistance, it is assumed to be infeasible to find a preimage other than the one originally intended that maps to the same hash value. With this background knowledge it is already easy to see that knowledge of a preimage in and of itself proves nothing about payment of an invoice. At a basic level, knowledge of such a preimage and hash value pair only demonstrates that one knows an input that produces the particular output hash value when processed through a function that is at least partially consistent with SHA-256. Within the context of a lightning network, a payment preimage is intended to be used as a secret nonce that has the primary function of allowing nodes along a payment route to reliably pull payment along.
As discussed in this article, a lightning network invoice is a BOLT 11 document. In short, an invoice is an advertisement by a lightning network node (i.e.- a payment destination) that it knows a preimage for a specific hash value and that it will disclose the preimage in exchange for a payment. Usually a specific amount of value to pay is provided, but it is not mandatory. Note that there is no restriction (and one can not exist, nor be enforced by the network) that the node advertising this knowledge accept payment of the invoice only one time, or for a particular amount. In fact, a pathological node can accept any payment on any route that it is a part of and for which it has knowledge of the payment preimage.