{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-09-21\n📝 Original message:\nProblem\n\nOne of the qualities of lightning is that it can provide light-weight,\nno-login payments with minimal friction. Games, paywalls, podcasts, etc can\nimmediately present a QR code that is ready for scan and pay.\n\nOptimistically presenting payment requests does lead to many of those\npayment requests going unused. A user visits a news site and decides not to\nbuy the article. The conventional approach is to create a lightning invoice\non a node and store the invoice together with order details in a database.\nIf the order then goes unfulfilled, cleaning processes remove the data from\nthe node and database again.\n\nThe problem with this setup is that it needs protection against unbounded\ngeneration of payment requests. There are solutions for that such as rate\nlimiting, but wouldn't it be nice if invoices can be generated without the\nneed to keep any state at all?\n\nStateless invoices\n\nWhat would happen if a lightning invoice is only generated and stored\nnowhere on the recipient side? To the user, it won't make a difference.\nThey would still scan and pay the invoice. When the payment arrives at the\nrecipient though, two problems arise:\n\n1. Recipient doesn't know whom or what the payment is for.\n\nThis can be solved by attaching additional custom tlv records to the htlc.\nOn the wire, this is all arranged for. The only missing piece is the\nability to specify additional data for that custom tlv record in a bolt11\ninvoice. One way would be to define a new tagged field for this in which\nthe recipient can encode the order details.\n\nAn alternative is to use the existing invoice description field and simply\nalways pass that along with the htlc as a custom tlv record.\n\nA second alternative that already works today is to use part (for example\n16 out of 32 bytes) of the payment_secret (aka payment address) to encode\nthe order details in. This assumes that the secret is still secret enough\nwith reduced entropy. Also there may not be enough space for every\napplication.\n\n2. Recipient doesn't know the preimage that is needed to settle the htlc(s).\n\nOne option is to use a keysend payment or AMP payment. In that case, the\nsender includes the preimage with the htlc. Unfortunately this doesn't\nprovide the sender with a proof of payment that they'd get with a regular\nlightning payment.\n\nAn alternative solution is to use a deterministic preimage based on a\n(recipient node key-derived) secret, the payment secret and other relevant\nproperties. This allows the recipient to derive the same preimage twice:\nOnce when the lightning invoice is generated and again when a payment\narrives.\n\nIt could be something like this:\n\npayment_secret = random\npreimage = H(node_secret | payment_secret | payment_amount |\nencoded_order_details)\ninvoice_hash = H(preimage)\n\nThe sender sends an htlc locked to invoice_hash for payment_amount and\npasses along payment_secret and encoded_order_details in a custom tlv\nrecord.\n\nWhen the recipient receives the htlc, they reconstruct the preimage\naccording to the formula above. At this point, all data is available to do\nso. When H(preimage) indeed matches the htlc hash, they can settle the\npayment knowing that this is an order that they committed to earlier.\nSettling could be implemented as a just-in-time inserted invoice to keep\nthe diff small.\n\nThe preimage is returned to the sender and serves as a proof of payment.\n\nResilience\n\nTo me it seems that stateless invoices can be a relatively simple way to\nimprove the resiliency of systems that deal with lightning invoices.\nUnlimited amounts of invoices can be generated without worrying about\nstorage or memory, no matter if the requests are due to popularity of a\nservice or a deliberate dos attack.\n\nInterested to hear your thoughts.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/788f449b/attachment-0001.html\u003e"}