{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-13\n📝 Original message:\n\u003e\n\u003e \u003e If I were LOW-REP, I'd still charge an unknown node a hold fee. I\n\u003e \u003e would only waive the hold fee for high-reputation nodes. In that case,\n\u003e \u003e the attacker is still paying for the attack. I may be forced to take a\n\u003e \u003e small loss on the difference, but at least the larger part of the pain\n\u003e \u003e is felt by the attacker. The assumption is that this is sufficient\n\u003e \u003e enough to deter the attacker from even trying.\n\u003e\n\u003e The LOW-REP node being out of pocket is the clue here: if one party\n\u003e loses funds, even a tiny bit, another party gains some funds. In this\n\u003e case the HIGH-REP node collaborating with the ATTACKER can extract some\n\u003e funds from the intermediate node, allowing them to dime their way to all\n\u003e of LOW-REP's funds. If an attack results in even a tiny loss for an\n\u003e intermediary and can be repeated, the intermediary's funds can be\n\u003e syphoned by an attacker.\n\u003e\n\nThe assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all\nthose failed payments and small losses and start to realize that something\nstrange is happening. I know the proposal isn't fully trustless, but I\nthink it can work in practice.\n\n\n\u003e Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the\n\u003e preimage is even worse:\n\u003e\n\u003e  - Attacker node `A` charging hold fees receives HTLC from victim `V`\n\u003e  - `A` does not forward the HTLC, but starts charging hold fees\n\u003e  - Just before the timeout for the HTLC would force us to settle onchain\n\u003e    `A` just removes the HTLC without forwarding it or he can try to\n\u003e    forward at the last moment, potentially blaming someone else for its\n\u003e    failure to complete\n\u003e\n\u003e This results in `A` extracting the maximum hold fee from `V`, without\n\u003e the downstream hold fees cutting into their profits. By forwarding as\n\u003e late as possible `A` can cause a downstream failure and look innocent,\n\u003e and the overall payment has the worst possible outcome: we waited an\n\u003e eternity for what turns out to be a failed attempt.\n\u003e\n\nThe idea is that an attacker node is untrusted and won't be able to charge\nhold fees.\n\n- Joost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/5b59146c/attachment.html\u003e"}