Must a payer trust, and thus be vulnerable to, a payee?

When a payer coordinates a payment to a payee via a lightning network, the payer has to trust that the payee will at least:

not disclose, leak, or reuse the payment preimage prior to the payer sending payment along a route on the network not conspire with, or run an intermediate node on the payment route that has knowledge of the payment preimage (and that is configured to claim/snipe/short-circuit a payment for which it knows the requested preimage/secret) acknowledge successful receipt of payment

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...