Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-02 📝 Original message: > Loop attacks are not ...
📅 Original date posted:2020-12-02
📝 Original message:
> Loop attacks are not about loops, it only requires that the start and
end of a payment are controlled by the same entity
Thanks for clearing that up. I was referring to cycles in the payment paths
where you get honest parties to forward your HTLC between themselves over
and over again as part of a single paryment. I have just realized that it's
easy to prevent by just looking for duplicate payment hashes. This will be
a problem for randomized PTLCs though.
> * There are two griefing attacks:
> * Loop attacks, which are deliberate malicious attacks to lock up funds
of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where a
forwarding node accidentally goes offline and causes payments to be locked
up for long periods and making everyone on the network cry when HTLCs time
out and things have to be dropped onchain
Another one recently pointed out in [1] is to jam a channels towards a
competing merchant. Users who are trying to buy from the merchant will give
up because of technical failure and instead come to your site where you
will sell successfully for a higher price.
This seems more plausible to me than completing for fees.
Back to the general topic. Perhaps a way of refining the proposal is the
following:
1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of
design.
2. The owner (owners?) of leach LN UTXO can go to any node in the network
and request a kind of token for their UTXO (i.e. channel id).
3. When making a payment you present a randomized version of the token to
each node (it is not linkable to the UTXO) and prove that the UTXO it
represents is large enough to support the payment (the token and proof
protocol can hopefully be non-interactive so it can fit in the onion).
4. If your HTLC fails your token is deleted (and have to wait some period
before requesting a new one).
5. If your payment succeeds your token is renewed on the spot (and maybe
forwarded back along the path covertly).
Not saying this will be easy (or even totally coherent) but I feel the
direction is a bit more plausible.
The benefit here is that you avoid the complicated ZKPs about UTXOs and are
treading on a more well worn path of anonymous credentials and ecash.
[1]:
https://github.com/t-bast/lightning-docs/issues/7#issuecomment-736713076
LL
On Tue, Dec 1, 2020 at 11:11 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning LL, and list,
>
>
> > That's a very interesting point. If we were to be able to prevent loop
> attacks by the sender proving the path is well formed (without revealing
> who they are or any of the other hops) would this be an alternative
> solution?
> > It seems to me that disabling loop attacks might be much easier than
> stake certificates.
>
> Loop attacks are not about loops, it only requires that the start and end
> of a payment are controlled by the same entity.
>
> Multiple nodes on the LN may be owned by the same entity.
> Nodes, individually as nodes, are trivially cheap and just need 32 bytes
> of entropy from a `/dev/random` near you.
> It is the channels themselves, requiring actual funds, high uptime, and
> not being a dick to your counterparty, that are fairly expensive.
>
> Thus, a "loop attack" need not involve a loop per se --- a single entity
> can run any number of nodes with small numbers of channels each, and
> thereby grief the network.
>
> Stake certificates make the node itself expensive, so a single entity
> running a number of nodes cannot perform such loop attacks, since it would
> require entities expensively allocating funds for each node.
>
>
>
>
> On the other hand, if channels are expensive, then a node with channels is
> expensive.
>
> In
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html
> , which contains the "Z consideration" you were alluding to, I note that
> the "point-to-point property" is already proven by the ***existing***
> Lightning network without an additional ZK cryptographic proof.
>
> So let me invert that logic and present an even more extreme position:
>
> * There are two griefing attacks:
> * Loop attacks, which are deliberate malicious attacks to lock up funds
> of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where
> a forwarding node accidentally goes offline and causes payments to be
> locked up for long periods and making everyone on the network cry when
> HTLCs time out and things have to be dropped onchain.
> * The point-to-point property, which is already proven by the
> ***existing*** Lightning network, is already sufficient to prevent loop
> attacks, leaving only accidental incompetence-based "attacks".
> * Or: the ***existing*** Lightning Network ***already*** proves the
> point-to-point property presented by t-bast, and that property is
> ***already*** sufficient to prevent the loop attacks.
>
> So, maybe we should instead focus on mitigating the effects of the
> incompetence-based non-attacks [such as this proposal](
> https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),
> instead of attempting to defend against the mirage of loop attacks.
>
>
> I could be utterly wrong here though.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201202/c3d28486/attachment.html>;
📝 Original message:
> Loop attacks are not about loops, it only requires that the start and
end of a payment are controlled by the same entity
Thanks for clearing that up. I was referring to cycles in the payment paths
where you get honest parties to forward your HTLC between themselves over
and over again as part of a single paryment. I have just realized that it's
easy to prevent by just looking for duplicate payment hashes. This will be
a problem for randomized PTLCs though.
> * There are two griefing attacks:
> * Loop attacks, which are deliberate malicious attacks to lock up funds
of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where a
forwarding node accidentally goes offline and causes payments to be locked
up for long periods and making everyone on the network cry when HTLCs time
out and things have to be dropped onchain
Another one recently pointed out in [1] is to jam a channels towards a
competing merchant. Users who are trying to buy from the merchant will give
up because of technical failure and instead come to your site where you
will sell successfully for a higher price.
This seems more plausible to me than completing for fees.
Back to the general topic. Perhaps a way of refining the proposal is the
following:
1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of
design.
2. The owner (owners?) of leach LN UTXO can go to any node in the network
and request a kind of token for their UTXO (i.e. channel id).
3. When making a payment you present a randomized version of the token to
each node (it is not linkable to the UTXO) and prove that the UTXO it
represents is large enough to support the payment (the token and proof
protocol can hopefully be non-interactive so it can fit in the onion).
4. If your HTLC fails your token is deleted (and have to wait some period
before requesting a new one).
5. If your payment succeeds your token is renewed on the spot (and maybe
forwarded back along the path covertly).
Not saying this will be easy (or even totally coherent) but I feel the
direction is a bit more plausible.
The benefit here is that you avoid the complicated ZKPs about UTXOs and are
treading on a more well worn path of anonymous credentials and ecash.
[1]:
https://github.com/t-bast/lightning-docs/issues/7#issuecomment-736713076
LL
On Tue, Dec 1, 2020 at 11:11 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning LL, and list,
>
>
> > That's a very interesting point. If we were to be able to prevent loop
> attacks by the sender proving the path is well formed (without revealing
> who they are or any of the other hops) would this be an alternative
> solution?
> > It seems to me that disabling loop attacks might be much easier than
> stake certificates.
>
> Loop attacks are not about loops, it only requires that the start and end
> of a payment are controlled by the same entity.
>
> Multiple nodes on the LN may be owned by the same entity.
> Nodes, individually as nodes, are trivially cheap and just need 32 bytes
> of entropy from a `/dev/random` near you.
> It is the channels themselves, requiring actual funds, high uptime, and
> not being a dick to your counterparty, that are fairly expensive.
>
> Thus, a "loop attack" need not involve a loop per se --- a single entity
> can run any number of nodes with small numbers of channels each, and
> thereby grief the network.
>
> Stake certificates make the node itself expensive, so a single entity
> running a number of nodes cannot perform such loop attacks, since it would
> require entities expensively allocating funds for each node.
>
>
>
>
> On the other hand, if channels are expensive, then a node with channels is
> expensive.
>
> In
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html
> , which contains the "Z consideration" you were alluding to, I note that
> the "point-to-point property" is already proven by the ***existing***
> Lightning network without an additional ZK cryptographic proof.
>
> So let me invert that logic and present an even more extreme position:
>
> * There are two griefing attacks:
> * Loop attacks, which are deliberate malicious attacks to lock up funds
> of competitors in order to redirect forwarding towards the attacker.
> * Accidental "attacks", which are accidental due to incompetence, where
> a forwarding node accidentally goes offline and causes payments to be
> locked up for long periods and making everyone on the network cry when
> HTLCs time out and things have to be dropped onchain.
> * The point-to-point property, which is already proven by the
> ***existing*** Lightning network, is already sufficient to prevent loop
> attacks, leaving only accidental incompetence-based "attacks".
> * Or: the ***existing*** Lightning Network ***already*** proves the
> point-to-point property presented by t-bast, and that property is
> ***already*** sufficient to prevent the loop attacks.
>
> So, maybe we should instead focus on mitigating the effects of the
> incompetence-based non-attacks [such as this proposal](
> https://github.com/ElementsProject/lightning/issues/2632#issuecomment-736438980),
> instead of attempting to defend against the mirage of loop attacks.
>
>
> I could be utterly wrong here though.
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201202/c3d28486/attachment.html>;