[Lightning-dev] [RFC] Lightning payment format

[Rusty Russell]

Olaoluwa Osuntokun <laolu32 at gmail.com> 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.