📅 Original date posted:2020-10-13
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
>> The LOW-REP node being out of pocket is the clue here: if one party
>> loses funds, even a tiny bit, another party gains some funds. In this
>> case the HIGH-REP node collaborating with the ATTACKER can extract some
>> funds from the intermediate node, allowing them to dime their way to all
>> of LOW-REP's funds. If an attack results in even a tiny loss for an
>> intermediary and can be repeated, the intermediary's funds can be
>> syphoned by an attacker.
>>
>
> The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all
> those failed payments and small losses and start to realize that something
> strange is happening. I know the proposal isn't fully trustless, but I
> think it can work in practice.
>
>
>> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the
>> preimage is even worse:
>>
>> - Attacker node `A` charging hold fees receives HTLC from victim `V`
>> - `A` does not forward the HTLC, but starts charging hold fees
>> - Just before the timeout for the HTLC would force us to settle onchain
>> `A` just removes the HTLC without forwarding it or he can try to
>> forward at the last moment, potentially blaming someone else for its
>> failure to complete
>>
>> This results in `A` extracting the maximum hold fee from `V`, without
>> the downstream hold fees cutting into their profits. By forwarding as
>> late as possible `A` can cause a downstream failure and look innocent,
>> and the overall payment has the worst possible outcome: we waited an
>> eternity for what turns out to be a failed attempt.
>>
>
> The idea is that an attacker node is untrusted and won't be able to charge
> hold fees.
The attacker controls both the sender and the HIGH-REP node. The sender
doesn't need to be trusted, it just initiates a payment that is used to
extract hold fees from a forwarding node. The HIGH-REP node doesn't
lose reputation because from what we can witness externally the payment
failed somewhere downstream. It does require an attacker to have a hold
fee charging HIGH-REP node, yes, but he is not jeopardizing its
reputation by having it fail downstream.
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:01:12
in reply to nevent1q…2tx8
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:01:12Event JSON
{
"id": "7267f6c5de5f6c587c8f06928a9ae1dc740ce8ab5bfb00df731f9f7eb6cc1bd7",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315672,
"kind": 1,
"tags": [
[
"e",
"2e5ffd65d86c5774dbb4381933898049e781bd6e8719e31c24e98ee704e67d6e",
"",
"root"
],
[
"e",
"407fd5fa508ca548c507e0bc008f6ce44162f3611b4fd9fc262016641df7d0a9",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2020-10-13\n📝 Original message:\nJoost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e\u003e The LOW-REP node being out of pocket is the clue here: if one party\n\u003e\u003e loses funds, even a tiny bit, another party gains some funds. In this\n\u003e\u003e case the HIGH-REP node collaborating with the ATTACKER can extract some\n\u003e\u003e funds from the intermediate node, allowing them to dime their way to all\n\u003e\u003e of LOW-REP's funds. If an attack results in even a tiny loss for an\n\u003e\u003e intermediary and can be repeated, the intermediary's funds can be\n\u003e\u003e syphoned by an attacker.\n\u003e\u003e\n\u003e\n\u003e The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all\n\u003e those failed payments and small losses and start to realize that something\n\u003e strange is happening. I know the proposal isn't fully trustless, but I\n\u003e think it can work in practice.\n\u003e\n\u003e\n\u003e\u003e Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the\n\u003e\u003e preimage is even worse:\n\u003e\u003e\n\u003e\u003e - Attacker node `A` charging hold fees receives HTLC from victim `V`\n\u003e\u003e - `A` does not forward the HTLC, but starts charging hold fees\n\u003e\u003e - Just before the timeout for the HTLC would force us to settle onchain\n\u003e\u003e `A` just removes the HTLC without forwarding it or he can try to\n\u003e\u003e forward at the last moment, potentially blaming someone else for its\n\u003e\u003e failure to complete\n\u003e\u003e\n\u003e\u003e This results in `A` extracting the maximum hold fee from `V`, without\n\u003e\u003e the downstream hold fees cutting into their profits. By forwarding as\n\u003e\u003e late as possible `A` can cause a downstream failure and look innocent,\n\u003e\u003e and the overall payment has the worst possible outcome: we waited an\n\u003e\u003e eternity for what turns out to be a failed attempt.\n\u003e\u003e\n\u003e\n\u003e The idea is that an attacker node is untrusted and won't be able to charge\n\u003e hold fees.\n\nThe attacker controls both the sender and the HIGH-REP node. The sender\ndoesn't need to be trusted, it just initiates a payment that is used to\nextract hold fees from a forwarding node. The HIGH-REP node doesn't\nlose reputation because from what we can witness externally the payment\nfailed somewhere downstream. It does require an attacker to have a hold\nfee charging HIGH-REP node, yes, but he is not jeopardizing its\nreputation by having it fail downstream.\n\nCheers,\nChristian",
"sig": "bcf4e3c25e40a1279c211eb33153ddbf2d1e425a3c5aa982f8586dc919625bf20a4a34f2070978409f0a26a7b5d79329d65b7b6923954360ce77175458222b7b"
}