Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-23 📝 Original message: > > > The conventional ...
📅 Original date posted:2021-09-23
📝 Original message:
>
> > 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210923/380db50c/attachment.html>;
📝 Original message:
>
> > 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210923/380db50c/attachment.html>;