From pm+lists at acinq.fr Tue May 2 16:11:29 2017 From: pm+lists at acinq.fr (Pierre) Date: Tue, 2 May 2017 18:11:29 +0200 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: <87ziewf5vy.fsf@rustcorp.com.au> References: <87h918ghdv.fsf@rustcorp.com.au> <CAO3Pvs_FqtAjONw+_amy_wfhY_BDgaRKoNHE_jdfv-F9EVQkzA@mail.gmail.com> <87ziewf5vy.fsf@rustcorp.com.au> Message-ID: <CAMXsxZMr-X3Oy8weBJmuEsZ00G8hxXjDTOxry3uszvF0sKY-LQ@mail.gmail.com> >> On the topic of signatures: as is proposed now, a user isn't able to verify >> the validity of the signature (and thereby authenticity of the payreq and >> integrity of the contents) without first having a (direction || chanID) -> >> pubKey mapping. In my opinion, the payreqs are already so long that >> optimizing for size is a bit of a waste. By replacing the chanID with the >> compressed serialized public key, users will be able to immediately verify >> the signature without the use of an external mapping. As much as I pushed for using the short chanID in the onion, I too am a reluctant to use it here. In addition to laolu's arguments, I would say: - making the assumption that the network is well-known doesn't take into account the fact that announcements take time to propagate through the network (typically a few minutes with staggered broadcast every minute); ok it doesn't change often, but now we will need to worry about not using our most recently created/closed channels as reference. - we already know that we won't always be able to have a full view of the network in the future, so I feel like we should rely on it as less as possible - since payment requests are sent out-of-band, optimizing their size is maybe not as important as messages exchanged on the p2p network? >As you pointed out offline, we can do key recovery from the signature[1], >so the information is there already in fact :) The chanid is really a >courtesy, from this POV. That is really amazing! Why not completely ditch the chanid then? ;-) Cheers, Pierre 2017-05-02 2:40 GMT+02:00 Rusty Russell <rusty at rustcorp.com.au>: > Olaoluwa Osuntokun <laolu32 at gmail.com> writes: >> Hi Rusty, >> >> I was thinking of proposing something similar recently, but looks like you >> beat me to it! >> >> I really like the flexibility of the tag format. Over the past few months, I >> thought of quite a bit of things application developers can do by utilizing >> a tag-based payment request format in conjunction with either: the spare >> bytes of the onion payload or an abuse of the encrypted back errors (in >> combo with some onion payload bytes). > > Yes, I thought about this too, but I'm reluctant to assign those onion > bytes as they're a limited resource. Easy to add later, though. > >> On the topic of bech32: I'm all for piggybacking on existing emerging >> standards in the space, but I'm not convinced we really gain anything by >> using it outside of the initial prefix. The human-readable amount within the >> prefix is nice for UX as you can eyeball exactly how much one is about to >> pay/receive. However, these payment requests can get rather long, so I don't >> envision any user typing them out by hand or reading them to someone over >> the phone. As a result, I don't think we have much use for bech32 character >> which has been optimized for manual-entry. Additionally, as this proposal >> includes a signature that covers the entire payreq, what's the use of the >> added checksum? Detecting 3 characters out of 1024+ is rather >> insignificant. > > I kind of agree, but I think the code reuse outweighs other arguments, > since codebases are going to have bech32 anyway. > > The minimal theoretical size we can do is 20 (payment hash160) + 64 > (signature). We'd have to change the protocol to use hash160 instead of > sha256 (we already do this onchain). But even that is 135 characters, > which is not going to be entered by hand, so I don't think it's worth > it. > >> On the topic of signatures: as is proposed now, a user isn't able to verify >> the validity of the signature (and thereby authenticity of the payreq and >> integrity of the contents) without first having a (direction || chanID) -> >> pubKey mapping. In my opinion, the payreqs are already so long that >> optimizing for size is a bit of a waste. By replacing the chanID with the >> compressed serialized public key, users will be able to immediately verify >> the signature without the use of an external mapping. > > As you pointed out offline, we can do key recovery from the signature[1], > so the information is there already in fact :) The chanid is really a > courtesy, from this POV. > >> I think this is a good step in the right direction. However, it utilizes an >> encoding whose rationale make sense for the Bitcoin address use-case, but in >> my opinion, doesn't carry over those compelling traits to the LN payreq >> use-case. > > Thanks! > Rusty. > [1] You also pointed out that we can use the same technique to remove > node-id and bitcoin-key from the channel announcement. Which would > be awesome magic... > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev