From fabrice.drouin at acinq.fr Wed May 3 15:37:14 2017 From: fabrice.drouin at acinq.fr (Fabrice Drouin) Date: Wed, 3 May 2017 17:37:14 +0200 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: References: <87h918ghdv.fsf@rustcorp.com.au> <87ziewf5vy.fsf@rustcorp.com.au> Message-ID: Hi Rusty, Payment requests should also include a timestamp and an expiry date (they could be optional tagged items but I think it makes more sense to make them mandatory) ? Thanks! Fabrice? On 2 May 2017 at 18:11, Pierre wrote: > >> 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 : > > Olaoluwa Osuntokun 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: