Daniel McNally [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-16 📝 Original message: > Since there is no delay ...
📅 Original date posted:2018-04-16
📝 Original message:
> 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.
Perhaps I should have clarified, the side unilaterally closing the
channel would always have to wait for the full delay to allow time for
revoke transactions to be broadcast, preventing the scenario you bring
up. It's a matter of what delay is imposed on the other side.
My understanding is that, currently, each channel has an agreed upon
CSV delay and each side's commitment transaction(s) has this delay for
their own output only. Jim's suggesting to apply this same delay to
the remote output as well. I'm wondering if it would make more sense
to scale the delay on the remote output according to the balance
distribution (while leaving the local outputs with the full delay) to
avoid the situation where a misbehaving node can unilaterally close
channels where it has little or no balance, thereby locking up the
funds of the remote node at virtually no cost to itself. The delay on
the remote output would scale from zero delay (what it always is
currently) up to the same delay as the side unilaterally closing the
channel. That wouldn't always make it completely symmetric (at least
in terms of coins locked * duration of lock), but it seems like an
improvement.
Daniel
📝 Original message:
> 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.
Perhaps I should have clarified, the side unilaterally closing the
channel would always have to wait for the full delay to allow time for
revoke transactions to be broadcast, preventing the scenario you bring
up. It's a matter of what delay is imposed on the other side.
My understanding is that, currently, each channel has an agreed upon
CSV delay and each side's commitment transaction(s) has this delay for
their own output only. Jim's suggesting to apply this same delay to
the remote output as well. I'm wondering if it would make more sense
to scale the delay on the remote output according to the balance
distribution (while leaving the local outputs with the full delay) to
avoid the situation where a misbehaving node can unilaterally close
channels where it has little or no balance, thereby locking up the
funds of the remote node at virtually no cost to itself. The delay on
the remote output would scale from zero delay (what it always is
currently) up to the same delay as the side unilaterally closing the
channel. That wouldn't always make it completely symmetric (at least
in terms of coins locked * duration of lock), but it seems like an
improvement.
Daniel