Skip to content

Fix Two Bugs around ChannelManager serialization round-trip #503

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

TheBlueMatt
Copy link
Collaborator

Based on #455 since one of the new tests builds on the tests added there. The pre-block-connected bug I found while playing with rust-lightning-bitcoinrpc, the other one I found while trying to write a test for the first.

Copy link

@ariard ariard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! More comments but otherwise looks good

@TheBlueMatt TheBlueMatt force-pushed the 2020-02-chanmon-ser-roundtrip branch from fd52ba8 to bc90c80 Compare February 17, 2020 22:53
@TheBlueMatt
Copy link
Collaborator Author

Added comments everywhere requested.

@TheBlueMatt TheBlueMatt added this to the 0.0.10 milestone Feb 17, 2020
@ariard
Copy link

ariard commented Feb 18, 2020

ACK bc90c80

Upon deserialization/reload we need to be able to register each
outpoint which spends the commitment txo which a channelmonitor
believes to be on chain. While our other internal tracking is
likely sufficient to regenerate these, its much easier to simply
track all outpouts we've ever generated, so we do that here.
This tests, after each functional test, that if we serialize and
reload all of our ChannelMonitors we end up tracking the same set
of outputs as before.
Previously, when attempting to write out a channel with some
RemoteAnnounced pending inbound HTLCs, we'd write out the count
without them, but write out some of their fields. We should drop
them as intended as they will need to be reannounced upon
reconnection.

This was found while attempting to simply reproduce a different
bug by adding tests for ChannelManager serialization rount-trip at
the end of each functional_test (in Node::drop). That test is
included here to prevent some classes of similar bugs in the future.
Previously, if we have a live ChannelManager (that has seen blocks)
and we open a new Channel, if we serialize that ChannelManager
before a new block comes in, we'll fail to deserialize it. This is
the result of an overly-ambigious last_block_connected check which
would see 0s for the new channel but the previous block for the
ChannelManager as a whole.

We add a new test which catches this error as well as hopefully
getting some test coverage for other similar issues in the future.
@TheBlueMatt TheBlueMatt force-pushed the 2020-02-chanmon-ser-roundtrip branch from bc90c80 to 4b189bd Compare February 18, 2020 23:24
@TheBlueMatt TheBlueMatt merged commit 69c3eb2 into lightningdevkit:master Feb 19, 2020
@TheBlueMatt TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants