Published on: 2018-11-05T08:23:10+00:00
The sender of the email proposes that writing things in human-readable form in the description field can achieve most of their proposal. This would put things into a machine-readable form and aid automated processing and a better user interface experience. The key aspect of their proposal is the inclusion of a payer pubkey in the original invoice, which offers benefits such as turning a "proof-that-someone-paid" into a "proof-that-I-paid" and clearly identifying who is authorized to issue an invoice nullifying the original one.Requiring two signatures (payer and payee) on each update is suggested as a more generic approach than allowing one party to unilaterally nullify an old contract. This allows for obligations on both parties. The possibility of accommodating more than two parties in complex business arrangements is acknowledged but considered a topic for future consideration.The Lightning Network facilitates the creation of payment channels where parties can transact without broadcasting every transaction to the blockchain. A discussion on the lightning-dev mailing list addresses concerns about the current definition of the description field in BOLT11, which is vague and may require more details regarding obligations.BOLT11 payment requests are compared to option contracts, where the payee has an obligation to deliver what was described in the contract if payment occurs. However, issues arise when the payer's identity is not specified in the contract. To address this, two-way communication is proposed, with the payer sending data to the payee, who then includes this data in the payment request. This establishes proof that the payee has an obligation to the payer.While proofs of payment are useful, they may lack flexibility in real-life applications. There may be cases where agreements need to be updated or revoked even after payment. In such scenarios, a "contract update" format is suggested. This format would include new obligations of the parties, a secure hash of the previous contract version, signatures from both parties, and optionally, a payment hash. Several conditions must be met for the contract update to be considered valid, including verifying signatures and ensuring the validity of previous contracts in the chain.The potential issue with the "contract update chain" is that it can fork. However, this can be avoided by not signing the forking update. The description field in BOLT11, which is defined as a "complete description of the purpose of the payment," is acknowledged as potentially vague. The concept of a BOLT11 payment request as an option contract is recognized, but the lack of payer identification in the contract is seen as problematic. Two-way communication is again proposed as the solution.In conclusion, the sender of the email suggests using human-readable descriptions and including a payer pubkey in the original invoice to achieve their proposal. They emphasize the importance of two-way communication to establish payer identification and propose a "contract update" format to accommodate changes and revocations even after payment. The potential issue of a "contract update chain" forking is addressed, and the need for clearer details regarding obligations in the description field of BOLT11 is highlighted.
Updated on: 2023-07-31T20:38:53.946937+00:00