Published on: 2017-06-01T05:54:37+00:00
Rusty Russell has submitted a pull request on GitHub for review of a lightning payment format. The format is bech32 encoded and includes optional parts tagged with a URI scheme, similar to the existing "bitcoin:" scheme. This proposed format also includes a MIME type for usage in NFC NDEF messages or emails. The author has provided an example payment in the pull request, demonstrating how to send 2500 microbitcoin using a specific payment hash to a specific recipient within a specific time frame. Rusty has requested wider review on the pull request.ZmnSCPxj corrects their understanding of the bech32 specification in a message. They clarify that the character "1" is not allowed in the data part, as previously thought. The last "1" digit in the bech32 string serves as a separator between the human-readable and data parts. ZmnSCPxj apologizes for any confusion caused by their previous statement.Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32 in an email exchange. They note that the separator character between the human-readable and data parts is the character "1", which may cause problems when upgrading versions. Currently, version 0 translates to the character "q" appearing after "1", indicating that 1q is not an amount and starts the data part. However, if version 1 is available, a payment starting with lnbc1p could indicate a 1 pico-bitcoin payment or an arbitrary payment to a version-1 data part. ZmnSCPxj questions the necessity of limiting the use of the character "1" for the amount and suggests fixing the first 5 bits to be 0 as an unambiguous separator. They also discuss the assertion that lightning invoices are less prone to human error compared to QR reader errors due to their length.In summary, Rusty Russell has made a pull request for review of a lightning payment format that is bech32 encoded with optional parts tagged. ZmnSCPxj corrects their understanding of the bech32 specification, clarifying that the character "1" is not allowed in the data part. Rusty and ZmnSCPxj discuss potential issues with parsing optional amounts in bech32, including the use of the character "1" as a separator between human-readable and data parts. The author has requested wider review on the pull request, which includes an example payment.
Updated on: 2023-08-01T20:49:13.414346+00:00