📅 Original date posted:2018-05-10
📝 Original message:
Hmm, I'm not quite following the situation. What do you mean by "directs
normal traffic"? Since the sender constructs the entire circuit, routing
nodes do not get any discretion over which nodes to forward a payment to,
only whether to forward or fail. What an attacker could do is perform a
loop attack and send a payment to another node that they control and delay
the payment on the receiving end. Note that the sending node loses no
reputation, only the receiving node. Since the hops being attacked are the
ones in the middle and they are faithfully enforcing the reputation
protocol, the receiving node's reputation should be penalized properly,
making it unlikely the attack will succeed in a second attempt.
On Thu, May 10, 2018 at 2:56 PM, Chris Gough <christopher.d.gough at gmail.com>
wrote:
> hello, I'm a curious lurker trying to follow this conversation:
>
> On Thu, 10 May 2018, 2:40 pm ZmnSCPxj via Lightning-dev, <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>>
>> The concern however is that the CLTV already partly leaks the distance
>> from the payee, whereas the reputation-loss-rate leaks distance from the
>> payer. It is often not interesting to know that some entity is getting
>> paid, but it probably far more interesting to know WHO paid WHO, so leaking
>> both distances simultaneously is more than twice as worse as leaking just
>> one distance.
>>
>
> Consider an asymetrically-resourced malevolent node that wants the ability
> to harm a specific small nodes without aquiring a bad reputation (and is
> willing to pay for it). In preparation, this bad boss node directs normal
> traffic to sacrificial nodes they control, while understating the
> reputation-risk (truthfully as it turns out, because they have out of band
> influence over the node). When the time comes, the sacrificial node
> inflicts delay on the victim node and they both suffer, while the boss
> keeps her nose clean.
>
> Is it the case that understating risk of legitimate traffic from boss node
> to sacrificial node effectively allows transfer of reputation to the
> sacrificial node in preparation for attack, while at the same time
> obscuring their association?
>
> Chris Gough
>
>>
> _______________________________________________
> 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/20180510/e6ddf135/attachment.html>;
Jim Posen [ARCHIVE] /
npub1nc…lqt2n
2023-06-09 12:50:26
in reply to nevent1q…8kyv
Author Public Key
npub1ncnj8arudstdxzfhxk7k4nwgkrw3hyw8sgt0wqqmm5hh2c4knmgs2lqt2nPublished at
2023-06-09 12:50:26Event JSON
{
"id": "996ac196c71569e33f7d8a6ff6ad2b95e6ded7bf0b936f96412e2222bc076274",
"pubkey": "9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1",
"created_at": 1686315026,
"kind": 1,
"tags": [
[
"e",
"ec647d42dc739e5a708f79cd6e7400519e655a3f7062723c1ca708888c19c0eb",
"",
"root"
],
[
"e",
"754d0f462c059327883ab070624a3fa8fa6f28b50fda518f8155b8695ab9efde",
"",
"reply"
],
[
"p",
"7dcf0ab721a725c5b60ca861acc882015ece95fd6c708f72074e2ff1c968f91e"
]
],
"content": "📅 Original date posted:2018-05-10\n📝 Original message:\nHmm, I'm not quite following the situation. What do you mean by \"directs\nnormal traffic\"? Since the sender constructs the entire circuit, routing\nnodes do not get any discretion over which nodes to forward a payment to,\nonly whether to forward or fail. What an attacker could do is perform a\nloop attack and send a payment to another node that they control and delay\nthe payment on the receiving end. Note that the sending node loses no\nreputation, only the receiving node. Since the hops being attacked are the\nones in the middle and they are faithfully enforcing the reputation\nprotocol, the receiving node's reputation should be penalized properly,\nmaking it unlikely the attack will succeed in a second attempt.\n\nOn Thu, May 10, 2018 at 2:56 PM, Chris Gough \u003cchristopher.d.gough at gmail.com\u003e\nwrote:\n\n\u003e hello, I'm a curious lurker trying to follow this conversation:\n\u003e\n\u003e On Thu, 10 May 2018, 2:40 pm ZmnSCPxj via Lightning-dev, \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e The concern however is that the CLTV already partly leaks the distance\n\u003e\u003e from the payee, whereas the reputation-loss-rate leaks distance from the\n\u003e\u003e payer. It is often not interesting to know that some entity is getting\n\u003e\u003e paid, but it probably far more interesting to know WHO paid WHO, so leaking\n\u003e\u003e both distances simultaneously is more than twice as worse as leaking just\n\u003e\u003e one distance.\n\u003e\u003e\n\u003e\n\u003e Consider an asymetrically-resourced malevolent node that wants the ability\n\u003e to harm a specific small nodes without aquiring a bad reputation (and is\n\u003e willing to pay for it). In preparation, this bad boss node directs normal\n\u003e traffic to sacrificial nodes they control, while understating the\n\u003e reputation-risk (truthfully as it turns out, because they have out of band\n\u003e influence over the node). When the time comes, the sacrificial node\n\u003e inflicts delay on the victim node and they both suffer, while the boss\n\u003e keeps her nose clean.\n\u003e\n\u003e Is it the case that understating risk of legitimate traffic from boss node\n\u003e to sacrificial node effectively allows transfer of reputation to the\n\u003e sacrificial node in preparation for attack, while at the same time\n\u003e obscuring their association?\n\u003e\n\u003e Chris Gough\n\u003e\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180510/e6ddf135/attachment.html\u003e",
"sig": "f8112304922ee023e8d05bd78c5858629a03247daf7ce13baaa3b18506d8409bf915537050a7a6d03b97813bf80687aa0261525daab709e54cdd7dbf08b0eba7"
}