From johanth at gmail.com Fri Jan 12 12:41:09 2018 From: johanth at gmail.com (=?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?=) Date: Fri, 12 Jan 2018 13:41:09 +0100 Subject: [Lightning-dev] Insufficient funder balance for paying fees In-Reply-To: References: <68e0ce2c-9218-4c9a-b932-27417d116c24@gmail.com> Message-ID: <581bb2d0-44df-40ba-9162-12c5dcb4c835@gmail.com> Hi Pierre, You?re right, that looks very much like the same kind of situation! I agree, it looks from [2] that a node may fail the channel in this case, and that it probably should to not risk end up with all funds in an unpublishable tx. Seems like something that could be used as a DOS attack vector by a malicious counter party otherwise. Relevant to this: We use a node?s resulting output (that is, after subtracting fees) when checking that the channel_reserve is met. In these cases we can therefore end up violating the reserve, even though none of the nodes are actually violating the protocol. When this happens we don?t really end up with an unpublishable tx, as the fees are still high enough, and I guess each node can choose what to do. I think we will just fail the channel to not have to deal with this as a special case. Anyway, I think these are cases that are not very likely to occur, especially with the right choice of parameters as you mention. And because of this it might be less error-prone to just fail the channel instead of trying to recover from it. Thanks! - Johan On Fri, Jan 12, 2018 at 12:56, Pierre wrote: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: