[RFC] Lightning payment format



Summary:

Olaoluwa Osuntokun and Rusty have been discussing a proposal to utilize a tag-based payment request format in combination with either the spare bytes of the onion payload or an abuse of the encrypted back errors. Rusty had considered using the onion bytes but was hesitant due to their limited resource. Additionally, they discussed the use of bech32 character and agreed that it may not be necessary for this particular proposal, as payment requests can become rather long and are not likely to be entered by hand. However, they also acknowledged that code reuse may be a factor in utilizing bech32 anyway. The proposal includes a signature that covers the entire payreq, which would allow users to verify the validity of the signature and authenticity of the payreq and integrity of the contents. However, a user would need a (direction || chanID) -> pubKey mapping in order to do so. Olaoluwa suggested replacing the chanID with the compressed serialized public key to allow users to immediately verify the signature without the use of an external mapping. Rusty agreed and also mentioned that key recovery from the signature is possible.Overall, they both agreed that the proposal is a step in the right direction but noted that the encoding used may not carry over compelling traits to the LN payreq use-case. Additionally, Rusty mentioned that the same technique could be used to remove node-id and bitcoin-key from the channel announcement, which would be beneficial.


Updated on: 2023-05-24T01:11:17.144089+00:00