đ
Original date posted:2018-01-12
đ Original message:
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
Pierre [ARCHIVE] /
npub1yzâŚy4pdt
2023-06-09 12:48:32
in reply to nevent1qâŚ7exc
Author Public Key
npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdtPublished at
2023-06-09 12:48:32Event JSON
{
"id": "5c5515c8da2fbce9a4007b71335c8de5960478a7d35f10a3796edb9dc533162e",
"pubkey": "208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff",
"created_at": 1686314912,
"kind": 1,
"tags": [
[
"e",
"344f05c5496273bfa44ccfa6bc653dfc6b5c5ec1dbf8885ef9c1f18fa5d1ad44",
"",
"root"
],
[
"e",
"0c327ff9404d1db0e65559a9d761a9607b4fe650aae12a3931e1f193a46cf9c7",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "đ
Original date posted:2018-01-12\nđ Original message:\nHi Johan,\n\nThat's an interesting corner case. I think it shares some similarities\nwith the race condition described in BOLT 2 [1], which handling is\nspecified in BOLT 3 [2].\n\nNote that what matters really is the timing of the\n`commit_sig`/`revoke_and_ack` messages, not the `update_add_htlc`s,\nbecause of the acknowledgment logic that excludes remote's unsigned\nupdates. A side effect is that there can be multiple HTLCs on each\nside.\n\nEach party will end up receiving a commitment tx which has\ninsufficient (possibly zero) fees. At that point according to [2] it\nmay decide to fail the channel, using its previous commitment (which\nit hasn't yet revoked). Currently eclair won't fail the channel, but I\nthink we probably should, especially if we are the fundee and would\nend up with all funds in an unpublishable tx. The funder could face\nthe same situation if the pending htlcs have a high value (at this\npoint its main output is zero anyway).\n\nAn appropriate choice of channel parameters (`mainly\nmax_htlc_value_in_flight_msat`, `channel_reserve_satoshis`,\n`max_accepted_htlcs`) could probably reduce the probability of this\nhappening.\n\nHope that helps,\n\nPierre\n\n[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee\n[2] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fee-payment",
"sig": "68d9541b0dd75228b841a23c4fb6913ae65bb2e013e3115a3138ba257149b2a4af8f875cd7371cd17b1a6d17102c854ed9e283d883f7e624981e500f85c50902"
}