> > > 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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
