ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: Good morning Joost, > > > ...

📅 Original date posted:2021-09-21
📝 Original message:
Good morning Joost,

> > > 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.

Ah, thanks for the clarification.
This should probably work, then.

Regards,
ZmnSCPxj