[RFC] Lightning payment format



Summary:

In a recent conversation regarding the Sphinx derived onion format, Olaoluwa Osuntokun suggested reintroducing the end-to-end payload in order to avoid needing to shave off bytes from the per-hop payload later on. This was removed in a previous version due to its large size and lack of clear use case at the time. However, some users have expressed interest in having this feature for mid-points as well. It was noted that it would be easy to extend to a "multi-cell" format in the future if needed.Fabrice also suggested adding a timestamp and expiry date to payment requests. The latest version has since included these features with the expiry time defaulting to one hour if not specified. While server-enforced, it saves senders from needing to extend an HTLC altogether.Regarding Schnorr signatures, Rusty initially believed they would lose the ability to include a recovery ID. However, after speaking with Pieter Wuille, it was determined that if modern practices are followed (making the signature hash commit to the public key), it is not possible to do so. It is possible, however, to commit to the pubkeyhash instead of the pubkey directly. Finally, Rusty proposed turning the changes into BOLT 11. As interoperability tests between implementations draw nearer, having a shared payment request format will be useful.


Updated on: 2023-05-24T01:14:04.308430+00:00