From therealsangaman at gmail.com Mon Apr 16 04:39:20 2018 From: therealsangaman at gmail.com (Daniel McNally) Date: Mon, 16 Apr 2018 00:39:20 -0400 Subject: [Lightning-dev] Commitment delay asymmetry In-Reply-To: References: <87vacwvuqn.fsf@rustcorp.com.au> Message-ID: > 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