[Lightning-dev] [RFC] Lightning payment format

[Pierre]

>> 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