Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-24 📝 Original message: Joost Jager <joost.jager ...
📅 Original date posted:2022-10-24
📝 Original message:
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.
Published at
2023-06-09 13:07:08Event JSON
{
"id": "d7057cb6d8cd212d55f9506be37b9a593d7093e81349391e14d0997406763ba0",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686316028,
"kind": 1,
"tags": [
[
"e",
"7e7acd5c9009d2af34a1e92bdcee51b6c78a97018be25ffc59e6b5e8e3dbabb9",
"",
"root"
],
[
"e",
"c6899ed45e773d9a5b58fe760560ab7375f548405bf9caac1af89cbf39124739",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2022-10-24\n📝 Original message:\nJoost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e Hi list,\n\u003e\n\u003e I wanted to get back to a long-standing issue in Lightning: gaps in error\n\u003e attribution. I've posted about this before back in 2019 [1].\n\nHi Joost!\n\n Thanks for writing this up fully. Core lightning also doesn't\npenalize properly, because of the attribution problem: solving this lets\nus penalize a channel, at least.\n\n I want to implement this too, to make sure I understand it\ncorrectly, but having read it twice it seems reasonable.\n\n How about 16 hops? It's the closest power of 2 to the legacy hop\nlimit, and makes this 4.5k for payloads and hmacs.\n\n There is, however, a completely different possibility if we want\nto use a pre-pay scheme, which I think I've described previously. You\nsend N sats and a secp point; every chained secret returned earns the\nforwarder 1 sat[1]. The answers of course are placed in each layer of\nthe onion. You know how far the onion got based on how much money you\ngot back on failure[2], though the error message may be corrupted.\n\nCheers,\nRusty.\n[1] Simplest is truncate the point to a new secret key. Each node would\n apply a tweak for decorrelation ofc.\n[2] The best scheme is that you don't get paid unless the next node\n decrypts, actually, but that needs more thought.",
"sig": "671f98da45469fb042c774fd02767aa29e25dc51424dc53177926b07348664f27905cf893a8065186c21010bea84d73cd1055828fa3bac5fe3823c658a0e94e4"
}