[RFC] Lightning invoice/payment format draft



Summary:

In this email exchange, Rusty and ZmnSCPxj discuss the potential issues with parsing of optional amounts in bech32. They note that the separator character between human-readable and data 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 whether the limitation on using character "1" for the amount is necessary and suggests fixing the first 5 bits to be 0 as an unambiguous separator. Additionally, they discuss the assertion that lightning invoices are less prone to human error due to their length compared to QR reader errors.


Updated on: 2023-06-12T01:28:53.311985+00:00