Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: > > > preimage = ...

📅 Original date posted:2021-09-21
📝 Original message:
>
> > 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.
>
> Does this actually work?
> How does the sender know the `invoice_hash` to lock the HTLC(s) to?


> If the sender does not know the `node_secret` (from its name, I am
> guessing it is a secret known only by the recipient?) then it cannot
> compute `invoice_hash`, the `invoice_hash` has to be somehow learned by the
> sender from the recipient.
>

So to be clear: this isn't a spontaneous payment protocol with
proof-of-payment. The sender will still request an invoice from the
recipient via an ordinary http request (think of a paywall with qr invoice
that is presented when web-browsing to a paid article). That is also how
the sender learns the invoice_hash. It is part of the bolt11 payment
request as it always is.

The goal of the scheme is to alleviate the recipient from storing the
invoices that they generate.

Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/e9fbb17f/attachment.html>;