Ariel Lorenzo-Luaces [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-15 📝 Original message: Letting the attacker have ...
📅 Original date posted:2018-04-15
📝 Original message:
Letting the attacker have immediate access to their funds is a null point because the attacker always has the preparation time to unbalance the channel to the honest node's favor. The attacker's 'funds' in this case is trivially reduced to 'reserve balance'. It's hard to argue that forcing the malicious node to wait for the delay before having access to their reserve balance is disincentive enough to not perform the attack.
Cheers
Ariel Lorenzo-Luaces
On Apr 15, 2018, 11:37 AM, at 11:37 AM, Jim Posen <jim.posen at gmail.com> wrote:
>I believe that anyone attempting a DOS by forcing on-chain settlement
>can
>do it just as easily with asymmetric delays than with symmetric delays.
>
>If my goal is to waste the time-value of your money in a channel, in a
>world with symmetric delays, I could just publish the commitment
>transaction and you would have to wait the full delay for access to
>your
>funds. True. But with delays asymmetric as they are now, I can just as
>easily refuse to participate in a mutual close, forcing you to close
>on-chain. This is just as bad. In fact, I'd argue that it is worse,
>because
>I lose less by doing this (in the sense that I as the attacker get
>immediate access to my funds). So in my assessment, it is a very active
>attack and symmetric delays are something of a mitigation. You are
>right
>that the balance of funds in the channel becomes a factor too, but note
>that there is the reserve balance, so I'm always losing access to some
>funds for some time.
>
>-jimpo
>
>On Sun, Apr 15, 2018 at 6:35 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>wrote:
>
>> Good morning Daniel,
>>
>>
>> This makes a lot of sense to me as a way to correct the incentives
>for
>> closing channels. I figure that honest nodes that have truly gone
>offline
>> will not require (or be able to take advantage of) immediate access
>to
>> their balance, such that this change shouldn't cause too much
>inconvenience.
>>
>> I was trying to think if this could open up a DOS vector - dishonest
>nodes
>> performing unilateral closes even when mutual closes are possible
>just to
>> lock up the other side's coins - but it seems like not much of a
>concern. I
>> figure it's hard to pull off on a large scale.
>>
>>
>>
>> Now that you bring this up, I think, it is indeed a concern, and one
>we
>> should not take lightly.
>>
>> As a purely selfish rational being, it matters not to me whether my
>> commitment transaction will delay your output or not; all that
>matters is
>> that it delays mine, and that is enough for me to prefer a bilateral
>close
>> if possible. I think we do not need to change commitment
>transactions to
>> be symmetrical then --- it is enough that the one holding the
>commitment
>> transaction has its own outputs delayed.
>>
>> If I had a goal to disrupt rather than cooperate with the Lightning
>> Network, and commitment transactions would also delay the side not
>holding
>> the commitment transaction (i.e. "symmetrical delay" commitments), I
>would
>> find it easier to disrupt cheaply if I could wait for a channel to be
>> unbalanced in your favor (i.e. you own more money on it than I do),
>then
>> lock up both our funds by doing a unilateral transaction. Since it
>is
>> unbalanced in your favor, you end up losing more utility than I do.
>> Indeed, in the situation where you are funding a new channel to me, I
>have
>> 0 satoshi on the channel and can perform this attack costlessly.
>>
>> Now perhaps one may argue, in the case of asymmetric delays, that if
>I
>> were evil, I could still disrupt the network by misbehaving and
>forcing the
>> other side to push its commitment transaction. Indeed I could even
>just
>> accept a channel and then always fail to forward any payment you try
>to
>> make over it, performing a disruption costlessly too (as I have no
>money in
>> this). But this attack is somewhat more passive than the above
>attack
>> under a symmetrical delay commitment transaction scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/2b1c8937/attachment-0001.html>;
📝 Original message:
Letting the attacker have immediate access to their funds is a null point because the attacker always has the preparation time to unbalance the channel to the honest node's favor. The attacker's 'funds' in this case is trivially reduced to 'reserve balance'. It's hard to argue that forcing the malicious node to wait for the delay before having access to their reserve balance is disincentive enough to not perform the attack.
Cheers
Ariel Lorenzo-Luaces
On Apr 15, 2018, 11:37 AM, at 11:37 AM, Jim Posen <jim.posen at gmail.com> wrote:
>I believe that anyone attempting a DOS by forcing on-chain settlement
>can
>do it just as easily with asymmetric delays than with symmetric delays.
>
>If my goal is to waste the time-value of your money in a channel, in a
>world with symmetric delays, I could just publish the commitment
>transaction and you would have to wait the full delay for access to
>your
>funds. True. But with delays asymmetric as they are now, I can just as
>easily refuse to participate in a mutual close, forcing you to close
>on-chain. This is just as bad. In fact, I'd argue that it is worse,
>because
>I lose less by doing this (in the sense that I as the attacker get
>immediate access to my funds). So in my assessment, it is a very active
>attack and symmetric delays are something of a mitigation. You are
>right
>that the balance of funds in the channel becomes a factor too, but note
>that there is the reserve balance, so I'm always losing access to some
>funds for some time.
>
>-jimpo
>
>On Sun, Apr 15, 2018 at 6:35 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>wrote:
>
>> Good morning Daniel,
>>
>>
>> This makes a lot of sense to me as a way to correct the incentives
>for
>> closing channels. I figure that honest nodes that have truly gone
>offline
>> will not require (or be able to take advantage of) immediate access
>to
>> their balance, such that this change shouldn't cause too much
>inconvenience.
>>
>> I was trying to think if this could open up a DOS vector - dishonest
>nodes
>> performing unilateral closes even when mutual closes are possible
>just to
>> lock up the other side's coins - but it seems like not much of a
>concern. I
>> figure it's hard to pull off on a large scale.
>>
>>
>>
>> Now that you bring this up, I think, it is indeed a concern, and one
>we
>> should not take lightly.
>>
>> As a purely selfish rational being, it matters not to me whether my
>> commitment transaction will delay your output or not; all that
>matters is
>> that it delays mine, and that is enough for me to prefer a bilateral
>close
>> if possible. I think we do not need to change commitment
>transactions to
>> be symmetrical then --- it is enough that the one holding the
>commitment
>> transaction has its own outputs delayed.
>>
>> If I had a goal to disrupt rather than cooperate with the Lightning
>> Network, and commitment transactions would also delay the side not
>holding
>> the commitment transaction (i.e. "symmetrical delay" commitments), I
>would
>> find it easier to disrupt cheaply if I could wait for a channel to be
>> unbalanced in your favor (i.e. you own more money on it than I do),
>then
>> lock up both our funds by doing a unilateral transaction. Since it
>is
>> unbalanced in your favor, you end up losing more utility than I do.
>> Indeed, in the situation where you are funding a new channel to me, I
>have
>> 0 satoshi on the channel and can perform this attack costlessly.
>>
>> Now perhaps one may argue, in the case of asymmetric delays, that if
>I
>> were evil, I could still disrupt the network by misbehaving and
>forcing the
>> other side to push its commitment transaction. Indeed I could even
>just
>> accept a channel and then always fail to forward any payment you try
>to
>> make over it, performing a disruption costlessly too (as I have no
>money in
>> this). But this attack is somewhat more passive than the above
>attack
>> under a symmetrical delay commitment transaction scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180415/2b1c8937/attachment-0001.html>;