Published on: 2017-05-29T10:48:51+00:00
The discussion revolves around various proposals and suggestions to optimize the Lightning Network payment requests and improve their usability. One proposal is to reintroduce the end-to-end (e2e) payload for Sphinx derived onion format. The e2e payload was previously removed due to its large size and lack of clear use case, but now there is interest in having this feature for mid-points as well. It is suggested that the e2e payload should be around 200 bytes, allowing a strict separation of layers with h2h payload for critical information and e2e payload for relevant data. This could potentially be extended to a "multi-cell" format in the future.Another suggestion is to add a timestamp and expiry date to payment requests. The latest version has included these features, with the expiry time defaulting to one hour if not specified. This saves senders from needing to extend an HTLC (Hashed Time-Locked Contract) altogether.There is also a discussion about using BTC with m (milli), u (micro), n (nano), and p (pico) instead of decimals. While this may be more concise, it is not ideal for coding purposes. It is proposed to use BOLT 11 as the shared payment request format, which would be useful for cross-implementation interoperability tests.The readability of invoices for Bitcoin transactions is also discussed. It is agreed to use BTC with m/u/n/p as modifiers instead of bech32. However, writing code to encode/decode this format proves to be challenging.Optimizing the Lightning Network payments is another topic of discussion. It is debated whether users can verify the validity of a signature without a mapping. Key recovery from the signature is suggested as a solution. The use of short chanID in the onion is also debated, as it assumes a well-known network and doesn't consider the time for announcements to propagate. The size optimization of payment requests is also questioned since they are sent out-of-band.The encoding used in Bitcoin addresses is critiqued for not carrying over to the Lightning Network payreq use-case. However, it is noted that the encoding is useful for QR codes and denser than hex. The example encoder/decoder now includes fallback addresses and a tweaked format. Ideas are welcomed to improve the encoding.The lightning-address.py script is discussed for generating Lightning Network invoices. It encodes transactions into bech32 format and includes options for description, amount, payment hash, and private key. It can also decode Lightning Network invoices.The proposal to replace chanID with compressed serialized public key is debated. Concerns are raised about users not being able to verify the signature without an external mapping. Key recovery from the signature is suggested as a solution. The use of bech32 and optimizing the size of payment requests is also discussed.There is a proposal to utilize a tag-based payment request format, either using spare bytes of the onion payload or an abuse of encrypted back errors. The flexibility of the tag format is appreciated, but it is acknowledged that the encoding used may not carry over compelling traits to the LN payreq use-case. Replacing chanID with the compressed serialized public key is suggested to allow users to immediately verify the signature without an external mapping.Overall, the various proposals and suggestions aim to optimize the Lightning Network payment requests, improve their readability and usability, and ensure the validity and authenticity of the transactions.The author of this post presents a draft format for requesting lightning payments, along with an incomplete implementation available on GitHub. The format uses an 8-byte chanid to refer to the destination instead of a full 33-byte pubkey. The author suggests that at least five characters could be squeezed out from the representation size, which ranges from approximately 181 characters upwards. However, it is noted that Bech32 only guarantees to detect three errors at these lengths (beyond 1024 it's only one), making the signature the final error detection.The author highlights an optimization for the common case by using the 8-byte chanid to compactly represent the destination. This is shorter than a full 33-byte pubkey and relies on the assumption that the network topology is well-known. The author mentions that these same style of IDs are already used in the channel announcement messages.In conclusion, the author welcomes feedback on both bikeshed comments and more substantive suggestions for improvement.
Updated on: 2023-07-31T19:17:39.629772+00:00