Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-01 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2017-05-01
📝 Original message:
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...
📝 Original message:
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...