Published on: 2017-06-01T05:25:57+00:00
ZmnSCPxj reported a doubled "than" in Bolt#11 at line 20 and expressed their confusion regarding the encoding of the tagged `d` field, which lacks a clear description and examples. They suggest including the proper encoding details in the BOLT documentation. Additionally, ZmnSCPxj corrected their understanding of bech32, realizing that the character "1" serves as a separator between the human-readable and data parts, rather than being allowed in the data part. They apologized for any confusion caused by their previous message.The letter delves into the potential challenges of parsing the optional amount in lightning invoices due to the use of the separator character "1" for both human-readable and data parts. Upgrading the version could lead to ambiguity, such as whether a payment starting with lnbc1p represents a 1 pico-bitcoin payment or an arbitrary payment to a version-1 data part. To address this, the suggestion is made to fix the first 5 bits as 0, providing a clear separator between the two parts. The author also questions the claim that lightning invoices are optimized for human errors, pointing out that they are longer than segwit addresses and thus more prone to errors. They propose rewording the statement to clarify that human errors are less likely compared to other types of errors.In relation to the lightning network, there is a pull request for a lightning payment format that requires wider review. This payment method is encoded using bech32 and includes optional tagged parts. Rustyrussell has created an implementation of the payment format, along with a less formal description, which can be found on Github. An example of the payment format is provided within the post.
Updated on: 2023-07-31T19:21:08.612587+00:00