From pm+lists at acinq.fr Fri Jan 12 11:56:39 2018 From: pm+lists at acinq.fr (Pierre) Date: Fri, 12 Jan 2018 12:56:39 +0100 Subject: [Lightning-dev] Insufficient funder balance for paying fees In-Reply-To: <68e0ce2c-9218-4c9a-b932-27417d116c24@gmail.com> References: <68e0ce2c-9218-4c9a-b932-27417d116c24@gmail.com> Message-ID: Hi Johan, That's an interesting corner case. I think it shares some similarities with the race condition described in BOLT 2 [1], which handling is specified in BOLT 3 [2]. Note that what matters really is the timing of the `commit_sig`/`revoke_and_ack` messages, not the `update_add_htlc`s, because of the acknowledgment logic that excludes remote's unsigned updates. A side effect is that there can be multiple HTLCs on each side. Each party will end up receiving a commitment tx which has insufficient (possibly zero) fees. At that point according to [2] it may decide to fail the channel, using its previous commitment (which it hasn't yet revoked). Currently eclair won't fail the channel, but I think we probably should, especially if we are the fundee and would end up with all funds in an unpublishable tx. The funder could face the same situation if the pending htlcs have a high value (at this point its main output is zero anyway). An appropriate choice of channel parameters (`mainly max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`, `max_accepted_htlcs`) could probably reduce the probability of this happening. Hope that helps, Pierre [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee [2] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment