📅 Original date posted:2017-05-02
📝 Original message:
>> 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
Pierre [ARCHIVE] /
npub1yz…y4pdt
2023-06-09 12:47:09
in reply to nevent1q…kls5
Author Public Key
npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdtPublished at
2023-06-09 12:47:09Event JSON
{
"id": "d651b621295fbf039fc3f7bcace3fba31d5654023ce730f62ccbcc653435d128",
"pubkey": "208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff",
"created_at": 1686314829,
"kind": 1,
"tags": [
[
"e",
"56742c88f6265e0090cd0ac17729d1bb4693d9767822b89dc939db0c32d43bbb",
"",
"root"
],
[
"e",
"1dce506a3002bac5abea35b65095cb1c1fe529ca2f37db1eb1ee45727884bc57",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2017-05-02\n📝 Original message:\n\u003e\u003e On the topic of signatures: as is proposed now, a user isn't able to verify\n\u003e\u003e the validity of the signature (and thereby authenticity of the payreq and\n\u003e\u003e integrity of the contents) without first having a (direction || chanID) -\u003e\n\u003e\u003e pubKey mapping. In my opinion, the payreqs are already so long that\n\u003e\u003e optimizing for size is a bit of a waste. By replacing the chanID with the\n\u003e\u003e compressed serialized public key, users will be able to immediately verify\n\u003e\u003e the signature without the use of an external mapping.\n\nAs much as I pushed for using the short chanID in the onion, I too am\na reluctant to use\nit here. In addition to laolu's arguments, I would say:\n- making the assumption that the network is well-known doesn't take\ninto account the fact\nthat announcements take time to propagate through the network\n(typically a few minutes with\nstaggered broadcast every minute); ok it doesn't change often, but now\nwe will need to worry\nabout not using our most recently created/closed channels as reference.\n- we already know that we won't always be able to have a full view of\nthe network in\nthe future, so I feel like we should rely on it as less as possible\n- since payment requests are sent out-of-band, optimizing their size\nis maybe not as\nimportant as messages exchanged on the p2p network?\n\n\u003eAs you pointed out offline, we can do key recovery from the signature[1],\n\u003eso the information is there already in fact :) The chanid is really a\n\u003ecourtesy, from this POV.\n\nThat is really amazing! Why not completely ditch the chanid then? ;-)\n\nCheers,\n\nPierre\n\n2017-05-02 2:40 GMT+02:00 Rusty Russell \u003crusty at rustcorp.com.au\u003e:\n\u003e Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e\u003e Hi Rusty,\n\u003e\u003e\n\u003e\u003e I was thinking of proposing something similar recently, but looks like you\n\u003e\u003e beat me to it!\n\u003e\u003e\n\u003e\u003e I really like the flexibility of the tag format. Over the past few months, I\n\u003e\u003e thought of quite a bit of things application developers can do by utilizing\n\u003e\u003e a tag-based payment request format in conjunction with either: the spare\n\u003e\u003e bytes of the onion payload or an abuse of the encrypted back errors (in\n\u003e\u003e combo with some onion payload bytes).\n\u003e\n\u003e Yes, I thought about this too, but I'm reluctant to assign those onion\n\u003e bytes as they're a limited resource. Easy to add later, though.\n\u003e\n\u003e\u003e On the topic of bech32: I'm all for piggybacking on existing emerging\n\u003e\u003e standards in the space, but I'm not convinced we really gain anything by\n\u003e\u003e using it outside of the initial prefix. The human-readable amount within the\n\u003e\u003e prefix is nice for UX as you can eyeball exactly how much one is about to\n\u003e\u003e pay/receive. However, these payment requests can get rather long, so I don't\n\u003e\u003e envision any user typing them out by hand or reading them to someone over\n\u003e\u003e the phone. As a result, I don't think we have much use for bech32 character\n\u003e\u003e which has been optimized for manual-entry. Additionally, as this proposal\n\u003e\u003e includes a signature that covers the entire payreq, what's the use of the\n\u003e\u003e added checksum? Detecting 3 characters out of 1024+ is rather\n\u003e\u003e insignificant.\n\u003e\n\u003e I kind of agree, but I think the code reuse outweighs other arguments,\n\u003e since codebases are going to have bech32 anyway.\n\u003e\n\u003e The minimal theoretical size we can do is 20 (payment hash160) + 64\n\u003e (signature). We'd have to change the protocol to use hash160 instead of\n\u003e sha256 (we already do this onchain). But even that is 135 characters,\n\u003e which is not going to be entered by hand, so I don't think it's worth\n\u003e it.\n\u003e\n\u003e\u003e On the topic of signatures: as is proposed now, a user isn't able to verify\n\u003e\u003e the validity of the signature (and thereby authenticity of the payreq and\n\u003e\u003e integrity of the contents) without first having a (direction || chanID) -\u003e\n\u003e\u003e pubKey mapping. In my opinion, the payreqs are already so long that\n\u003e\u003e optimizing for size is a bit of a waste. By replacing the chanID with the\n\u003e\u003e compressed serialized public key, users will be able to immediately verify\n\u003e\u003e the signature without the use of an external mapping.\n\u003e\n\u003e As you pointed out offline, we can do key recovery from the signature[1],\n\u003e so the information is there already in fact :) The chanid is really a\n\u003e courtesy, from this POV.\n\u003e\n\u003e\u003e I think this is a good step in the right direction. However, it utilizes an\n\u003e\u003e encoding whose rationale make sense for the Bitcoin address use-case, but in\n\u003e\u003e my opinion, doesn't carry over those compelling traits to the LN payreq\n\u003e\u003e use-case.\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e [1] You also pointed out that we can use the same technique to remove\n\u003e node-id and bitcoin-key from the channel announcement. Which would\n\u003e be awesome magic...\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "3b74e80b643ad88794229ab581f76bd8dd8d20a33a0aad99f8d6c83b4151f3eb750905aae18111b51141741541138ac934eec944a4b0c02cc3d4fd0f25c23eb1"
}