From rusty at rustcorp.com.au Mon May 29 10:48:51 2017 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 29 May 2017 20:18:51 +0930 Subject: [Lightning-dev] [RFC] Lightning payment format In-Reply-To: References: <87h918ghdv.fsf@rustcorp.com.au> <87h90yeieo.fsf@rustcorp.com.au> <20170508112529.GA28181@nex> <87y3u624kn.fsf@rustcorp.com.au> <20170509082241.GA21968@nex> <87vap9zdet.fsf@rustcorp.com.au> Message-ID: <87poesym3w.fsf@rustcorp.com.au> Olaoluwa Osuntokun writes: > Rusty wrote: >> 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. > > If y'all recall, the initial version of the Sphinx derived onion format > included an end-to-end payload. In the first revision, removed this > payload as at the time it was very large (1KB iirc), an at the time, we > didn't see nay clear use case for such a payload (and also due to MTU > constraints?). In my opinion, we should re-introduce this payload so we > aren't put into a corner where we need to shave bytes off of the per-hop > payload in order to accommodate application level schemes/apps. Unfortunately people want this for mid-points, too, to do weird crazy shit. But it's trivial for us to extend to a "multi-cell" format in future, so I'm tempted by the default of "no change"? > Fabrice wrote: >> 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) > > Agreed that that would make for a really useful tag. I had a user which > was making a store on lnd request such a feature as his use-case depended > on users only having a particular time window to make the payment. This > could of course be enforced server side, but allow senders to enforce it > at the origin of the payment saves them from extending an HTLC all > together. Agreed. Latest version has a UTC timestamp, and expiry time (defaults to 1 hour if not specified). As you say, must be server-enforced too, but it's nice to make it clear to the user (and it's signed in case of dispute). > Rusty wrote: >> Note: we will lose this ability when we switch to Schnorr, apparently. > > AFAIK, this isn't the case. With Schnorr signatures (that include the > entire point, instead of the hash), we actually won't need to include a > recovery ID at all. Quoting a private conversation with Pieter Wuille, when I asked him about it: You can't. At least, if you follow modern practices (which make the signature hash commit to the public key), you can't do pubkey recovery. It *is* possible (and safe, I think) to commit to the pubkeyhash rather than the pubkey directly, in which case you can verify a (signature, pubkeyhash, msg) triplet. I think you can use a 128-bit pubkey hash, actually. > Rusty wrote: >> OK, if people like this change, I think we can move start turning this >> into BOLT 10? > > Let's do it (BOLT 11)! As were all getting pretty close to the stage of > cross-implementation interoperability tests, having a shared payment > request format will be super useful. OK, I'll start typing... Thanks! Rusty.