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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
