Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-20 📝 Original message: On Thu, Aug 20, 2015 at ...
📅 Original date posted:2015-08-20
📝 Original message:
On Thu, Aug 20, 2015 at 03:19:29PM +0930, Rusty Russell wrote:
> So, with some prompting from AJ who has been working on node
> incentives, I realized there's a nasty attack available to the
> network. You simply route a payment back to another channel you own,
> then refuse to dislose R.
>
> You have to lock up N bitcoins, but so does every node in the path
> (and nobody gets paid!). Onion routing means nobody knows who to
> blame (you can simply claim there's another hop after you).
This can be defined as a feature, though. If one expects the coins to be
locked up for the duration from the outset, the risk models are a lot
more clear.
It forces the graph to be more diffuse. It also forces intermediate
nodes who are well-connected (who therefore also are the most likely
subject of attacks) to offload their HTLCs to 3rd party channel
liquidity providers.
E.g. If Mallory tries to tie up the Alice<->Bob link, then if Carol is
connected to both Alice and Bob, she can take the HTLC to be
Alice->Carol->Bob, so that the Alice<->Bob link is clear.
> I think in this case we need to peel the onion[1]: if a payment takes
> too long you tell the previous node where you sent it (and relay where
> it sent it, etc.) If you're the last in the queue, you also need to
> prove that you closed the channel to the offender[2] (which costs you
> a txfee, providing disincentive).
My concern with mitigating this by establishing blame via information
disclosure is that it will encourage graph centralization.
> Anyone see any other problems?
I see the primary problem with "onion" routing is that some parts of the
graph may be faster with disclosure of R. In effect, some people may
have higher costs in the "time" part of "time-value"
E.g. A->B->C->D->E. If C, D, and E are colluding participants to each
other, and their R gets disclosed immediately, their channel's value
permits much lower fees. They can collude to be dishonest with B, so
that B's channel is tied up for the maximum period of time. This
increases the costs for B and biases channels to use the C,D,E cartel
due to lower costs (since the channels aren't locked up as long).
However! The effect isn't necessarily that the cartel is successful,
there are always second order effects in preventing potential problems.
It's possible that B mitigates this by biasing the routing towards
certain participants that B "likes" (IOW, trusts to not withhold R to the
maximum time), which is where I think the real complexity with
incentives lie -- B will discourage using onion routing entirely.
I see the tradeoffs as having both as an option may make sense, the
second order effect gives you an option for either (with one possibly
being slightly more expensive due to the withholding risks), whereas
forcing onion *only* on everything may create emergent cartelization
incentives. I haven't fully thought out the implications, and not
particularly attached to this viewpoint, though.
Thaddeus mentioned a possible solution to all this being funds sent to
each participant with multiple signatures for different times of
disclosure of R (having the spending transaction be double-spent with
different locktimes, this is dependent upon a longer-term malleability
fix and may require a more elaborate tree structure for the HTLC
spends). E.g. release within 4 hours will have each hop make slightly
more money in fees. It doesn't guarantee against withholding, it just
creates a material cost to do so. I don't think we've really fleshed out
the idea, though AFAIK.
--
Joseph Poon
Published at
2023-06-09 12:44:03Event JSON
{
"id": "7637a814ad8a5afb5309c9dea8aeda530bdc8ececc986dfd412eb1ecd9930abe",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314643,
"kind": 1,
"tags": [
[
"e",
"a92f734d740b85399f0e70711c3ef451f97eec2048c08c21ef8e0700fe174d1c",
"",
"root"
],
[
"e",
"331253379f3ea6dc10681974165b01bb784d1d70ab58098157fa7daab29f4f4d",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-08-20\n📝 Original message:\nOn Thu, Aug 20, 2015 at 03:19:29PM +0930, Rusty Russell wrote:\n\u003e So, with some prompting from AJ who has been working on node\n\u003e incentives, I realized there's a nasty attack available to the\n\u003e network. You simply route a payment back to another channel you own,\n\u003e then refuse to dislose R.\n\u003e \n\u003e You have to lock up N bitcoins, but so does every node in the path\n\u003e (and nobody gets paid!). Onion routing means nobody knows who to\n\u003e blame (you can simply claim there's another hop after you).\n\nThis can be defined as a feature, though. If one expects the coins to be\nlocked up for the duration from the outset, the risk models are a lot\nmore clear.\n\nIt forces the graph to be more diffuse. It also forces intermediate\nnodes who are well-connected (who therefore also are the most likely\nsubject of attacks) to offload their HTLCs to 3rd party channel\nliquidity providers.\n\nE.g. If Mallory tries to tie up the Alice\u003c-\u003eBob link, then if Carol is\nconnected to both Alice and Bob, she can take the HTLC to be\nAlice-\u003eCarol-\u003eBob, so that the Alice\u003c-\u003eBob link is clear.\n\n\u003e I think in this case we need to peel the onion[1]: if a payment takes\n\u003e too long you tell the previous node where you sent it (and relay where\n\u003e it sent it, etc.) If you're the last in the queue, you also need to\n\u003e prove that you closed the channel to the offender[2] (which costs you\n\u003e a txfee, providing disincentive).\n\nMy concern with mitigating this by establishing blame via information\ndisclosure is that it will encourage graph centralization.\n\n\u003e Anyone see any other problems?\n\nI see the primary problem with \"onion\" routing is that some parts of the\ngraph may be faster with disclosure of R. In effect, some people may\nhave higher costs in the \"time\" part of \"time-value\"\n\nE.g. A-\u003eB-\u003eC-\u003eD-\u003eE. If C, D, and E are colluding participants to each\nother, and their R gets disclosed immediately, their channel's value\npermits much lower fees. They can collude to be dishonest with B, so\nthat B's channel is tied up for the maximum period of time. This\nincreases the costs for B and biases channels to use the C,D,E cartel\ndue to lower costs (since the channels aren't locked up as long). \n\nHowever! The effect isn't necessarily that the cartel is successful,\nthere are always second order effects in preventing potential problems.\nIt's possible that B mitigates this by biasing the routing towards\ncertain participants that B \"likes\" (IOW, trusts to not withhold R to the\nmaximum time), which is where I think the real complexity with\nincentives lie -- B will discourage using onion routing entirely.\n\nI see the tradeoffs as having both as an option may make sense, the\nsecond order effect gives you an option for either (with one possibly\nbeing slightly more expensive due to the withholding risks), whereas\nforcing onion *only* on everything may create emergent cartelization\nincentives. I haven't fully thought out the implications, and not\nparticularly attached to this viewpoint, though.\n\nThaddeus mentioned a possible solution to all this being funds sent to\neach participant with multiple signatures for different times of\ndisclosure of R (having the spending transaction be double-spent with\ndifferent locktimes, this is dependent upon a longer-term malleability\nfix and may require a more elaborate tree structure for the HTLC\nspends). E.g. release within 4 hours will have each hop make slightly\nmore money in fees. It doesn't guarantee against withholding, it just\ncreates a material cost to do so. I don't think we've really fleshed out\nthe idea, though AFAIK.\n\n-- \nJoseph Poon",
"sig": "3259470a4240943f99d081041b62a09b9f0869c8ee84e02c075f0380a99b0a49122d95e87fc2f555402caf58a1a1e1ccf3dc22c600b28c1d72d43bae53b3a718"
}