Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-01 📝 Original message: Hi Rusty, I was thinking ...
📅 Original date posted:2017-05-01
📝 Original message:
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).
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.
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.
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.
-- Laolu
On Fri, Apr 28, 2017 at 5:57 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> I threw together this draft format for requesting lightning
> payments, and an (incomplete) implementation:
>
> - https://github.com/rustyrussell/lightning-payencode
>
> The representation size ranges from ~181 characters upwards: we could
> squeeze at least 5 of those out if we cared. Bech32 only guarantees to
> detect 3 errors at these lengths (beyond 1024 it's only 1), but the
> signature is the final error detection.
>
> You'll notice one optimization for the common case: we use the 8-byte
> chanid (stealing 1 bit) to compactly refer to the destination. This is
> shorter than a full 33-byte pubkey, and relies on the fact that the
> network topology is well-known. We use these same style of IDs in
> the channel announcement messages already.
>
> I look forward to both the bikeshed comments, and more substantive
> feedback :)
>
> Thanks!
> Rusty.
> _______________________________________________
> 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/20170501/98cf78f1/attachment.html>;
📝 Original message:
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).
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.
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.
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.
-- Laolu
On Fri, Apr 28, 2017 at 5:57 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> I threw together this draft format for requesting lightning
> payments, and an (incomplete) implementation:
>
> - https://github.com/rustyrussell/lightning-payencode
>
> The representation size ranges from ~181 characters upwards: we could
> squeeze at least 5 of those out if we cared. Bech32 only guarantees to
> detect 3 errors at these lengths (beyond 1024 it's only 1), but the
> signature is the final error detection.
>
> You'll notice one optimization for the common case: we use the 8-byte
> chanid (stealing 1 bit) to compactly refer to the destination. This is
> shorter than a full 33-byte pubkey, and relies on the fact that the
> network topology is well-known. We use these same style of IDs in
> the channel announcement messages already.
>
> I look forward to both the bikeshed comments, and more substantive
> feedback :)
>
> Thanks!
> Rusty.
> _______________________________________________
> 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/20170501/98cf78f1/attachment.html>;