Fabrice Drouin [ARCHIVE] on Nostr: đź“… Original date posted:2017-05-03 đź“ť Original message: Hi Rusty, Payment ...
đź“… Original date posted:2017-05-03
đź“ť Original message:
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 <pm+lists at acinq.fr> 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 <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
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170503/3885b9e8/attachment.html>;
đź“ť Original message:
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 <pm+lists at acinq.fr> 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 <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
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170503/3885b9e8/attachment.html>;