Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-12 📝 Original message: Hi Pierre, You’re ...
đź“… Original date posted:2018-01-12
đź“ť Original message:
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 <pm+lists at acinq.fr> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180112/c18884a0/attachment.html>;
đź“ť Original message:
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 <pm+lists at acinq.fr> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180112/c18884a0/attachment.html>;