📅 Original date posted:2016-08-04
📝 Original message:
> Hmm, I think we should combine the "header" and "per-hop payload" into a
> single 40 byte field. They're not meaningfully distinct for lightning,
> AFAICT.
It's not clear to me what we gain by squashing the header (hop's ephemeral
key,
MAC, next hop) and the per-hop payload (amount to forward, possibly an
allowed
CLTV range, etc) into a single blob. I think the extensibility features are
the
same regardless.
> And I think we should add/steal at least one byte for "realm". 0 =
> terminal. 1 = bitcoin lightning. 2 = TBA. etc.
What does "terminal" represent in this context?
I don't think we need an equivalent of Bitcoin's "net magic" bytes within
the
onion blob itself, as I'd imagine that the onion blob would be encapsulated
within a fixed-length field within the "htlcAdd" message. The "htlcAdd"
message
would then have a header similar to Bitcoin's, in which the "net magic"
bytes
would be placed.
> We can't simply deny multiple HTLCs with the same r hash, since that
allows an
> attacker to probe the network to see where an HTLC went (note that in the
> longer run, it's in a node's short-term economic interest to allow this,
which
> is why rhash is troubling).
We wouldn't deny multiple HTLC's with the same r hash. We'd deny a packet
with
a shared secret we've already seen, meaning one that we've processed
before. A
node could still forward multiple HTLC's with identical r-hashes (perhaps
due
to having to fragment a payment due to insufficient link-capacity), these
HTLC's would have distinct (indistinguishable) onion packets.
(as a side note: I think we should establish some better terminology than
r-hash, or H)
> If we switch from hash/preimage to the privkeys with point addition scheme
> (which has other benefits) this is no longer an issue and we can simply
refuse
> to accept two HTLCs with the same pubkey.
The point addition derivation (P2CH style) scheme only applies to
revocations.
It's not clear to me how one can switch to priv/pub key based HTLC's without
modifying Bitcoin Script. At the moment, we're unable to guarantee/force key
disclosure with Script's current capabilities.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160804/34ecad88/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:46:24
in reply to nevent1q…fxsp
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:46:24Event JSON
{
"id": "3de2351d6370292006946a60dabe55e86dc0cf27fd0fa489564c3767f2bc61ad",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314784,
"kind": 1,
"tags": [
[
"e",
"f166a20039cde752a8ba4e6cccc22d4b2719f9a29840f0c295641243ae59d83f",
"",
"root"
],
[
"e",
"6fdd7db00bda4f4246c8073b20f373647d5e42d0ccea0c864f4fea2b954da62d",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-08-04\n📝 Original message:\n\u003e Hmm, I think we should combine the \"header\" and \"per-hop payload\" into a\n\u003e single 40 byte field. They're not meaningfully distinct for lightning,\n\u003e AFAICT.\n\nIt's not clear to me what we gain by squashing the header (hop's ephemeral\nkey,\nMAC, next hop) and the per-hop payload (amount to forward, possibly an\nallowed\nCLTV range, etc) into a single blob. I think the extensibility features are\nthe\nsame regardless.\n\n\u003e And I think we should add/steal at least one byte for \"realm\". 0 =\n\u003e terminal. 1 = bitcoin lightning. 2 = TBA. etc.\n\nWhat does \"terminal\" represent in this context?\n\nI don't think we need an equivalent of Bitcoin's \"net magic\" bytes within\nthe\nonion blob itself, as I'd imagine that the onion blob would be encapsulated\nwithin a fixed-length field within the \"htlcAdd\" message. The \"htlcAdd\"\nmessage\nwould then have a header similar to Bitcoin's, in which the \"net magic\"\nbytes\nwould be placed.\n\n\u003e We can't simply deny multiple HTLCs with the same r hash, since that\nallows an\n\u003e attacker to probe the network to see where an HTLC went (note that in the\n\u003e longer run, it's in a node's short-term economic interest to allow this,\nwhich\n\u003e is why rhash is troubling).\n\nWe wouldn't deny multiple HTLC's with the same r hash. We'd deny a packet\nwith\na shared secret we've already seen, meaning one that we've processed\nbefore. A\nnode could still forward multiple HTLC's with identical r-hashes (perhaps\ndue\nto having to fragment a payment due to insufficient link-capacity), these\nHTLC's would have distinct (indistinguishable) onion packets.\n\n(as a side note: I think we should establish some better terminology than\nr-hash, or H)\n\n\u003e If we switch from hash/preimage to the privkeys with point addition scheme\n\u003e (which has other benefits) this is no longer an issue and we can simply\nrefuse\n\u003e to accept two HTLCs with the same pubkey.\n\nThe point addition derivation (P2CH style) scheme only applies to\nrevocations.\nIt's not clear to me how one can switch to priv/pub key based HTLC's without\nmodifying Bitcoin Script. At the moment, we're unable to guarantee/force key\ndisclosure with Script's current capabilities.\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160804/34ecad88/attachment-0001.html\u003e",
"sig": "5635cda360963dfd077122c255f0595d9a81c16966000836faadcbf352ae1cbf1de19a4a0d296ceca1d7ffea5ada0dbcc58cb2c625583e711ab6111d1d67923b"
}