Good morning, It may be helpful to remember that "cross-asset" need not mean "cross-chain"; for example, the RGB project strives to create assets committed on the Bitcoin blockchain, in such a way that it would be possible to put them into Lightning channels. Thus this "proof-of-not-my-fault" apply to cross-asset swaps on the same blockchain? How about same-asset swaps across blockchains, e.g. RSK to Liquid?
Of course the most obvious way, to create a unique assets, involves creating a unique blockchain for it, but the argument applies regardless for a multi-asset blockchain. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, January 8, 2019 9:27 PM, Corné Plooy via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrote: > 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 lightning-dev@lists.linuxfoundation.org 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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
