Comments on BOLT#11 [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2017-12-18T05:20:35+00:00


Summary:

The Lightning Network Daemon API does not include data in the payment request, leading to htlc.me storing data in the description field. Rusty Russell believes this is an incorrect API implementation and suggests that c-lightning does not store descriptions in the database; instead, it uses a label specified by the invoice creator. Htlc me separates its balance into user accounts outside of Lightning and uses an identifier to link user information with the payment request status. Jon, a developer, seeks edge cases for his bitcoinjs/bolt11 project related to Bitcoin and Lightning Network payments.In a discussion thread, Jonathan Underwood suggests that the invoice description may be used to link user data and payment hashes. Rusty notes that when he sends payments, only the payment hash is received. HTLC.me, which separates its balance into user accounts, uses the description field to join user data and payment hash on their end. However, Rusty suggests that this practice is understandable but not ideal for an API. Alex Bosworth is the owner of HTLC.me and uses descriptions to store user information locally. Rusty urges HTLC.me to fix the violation of using the description field for purposes other than intended.Jonathan Underwood proposes hiding certain text in payment request descriptions under specific conditions and adding an "extra data" tag. Rusty suggests that HTLC.me should have a description entry field in their "Request Payment" form to avoid violating specifications. In an email exchange with Johan Torås Halseth, Underwood shares a payment request made using UTF-8 description and discusses potential improvements to BOLT#11. There is a suggestion to set a max length for invoices and add UTF-8 support.Johan from the Lightning-dev mailing list suggests setting a reasonable maximum length for invoices and agrees on UTF-8 support. He questions including the description hash URL in the invoice and suggests it should be used between clients who have already agreed on payment for data. Jonathan Underwood shares code for a payment request using UTF-8 descriptions and provides the results of the request.Rusty and Jon discuss various topics related to the Lightning Network, including decoding process, properly formatted signatures, clear descriptions of payments, and maximum field size. They also discuss the inclusion of a URL in payment requests and its potential de-anonymizing effects. Jon proposes hiding text in descriptions and adding an "extra data" tag.Jonathan Underwood implements BOLT11 in Node.js and receives comments regarding the implementation. The user suggests adding a tags_length integer and debates whether the description or description commit hash should be included as a tag. Full unicode support via UTF8 is recommended, along with a maximum length for descriptions. Test cases for the RFC and adding signature preimage hex data to examples are proposed to improve the implementation.In a conversation between Jonathan Underwood and ZmnSCPxj, they discuss the use of UTF-8 encoding for descriptions in Bitcoin transactions. Underwood argues for mentioning naive implementations that do not follow the UTF-8 spec to avoid corruption. The purpose of the commit hash and Unicode normalization are discussed. ZmnSCPxj warns about being precise in choosing the variant of UTF8 and suggests considering Modified UTF8 or disallowing null characters. The issue of Unicode normalization and ASCII usage is also mentioned.A developer implements BOLT11 in Node.js and shares it on Github. The implementation is still in progress, with tests being developed and possible changes to the encode function. Suggestions include adding a tags_length integer, supporting full Unicode via UTF8, implementing a maximum length for descriptions, and specifying ways for parsing clients to fetch committed purpose description data. Additional test cases for the RFC and a pull request for adding signature preimage hex data to examples are proposed. The developer's PGP public key block is provided for secure communication.


Updated on: 2023-07-31T19:31:11.407572+00:00