]> git.bitcoin.ninja Git - rust-lightning/commit
Fail holding-cell AddHTLCs on Channel deser to match disconnection 2020-11-holding-cell-add-panic
authorMatt Corallo <git@bluematt.me>
Thu, 19 Nov 2020 00:28:09 +0000 (19:28 -0500)
committerMatt Corallo <git@bluematt.me>
Thu, 19 Nov 2020 01:23:47 +0000 (20:23 -0500)
commit1ecee17d03fb165384c88c893203cc1374f10126
tree552dbaa94b41b27e756a0000275e8972f5055993
parent4e82003261e11ece5d5fb3b13f686c9f7a0d2aaf
Fail holding-cell AddHTLCs on Channel deser to match disconnection

As Channel::write says in the comment at the top: "we write out as
if remove_uncommitted_htlcs_and_mark_paused had just been called",
except that we previously deliberately included holding-cell
AddHTLC events in the serialization. On the flip side, in
remove_uncommitted_htlcs_and_mark_paused, we removed pending
AddHTLC events under the assumption that, if we can't forward
something ASAP, its better to fail it back to the origin than to
sit on it for a while.

Given there's likely to be just as large a time-lag between
ser/deserialization as between when a peer dis/reconnects, there
isn't much of a reason for this difference. Worse, we debug_assert
that there are no pending AddHTLC holding cell events when doing a
reconnect, so any tests or fuzzers which deserialized a
ChannelManager with AddHTLC events would panic.

We resolve this by adding logic to fail any holding-cell AddHTLC
events upon deserialization, in part because trying to forward it
before we're sure we have an up-to-date chain is somewhat risky -
the sender may have already gone to chain while our upstream has
not.
lightning/src/ln/chanmon_update_fail_tests.rs
lightning/src/ln/channel.rs
lightning/src/ln/channelmanager.rs