I think the mechanism can indeed create interesting dynamics, but not in a good sense :-)
>> I can still establish channels to various low-reputation nodes, and >> then use them to grief a high-reputation node. Not only do I get to >> jam up the high-reputation channels, as a bonus I get the >> low-reputation nodes to pay for it! > > So you're saying: > > ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP > > 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. 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. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
