ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-16 📝 Original message: Good morning all, It ...
📅 Original date posted:2018-04-16
📝 Original message:
Good morning all,
It seems to me the below two worlds are possible:
1. Symmetric delays.
1.1. I can attack passively: I force a condition where most funds are in the other side (e.g. forwarding to another node I control, or exchanging BTC for material goods), then stop forwarding payments and generally being a pest. The other side closes unilaterally in frustration (locking its funds) and I get penalized by having my (smaller, in my case) amount locked for some blocks.
1.2. I can attack actively: I force a condition where most funds are in the other side, then unilaterally close the channel (locking my counterparty funds). I get penalized by having my smaller amount locked for some blocks.
2. Asymmetric delays.
2.1. I can attack passively: I force a condition where most funds are in the other side (e.g. forwarding to another node I control, or exchanging BTC for material goods), then stop forwarding payments and generally being a pest. The other side closes unilaterally in frustration (locking its funds) and I do not get penalized.
It seems to me that adding an entire new attack vector in order to only *mitigate* (not eliminate!) another attack vector is not a good enough trade-off. In particular the new attack seems *easier* to perform. The current attack where I annoy the other side until it closes has the risk that the other side may have a high tolerance for annoyance, and decide not to close the channel unilaterally anyway. But in a symmetric-delay world, I do not have to wait for the other side to get annoyed: I just trigger the lockup period immediately in the active attack.
--
> For example, in the case where the side unilaterally closing the channel has zero balance, the other side gets no delay and symmetry as measured by (coins locked) * (duration of lock) equals zero on both sides. When the side closing the channel has at least 50% of the balance, both sides must wait the full delay. Thoughts?
So on channel setup where I am the funder to a 1BTC channel I make to Daniel:
* Daniel holds a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
* I hold a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
In order to make the symmetry "(coins locked) * (duration of lock)" equal on both sides of the commitment transaction (after all, Daniel has 0 BTC, so the product 0BTC * anything is 0, so I should not be penalized with a delay on my output of the commitment transaction).
Then I send 0.99BTC to Daniel for 0.99BTC of Daniel products.
Then I publish my original, revoked, commitment transaction with ZmnSCPxj=1BTC+no delay, Danel=0BTC+no delay
Since there is no delay involved in my branch, I can get the money immediately without Daniel being able to revoke it. So I get 1.0BTC and 0.99BTC worth of Daniel products.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/a224bd0f/attachment.html>;
📝 Original message:
Good morning all,
It seems to me the below two worlds are possible:
1. Symmetric delays.
1.1. I can attack passively: I force a condition where most funds are in the other side (e.g. forwarding to another node I control, or exchanging BTC for material goods), then stop forwarding payments and generally being a pest. The other side closes unilaterally in frustration (locking its funds) and I get penalized by having my (smaller, in my case) amount locked for some blocks.
1.2. I can attack actively: I force a condition where most funds are in the other side, then unilaterally close the channel (locking my counterparty funds). I get penalized by having my smaller amount locked for some blocks.
2. Asymmetric delays.
2.1. I can attack passively: I force a condition where most funds are in the other side (e.g. forwarding to another node I control, or exchanging BTC for material goods), then stop forwarding payments and generally being a pest. The other side closes unilaterally in frustration (locking its funds) and I do not get penalized.
It seems to me that adding an entire new attack vector in order to only *mitigate* (not eliminate!) another attack vector is not a good enough trade-off. In particular the new attack seems *easier* to perform. The current attack where I annoy the other side until it closes has the risk that the other side may have a high tolerance for annoyance, and decide not to close the channel unilaterally anyway. But in a symmetric-delay world, I do not have to wait for the other side to get annoyed: I just trigger the lockup period immediately in the active attack.
--
> For example, in the case where the side unilaterally closing the channel has zero balance, the other side gets no delay and symmetry as measured by (coins locked) * (duration of lock) equals zero on both sides. When the side closing the channel has at least 50% of the balance, both sides must wait the full delay. Thoughts?
So on channel setup where I am the funder to a 1BTC channel I make to Daniel:
* Daniel holds a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
* I hold a commitment transaction with: ZmnSCPxj=1BTC+no delay, Daniel=0BTC+no delay
In order to make the symmetry "(coins locked) * (duration of lock)" equal on both sides of the commitment transaction (after all, Daniel has 0 BTC, so the product 0BTC * anything is 0, so I should not be penalized with a delay on my output of the commitment transaction).
Then I send 0.99BTC to Daniel for 0.99BTC of Daniel products.
Then I publish my original, revoked, commitment transaction with ZmnSCPxj=1BTC+no delay, Danel=0BTC+no delay
Since there is no delay involved in my branch, I can get the money immediately without Daniel being able to revoke it. So I get 1.0BTC and 0.99BTC worth of Daniel products.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/a224bd0f/attachment.html>;