rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 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>