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