Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-08 📝 Original message: True, as soon as this ...
📅 Original date posted:2019-01-08
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev