Author: Olaoluwa Osuntokun 2017-05-01 18:03:08
Published on: 2017-05-01T18:03:08+00:00
Laolu is responding to Rusty's draft format for requesting lightning payments and implementation. He expresses his appreciation for the flexibility of the tag format and discusses how developers can utilize tag-based payment requests in conjunction with either spare bytes of the onion payload or an abuse of the encrypted back errors. Laolu also shares his opinion on using bech32 outside of the initial prefix and questions its usefulness since payment requests can get long, making manual entry unlikely. He also suggests replacing chanID with the compressed serialized public key to enable users to immediately verify the signature without the use of an external mapping.Rusty's draft format for requesting lightning payments uses an 8-byte chanid to refer to the destination instead of a full 33-byte pubkey, and it relies on the fact that the network topology is well-known. The representation size ranges from ~181 characters upwards, and at least 5 characters could be squeezed out if optimization was necessary. Bech32 only guarantees to detect three errors beyond 1024, but the signature serves as the final error detection. Rusty welcomes feedback on the draft format.
Updated on: 2023-05-19T15:59:55.743544+00:00