From joost.jager at gmail.com Thu Sep 23 09:48:06 2021 From: joost.jager at gmail.com (Joost Jager) Date: Thu, 23 Sep 2021 11:48:06 +0200 Subject: [Lightning-dev] Stateless invoices with proof-of-payment In-Reply-To: References: Message-ID: > > > The conventional approach is to create a lightning invoice on a node and > > store the invoice together with order details in a database. If the order > > then goes unfulfilled, cleaning processes remove the data from the node > > and database again. > > > The problem with this setup is that it needs protection against unbounded > > generation of payment requests. There are solutions for that such as rate > > limiting, but wouldn't it be nice if invoices can be generated without > the > > need to keep any state at all? > > Isn't this ultimately an engineering issue? How much exactly is "too much" > in this case? Invoices are relatively small, and also don't even > necessarily > need to be ever written to disk assuming a slim expiration window. It's > likely the case that a service can just throw everything in Redis and call > it a day. In terms of rate limiting a service would likely already need to > implement that on the API/service level to mitigate app level DoS attacks. > It is an engineering issue and indeed, you can use something like Redis to solve it. Today's internet is probably doing the same thing and it seems to work so far. With lightning though, there is another option. And it could be an engineering advantage to not have to keep that state. I can also imagine that slim expiration windows aren't always desirable. Thinking of personalized payment requests in mass mailings for example. So yes, this is not about new functionality, but I still think it is worth exploring the path. As far as pre-images go, this can already be "stateless" by generating a > single random seed (storing that somewhere w/ a counter likely) and then > using shachain or elkrem to deterministically generate payment hashes. You > can then either use the payment_addr/secret to index into the hash chain, > or > have the user send some counter extracted from the invoice as a custom > record. Similar schemes have been proposed in the past to support "offline" > vending machine payments. > What would be the advantage of using elkrem or shachain compared to just using `H(receiver_node_secret | payment_secret)` as the preimage? The sender knows all the preimages already anyway, they aren't revealed one by one by another party. Also I think it could be beneficial to add more data into that hash function such as the payment amount and the order details. With that, the receiver knows that they received a payment for something that they offered in the past, without having the actual record of that stored somewhere. > Taking it one step further, the service could maintain a unique > elkrem/shachain state for each unique user, which would then allow them to > also collapse the pre-image into the hash chain, which lets them save space > and be able to reproduce a given "proof that someone in the world paid" > (that no service/wallet seems to accept/generate in an > automated/standardized manner) statement dynamically > Can you provide an example to clarify this idea a bit more? If I read it correctly, the goal is for the receiver to produce a proof that someone in the world paid. But how can this be proven if the receiver can generate all the preimages that they want? Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: