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