A client can cheat if the backend has multiple endpoints with different prices

[philippgille]

Reproduction

1. Create backend with 2 endpoints, "a" and "b"
   • "a" is 1 Satoshi, "b" is 10 Satoshis
2. Client sends initial request to each
3. Client pays invoice for "a"
4. Client sends final request to "b", but with the preimage of the payment for "a"
5. => Request works although the client didn't pay the related invoice

Problem

The middleware doesn't track which invoice was created for which endpoint, it doesn't know about the endpoints at all. It just checks if the preimage was already used as payment proof and then checks the LN node for the invoice's existence and settlement.

Possible solution

1. When the initial request arrives we're in the correct middleware instance, so we cache the URL path along with the preimage or its hash
2. When the final request arrives we don't just check if it's valid (not used before, invoice settled), but also if the current request URL path is the same we previously cached. (Lookup via the preimage or its hash)

Note 1: It's not enough to have an in-memory cache of just the preimage or its hash per middleware instance, because in case of a horizontally scaled web service the caches wouldn't work properly anymore. It's probably best to use the existing storage client implementations, so the web service developer can choose for example Redis when he wants to scale horizontally.

[philippgille]

A client can cheat not only in the case mentioned in the title, but also if the lnd is used for other invoices unrelated to the webservice, and the client uses one of the preimages of those invoices.

[philippgille]

Looking at how paypercall prevents this, you can see in this file, that they only cache the invoice ID, and store the information about the request (HTTP verb, URL path) inside of a token that they sent to the requesting client, encrypted with the same secret that's used for the Lightning Charge backend. When the client sends the request again, paypercall can decrypt the token and read the info about the request. The encryption makes sure the client can't fake the token.

The advantage of that is that fewer info has to be stored, so the DB stays as small as possible. The disadvantage is that the token has to be sent back and forth.

In our case this would be a breaking change from the perspective of a client. (The current vNext contains a breaking change regarding the header anyway, but that's just a change of the encoding.)

My current implementation stores all the info in the DB, and doesn't send any token to the client. The client still only needs to send the preimage in the second request. This is possible because the stored data is stored with the invoice ID (a.k.a. preimage hash, a.k.a. payment hash) as key and the preimage can easily be hashed to get that value. In the future ln-paywall should accept the invoice ID directly as well. This also makes the process very clear for users: In the second request you just have to reference the invoice that you just paid. Like when you order something online but with pick up in a store, then you give them your invoice ID so they can check some metadata about it (was it paid etc.).

In the future it might make sense to support both modes of operation. Although this wouldn't be necessary for compatibility with paypercall clients - for that it would suffice to send the invoice ID in the X-Token header of the invoice response (after the above mentioned acceptance of the invoice ID is implemented).