Published on: 2021-09-23T09:48:06+00:00
The Lightning Network, known for its light-weight and no-login payments, faces challenges with unutilized payment requests. The conventional approach involves storing lightning invoices in a database, but this requires protection against unlimited payment request generation. To address this issue, stateless invoices can be generated without storing any state. Redis or elkrem/shachain can be used to generate deterministic payment hashes, and unique elkrem/shachain states can be maintained for each user to save space and reproduce proof of payment statements.In an email exchange between Bastien TEINTURIER and Joost Jager, they discuss the potential usefulness of invoice storage as a vector for Denial-of-Service (DoS) attacks. They suggest attaching metadata to Lightning Network payments and rethinking design patterns for ecommerce applications. They also discuss the implementation of a "stateless invoice" API and the use of encoded order details. Examples of information that could be put in the encoded_order_details field are requested, and various workarounds and application-specific solutions are discussed.Another email exchange between fiatjaf and Joost Jager discusses proposals related to Lightning Network payments. One proposal suggests offering a "stateless invoice" API for receiving payments using the payment_secret. The second proposal involves attaching TLV records with encoded order details when sending payments. Application-specific workarounds such as encoding order details minimally in the payment secret or using lnurlpay to reduce invoice issuance delay are discussed. Joost mentions that he has prototyped a stateless invoice API in lnd, and both proposals aim to improve the Lightning Network payment process.The conversation between Bastien TEINTURIER and Joost Jager discusses the implementation of stateless invoices in the Lightning Network. The proposal suggests that payees should generate stateless invoices using a secret to compute the preimage upon receiving the HTLC. Implementations should provide a "stateless invoice" API for receiving payments using the payment_secret, and TLV records with encoded order details should be attached when sending payments. Various workarounds, including fixed sets of possible orders and storing order details on Redis for a limited time, are discussed. Joost Jager mentions implementing a stateless invoice API in lnd and its potential benefits.The Lightning Network is praised for its ability to provide light-weight, no-login payments. However, protection against unlimited generation of payment requests is needed. Stateless invoices are proposed as a solution, allowing invoices to be generated without storing any state. Additional custom TLV records or part of the payment secret can be used to encode order details. Proof of payment can be achieved through deterministic preimages. Joost Jager has implemented a scheme on @lntxbot, but it required low-level code and a route hint hack. Stateless invoices can improve resiliency and allow for unlimited invoice generation without storage concerns.A payment protocol using Hash Time-Locked Contracts (HTLCs) is described, where the sender locks an HTLC to a hash of a preimage constructed using various inputs. Upon receiving the HTLC, the recipient reconstructs the preimage and settles the payment if the hash matches. The preimage also serves as proof of payment. An email thread discusses the implementation of a "pay-for-signature" protocol using PTLCs, but it is revealed that it cannot work as intended. Alternative mechanisms are suggested, such as using two scalars for payment and generating a proof-of-payment locked to a specific scalar.The proposed payment scheme involves the sender locking an HTLC to a preimage computed from various inputs. The recipient reconstructs the preimage upon receiving the HTLC and settles the payment if the hash matches. The preimage also serves as proof of payment. The goal is to alleviate the recipient from storing invoices, and the scheme requires the sender to request an invoice to learn the invoice hash. A discussion on point shenanigans and PTLCs reveals that they may not be suitable, but alternative protocols for pay-for-signature and proof-of-payment are suggested.A BOLT12 protocol is described, where the sender provides payment_secret and encoded_order_details to the recipient for a payment. The recipient constructs a preimage using several inputs and settles the payment. The invoice_hash is used to lock HTLC(s) and is learned by the sender from a BOLT11 invoice. The possibility of a "pay-for-signature" protocol using PTLCs is discussed, along with alternative mechanisms for proof-of-payment.
Updated on: 2023-07-31T23:49:19.273738+00:00