From corne at bitonic.nl Tue Jan 8 13:27:02 2019 From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=) Date: Tue, 8 Jan 2019 14:27:02 +0100 Subject: [Lightning-dev] An Argument For Single-Asset Lightning Network In-Reply-To: <878szvg2dg.fsf@rustcorp.com.au> References: <878szvg2dg.fsf@rustcorp.com.au> Message-ID: True, as soon as this measure gets implemented (which AFAIK is not the case right now). However, the attack is not free. The victim interfaces between two different Lightning networks, each operating a different asset, possibly on a different block chain (so that proof of channel closuse on one side cannot be understood on the other side) or even using a completely different technology. The problem of the victim arises when an exchange transaction arrives from network A, the victim forwards it on network B, and then the transaction gets stalled. The victim can demand a proof that something went wrong on network B, but cannot propagate that proof on network A. Since the victim cannot propagate a valid proof, the victim will be penalized on network A. My point is: the victim can still demand a proof that something went wrong on network B. To stall the transaction, the attacker must be controlling the node on network B that is doing the stalling. The same anti-spam measure that penalizes the victim on network A *also* penalizes the attacking node on network B. The penalties may not be the same: maybe on-chain fees are much lower on chain B than on chain A. Still, the anti-spam measure should somewhat reduce the attractiveness of this attack. CJP On 08-01-19 06:11, Rusty Russell wrote: > ZmnSCPxj via Lightning-dev writes: >> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across Assets, or, An Argument For Single-Asset Lightning Network > Interesting. FWIW, I believe that multi-asset LN will fail for a > related, but different reason: to prevent long-lived spam payments we > may require proof that something went wrong (ie. channel unilateral > close tx). That won't be valid if it's from a different network, > resulting in the exchange point itself being penalized. Thus they are > vulnerable to such a DoS. > > Cheers, > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev