rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2020-10-13 📝 Original message: > > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I > > would only waive the hold fee for high-reputation nodes. In that case, > > the attacker is still paying for the attack. I may be forced to take a > > small loss on the difference, but at least the larger part of the pain > > is felt by the attacker. The assumption is that this is sufficient > > enough to deter the attacker from even trying. > > 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. - Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201013/5b59146c/attachment.html>