fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: What if instead of the ...
📅 Original date posted:2021-09-21
📝 Original message:
What if instead of the payer generating the preimage the payee could
generate stateless invoices? Basically just use some secret to compute the
preimage upon receiving the HTLC, for example:
1. Payer requests an invoice.
2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)),
then encodes arbitrary_invoice_id into the invoice somehow.
3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
tlv_record_a) and resolves it.
I've implemented such a scheme on @lntxbot, but it required low level code
in a c-lightning plugin and a hack with route hints: since TLV payloads
were not an option (as payers wouldn't know how to send them) I've used a
"shadow" route hint to a private channel that didn't exist, so preimage was
generated on the payee using preimage = hmac(local_secret,
next_channel_scid).
If however node implementations could provide such a thing it would reduce
database requirements and improve the lives of application developers very
much.
On Tue, Sep 21, 2021 at 7:09 AM Joost Jager <joost.jager at gmail.com> wrote:
> Problem
>
> One of the qualities of lightning is that it can provide light-weight,
> no-login payments with minimal friction. Games, paywalls, podcasts, etc can
> immediately present a QR code that is ready for scan and pay.
>
> Optimistically presenting payment requests does lead to many of those
> payment requests going unused. A user visits a news site and decides not to
> buy the article. 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?
>
> Stateless invoices
>
> What would happen if a lightning invoice is only generated and stored
> nowhere on the recipient side? To the user, it won't make a difference.
> They would still scan and pay the invoice. When the payment arrives at the
> recipient though, two problems arise:
>
> 1. Recipient doesn't know whom or what the payment is for.
>
> This can be solved by attaching additional custom tlv records to the htlc.
> On the wire, this is all arranged for. The only missing piece is the
> ability to specify additional data for that custom tlv record in a bolt11
> invoice. One way would be to define a new tagged field for this in which
> the recipient can encode the order details.
>
> An alternative is to use the existing invoice description field and simply
> always pass that along with the htlc as a custom tlv record.
>
> A second alternative that already works today is to use part (for example
> 16 out of 32 bytes) of the payment_secret (aka payment address) to encode
> the order details in. This assumes that the secret is still secret enough
> with reduced entropy. Also there may not be enough space for every
> application.
>
> 2. Recipient doesn't know the preimage that is needed to settle the
> htlc(s).
>
> One option is to use a keysend payment or AMP payment. In that case, the
> sender includes the preimage with the htlc. Unfortunately this doesn't
> provide the sender with a proof of payment that they'd get with a regular
> lightning payment.
>
> An alternative solution is to use a deterministic preimage based on a
> (recipient node key-derived) secret, the payment secret and other relevant
> properties. This allows the recipient to derive the same preimage twice:
> Once when the lightning invoice is generated and again when a payment
> arrives.
>
> It could be something like this:
>
> payment_secret = random
> preimage = H(node_secret | payment_secret | payment_amount |
> encoded_order_details)
> invoice_hash = H(preimage)
>
> The sender sends an htlc locked to invoice_hash for payment_amount and
> passes along payment_secret and encoded_order_details in a custom tlv
> record.
>
> When the recipient receives the htlc, they reconstruct the preimage
> according to the formula above. At this point, all data is available to do
> so. When H(preimage) indeed matches the htlc hash, they can settle the
> payment knowing that this is an order that they committed to earlier.
> Settling could be implemented as a just-in-time inserted invoice to keep
> the diff small.
>
> The preimage is returned to the sender and serves as a proof of payment.
>
> Resilience
>
> To me it seems that stateless invoices can be a relatively simple way to
> improve the resiliency of systems that deal with lightning invoices.
> Unlimited amounts of invoices can be generated without worrying about
> storage or memory, no matter if the requests are due to popularity of a
> service or a deliberate dos attack.
>
> Interested to hear your thoughts.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/997189bc/attachment.html>;
📝 Original message:
What if instead of the payer generating the preimage the payee could
generate stateless invoices? Basically just use some secret to compute the
preimage upon receiving the HTLC, for example:
1. Payer requests an invoice.
2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)),
then encodes arbitrary_invoice_id into the invoice somehow.
3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
tlv_record_a) and resolves it.
I've implemented such a scheme on @lntxbot, but it required low level code
in a c-lightning plugin and a hack with route hints: since TLV payloads
were not an option (as payers wouldn't know how to send them) I've used a
"shadow" route hint to a private channel that didn't exist, so preimage was
generated on the payee using preimage = hmac(local_secret,
next_channel_scid).
If however node implementations could provide such a thing it would reduce
database requirements and improve the lives of application developers very
much.
On Tue, Sep 21, 2021 at 7:09 AM Joost Jager <joost.jager at gmail.com> wrote:
> Problem
>
> One of the qualities of lightning is that it can provide light-weight,
> no-login payments with minimal friction. Games, paywalls, podcasts, etc can
> immediately present a QR code that is ready for scan and pay.
>
> Optimistically presenting payment requests does lead to many of those
> payment requests going unused. A user visits a news site and decides not to
> buy the article. 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?
>
> Stateless invoices
>
> What would happen if a lightning invoice is only generated and stored
> nowhere on the recipient side? To the user, it won't make a difference.
> They would still scan and pay the invoice. When the payment arrives at the
> recipient though, two problems arise:
>
> 1. Recipient doesn't know whom or what the payment is for.
>
> This can be solved by attaching additional custom tlv records to the htlc.
> On the wire, this is all arranged for. The only missing piece is the
> ability to specify additional data for that custom tlv record in a bolt11
> invoice. One way would be to define a new tagged field for this in which
> the recipient can encode the order details.
>
> An alternative is to use the existing invoice description field and simply
> always pass that along with the htlc as a custom tlv record.
>
> A second alternative that already works today is to use part (for example
> 16 out of 32 bytes) of the payment_secret (aka payment address) to encode
> the order details in. This assumes that the secret is still secret enough
> with reduced entropy. Also there may not be enough space for every
> application.
>
> 2. Recipient doesn't know the preimage that is needed to settle the
> htlc(s).
>
> One option is to use a keysend payment or AMP payment. In that case, the
> sender includes the preimage with the htlc. Unfortunately this doesn't
> provide the sender with a proof of payment that they'd get with a regular
> lightning payment.
>
> An alternative solution is to use a deterministic preimage based on a
> (recipient node key-derived) secret, the payment secret and other relevant
> properties. This allows the recipient to derive the same preimage twice:
> Once when the lightning invoice is generated and again when a payment
> arrives.
>
> It could be something like this:
>
> payment_secret = random
> preimage = H(node_secret | payment_secret | payment_amount |
> encoded_order_details)
> invoice_hash = H(preimage)
>
> The sender sends an htlc locked to invoice_hash for payment_amount and
> passes along payment_secret and encoded_order_details in a custom tlv
> record.
>
> When the recipient receives the htlc, they reconstruct the preimage
> according to the formula above. At this point, all data is available to do
> so. When H(preimage) indeed matches the htlc hash, they can settle the
> payment knowing that this is an order that they committed to earlier.
> Settling could be implemented as a just-in-time inserted invoice to keep
> the diff small.
>
> The preimage is returned to the sender and serves as a proof of payment.
>
> Resilience
>
> To me it seems that stateless invoices can be a relatively simple way to
> improve the resiliency of systems that deal with lightning invoices.
> Unlimited amounts of invoices can be generated without worrying about
> storage or memory, no matter if the requests are due to popularity of a
> service or a deliberate dos attack.
>
> Interested to hear your thoughts.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/997189bc/attachment.html>;