📅 Original date posted:2022-11-03
📝 Original message:
Hi Joost,
This is a very interesting proposal that elegantly solves the problem, with
however a very significant size increase. I can see two ways to keep the
size small:
- Each node just adds its hmac in a naive way, without deleting any part of
the message to relay. You seem to have disqualified this option because it
increases the size of the relayed message but I think it merits more
consideration. It is much simpler and the size only grows linearly with the
length of the route. An intermediate node could try to infer its position
relative to the failing node (which should not be the recipient) but
without knowing the original message size (which can easily be randomized
by the final node), is that really such a problem? It may be but I would
argue it's a good trade-off.
- If we really want to keep the constant size property, as you've suggested
we could use a low limit on the number of nodes. I would put the limit even
lower, at 8 or less. We could still use longer routes but we would only get
hmacs for the first 8 hops and revert to the legacy system if the failure
happens after the first 8 hops. That way we keep the size low and 8 hops
should be good enough for 99% of the payments, and even when there are more
hops we would know that the first 7 hops are clean.
Thanks again for your contribution, I hope we'll soon be able to attribute
failures trustlessly.
Thomas
Le mar. 1 nov. 2022 à 22:10, Joost Jager <joost.jager at gmail.com> a écrit :
> Hey Rusty,
>
> Great to hear that you want to try to implement the proposal. I can polish
> my golang proof of concept code a bit and share if that's useful? It's just
> doing the calculation in isolation. My next step after that would be to see
> what it looks like integrated in lnd.
>
> 16 hops sounds fine to me too, but in general I am not too concerned about
> the size of the message. Maybe a scheme is possible where the sender
> signals the max number of hops, trading off size against privacy. Probably
> an unnecessary complication though.
>
> I remember the prepay scheme, but sounds quite a bit more invasive than
> just touching encode/relay/decode of the failure message. You also won't
> have the timing information to identify slow nodes on the path.
>
> Joost.
>
> On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell <rusty at rustcorp.com.au>
> wrote:
>
>> Joost Jager <joost.jager at gmail.com> writes:
>> > Hi list,
>> >
>> > I wanted to get back to a long-standing issue in Lightning: gaps in
>> error
>> > attribution. I've posted about this before back in 2019 [1].
>>
>> Hi Joost!
>>
>> Thanks for writing this up fully. Core lightning also doesn't
>> penalize properly, because of the attribution problem: solving this lets
>> us penalize a channel, at least.
>>
>> I want to implement this too, to make sure I understand it
>> correctly, but having read it twice it seems reasonable.
>>
>> How about 16 hops? It's the closest power of 2 to the legacy hop
>> limit, and makes this 4.5k for payloads and hmacs.
>>
>> There is, however, a completely different possibility if we want
>> to use a pre-pay scheme, which I think I've described previously. You
>> send N sats and a secp point; every chained secret returned earns the
>> forwarder 1 sat[1]. The answers of course are placed in each layer of
>> the onion. You know how far the onion got based on how much money you
>> got back on failure[2], though the error message may be corrupted.
>>
>> Cheers,
>> Rusty.
>> [1] Simplest is truncate the point to a new secret key. Each node would
>> apply a tweak for decorrelation ofc.
>> [2] The best scheme is that you don't get paid unless the next node
>> decrypts, actually, but that needs more thought.
>>
> _______________________________________________
> 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/20221103/ddb54b9c/attachment.html>;
Thomas HUET [ARCHIVE] /
npub1tc…pu5xp
2023-06-09 13:07:11
in reply to nevent1q…nqvp
Author Public Key
npub1tcwr7j30p5q4sypnsw4arca9s2433s7wdcpt2z2sk7pkqfsntjds0pu5xpPublished at
2023-06-09 13:07:11Event JSON
{
"id": "7784f6ce58d645b281095600e21b74a58df2f1995539e3c7637d7970707a3675",
"pubkey": "5e1c3f4a2f0d0158103383abd1e3a582ab18c3ce6e02b50950b7836026135c9b",
"created_at": 1686316031,
"kind": 1,
"tags": [
[
"e",
"dc71b85331584c18886f990401d6dac93968340735593115b90d6d86b61b1ed1",
"",
"root"
],
[
"e",
"b36fb6a50482c2fb9452522ce20531c53899a75dd5ca1b8748c560267c37e8e3",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2022-11-03\n📝 Original message:\nHi Joost,\n\nThis is a very interesting proposal that elegantly solves the problem, with\nhowever a very significant size increase. I can see two ways to keep the\nsize small:\n- Each node just adds its hmac in a naive way, without deleting any part of\nthe message to relay. You seem to have disqualified this option because it\nincreases the size of the relayed message but I think it merits more\nconsideration. It is much simpler and the size only grows linearly with the\nlength of the route. An intermediate node could try to infer its position\nrelative to the failing node (which should not be the recipient) but\nwithout knowing the original message size (which can easily be randomized\nby the final node), is that really such a problem? It may be but I would\nargue it's a good trade-off.\n- If we really want to keep the constant size property, as you've suggested\nwe could use a low limit on the number of nodes. I would put the limit even\nlower, at 8 or less. We could still use longer routes but we would only get\nhmacs for the first 8 hops and revert to the legacy system if the failure\nhappens after the first 8 hops. That way we keep the size low and 8 hops\nshould be good enough for 99% of the payments, and even when there are more\nhops we would know that the first 7 hops are clean.\n\nThanks again for your contribution, I hope we'll soon be able to attribute\nfailures trustlessly.\n\nThomas\n\nLe mar. 1 nov. 2022 à 22:10, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e Hey Rusty,\n\u003e\n\u003e Great to hear that you want to try to implement the proposal. I can polish\n\u003e my golang proof of concept code a bit and share if that's useful? It's just\n\u003e doing the calculation in isolation. My next step after that would be to see\n\u003e what it looks like integrated in lnd.\n\u003e\n\u003e 16 hops sounds fine to me too, but in general I am not too concerned about\n\u003e the size of the message. Maybe a scheme is possible where the sender\n\u003e signals the max number of hops, trading off size against privacy. Probably\n\u003e an unnecessary complication though.\n\u003e\n\u003e I remember the prepay scheme, but sounds quite a bit more invasive than\n\u003e just touching encode/relay/decode of the failure message. You also won't\n\u003e have the timing information to identify slow nodes on the path.\n\u003e\n\u003e Joost.\n\u003e\n\u003e On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Joost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e\u003e \u003e Hi list,\n\u003e\u003e \u003e\n\u003e\u003e \u003e I wanted to get back to a long-standing issue in Lightning: gaps in\n\u003e\u003e error\n\u003e\u003e \u003e attribution. I've posted about this before back in 2019 [1].\n\u003e\u003e\n\u003e\u003e Hi Joost!\n\u003e\u003e\n\u003e\u003e Thanks for writing this up fully. Core lightning also doesn't\n\u003e\u003e penalize properly, because of the attribution problem: solving this lets\n\u003e\u003e us penalize a channel, at least.\n\u003e\u003e\n\u003e\u003e I want to implement this too, to make sure I understand it\n\u003e\u003e correctly, but having read it twice it seems reasonable.\n\u003e\u003e\n\u003e\u003e How about 16 hops? It's the closest power of 2 to the legacy hop\n\u003e\u003e limit, and makes this 4.5k for payloads and hmacs.\n\u003e\u003e\n\u003e\u003e There is, however, a completely different possibility if we want\n\u003e\u003e to use a pre-pay scheme, which I think I've described previously. You\n\u003e\u003e send N sats and a secp point; every chained secret returned earns the\n\u003e\u003e forwarder 1 sat[1]. The answers of course are placed in each layer of\n\u003e\u003e the onion. You know how far the onion got based on how much money you\n\u003e\u003e got back on failure[2], though the error message may be corrupted.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Rusty.\n\u003e\u003e [1] Simplest is truncate the point to a new secret key. Each node would\n\u003e\u003e apply a tweak for decorrelation ofc.\n\u003e\u003e [2] The best scheme is that you don't get paid unless the next node\n\u003e\u003e decrypts, actually, but that needs more thought.\n\u003e\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221103/ddb54b9c/attachment.html\u003e",
"sig": "ef182e283f3e61fd783bfd6d46863c1aea3304a02915f7c1d7acf42bbbc4e59c4d01750d19342abdb77aaf716de4c5c9b441b70f73bc53ec3fd4c4bc539e6e6f"
}