📅 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...
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:47:09
in reply to nevent1q…9lkd
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:47:09Event JSON
{
"id": "1dce506a3002bac5abea35b65095cb1c1fe529ca2f37db1eb1ee45727884bc57",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314829,
"kind": 1,
"tags": [
[
"e",
"56742c88f6265e0090cd0ac17729d1bb4693d9767822b89dc939db0c32d43bbb",
"",
"root"
],
[
"e",
"f58992d3fcf711ba0999def69531e66e95d8750d982d8e1ee43872b2957fe1f3",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2017-05-01\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e I was thinking of proposing something similar recently, but looks like you\n\u003e beat me to it!\n\u003e\n\u003e I really like the flexibility of the tag format. Over the past few months, I\n\u003e thought of quite a bit of things application developers can do by utilizing\n\u003e a tag-based payment request format in conjunction with either: the spare\n\u003e bytes of the onion payload or an abuse of the encrypted back errors (in\n\u003e combo with some onion payload bytes).\n\nYes, I thought about this too, but I'm reluctant to assign those onion\nbytes as they're a limited resource. Easy to add later, though.\n\n\u003e On the topic of bech32: I'm all for piggybacking on existing emerging\n\u003e standards in the space, but I'm not convinced we really gain anything by\n\u003e using it outside of the initial prefix. The human-readable amount within the\n\u003e prefix is nice for UX as you can eyeball exactly how much one is about to\n\u003e pay/receive. However, these payment requests can get rather long, so I don't\n\u003e envision any user typing them out by hand or reading them to someone over\n\u003e the phone. As a result, I don't think we have much use for bech32 character\n\u003e which has been optimized for manual-entry. Additionally, as this proposal\n\u003e includes a signature that covers the entire payreq, what's the use of the\n\u003e added checksum? Detecting 3 characters out of 1024+ is rather\n\u003e insignificant.\n\nI kind of agree, but I think the code reuse outweighs other arguments,\nsince codebases are going to have bech32 anyway.\n\nThe minimal theoretical size we can do is 20 (payment hash160) + 64\n(signature). We'd have to change the protocol to use hash160 instead of\nsha256 (we already do this onchain). But even that is 135 characters,\nwhich is not going to be entered by hand, so I don't think it's worth\nit.\n\n\u003e On the topic of signatures: as is proposed now, a user isn't able to verify\n\u003e the validity of the signature (and thereby authenticity of the payreq and\n\u003e integrity of the contents) without first having a (direction || chanID) -\u003e\n\u003e pubKey mapping. In my opinion, the payreqs are already so long that\n\u003e optimizing for size is a bit of a waste. By replacing the chanID with the\n\u003e compressed serialized public key, users will be able to immediately verify\n\u003e the signature without the use of an external mapping.\n\nAs you pointed out offline, we can do key recovery from the signature[1],\nso the information is there already in fact :) The chanid is really a\ncourtesy, from this POV.\n\n\u003e I think this is a good step in the right direction. However, it utilizes an\n\u003e encoding whose rationale make sense for the Bitcoin address use-case, but in\n\u003e my opinion, doesn't carry over those compelling traits to the LN payreq\n\u003e use-case.\n\nThanks!\nRusty.\n[1] You also pointed out that we can use the same technique to remove\n node-id and bitcoin-key from the channel announcement. Which would\n be awesome magic...",
"sig": "c3aff4eb81e3197153345d68193c03b324754b07597add82b5c9fd7969ac9a567cbfe74670ab220d61b02435a270ad27e6299c30717102d683e0bf07184fa349"
}