Skip to content

Fix off-by-one finalized transaction locktime #2212

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
merged 3 commits into from
Apr 22, 2023

Conversation

wpaulino
Copy link
Contributor

While these transactions were still valid, we incorrectly assumed that they would propagate with a locktime of current_height + 1, when in reality, only those with a locktime strictly lower than the next height in the chain are allowed to enter the mempool.

Fixes #2181.

@wpaulino wpaulino added this to the 0.0.115 milestone Apr 21, 2023
@wpaulino wpaulino requested review from TheBlueMatt and arik-so April 21, 2023 23:52
@codecov-commenter
Copy link

codecov-commenter commented Apr 22, 2023

Codecov Report

Patch coverage: 98.43% and project coverage change: +0.01 🎉

Comparison is base (02ae5cb) 91.53% compared to head (97e4344) 91.54%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2212      +/-   ##
==========================================
+ Coverage   91.53%   91.54%   +0.01%     
==========================================
  Files         104      104              
  Lines       51332    51553     +221     
  Branches    51332    51553     +221     
==========================================
+ Hits        46985    47195     +210     
- Misses       4347     4358      +11     
Impacted Files Coverage Δ
lightning/src/ln/channelmanager.rs 88.82% <ø> (-0.22%) ⬇️
lightning/src/util/test_utils.rs 76.95% <88.88%> (+0.07%) ⬆️
lightning-background-processor/src/lib.rs 83.56% <100.00%> (+6.35%) ⬆️
lightning/src/chain/channelmonitor.rs 94.58% <100.00%> (-0.11%) ⬇️
lightning/src/chain/onchaintx.rs 92.54% <100.00%> (-0.50%) ⬇️
lightning/src/chain/package.rs 90.99% <100.00%> (-1.25%) ⬇️
lightning/src/ln/functional_test_utils.rs 92.79% <100.00%> (+0.05%) ⬆️
lightning/src/ln/functional_tests.rs 98.20% <100.00%> (-0.05%) ⬇️
lightning/src/ln/monitor_tests.rs 97.32% <100.00%> (-0.92%) ⬇️
lightning/src/ln/payment_tests.rs 97.57% <100.00%> (ø)
... and 2 more

... and 16 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Contributor

@arik-so arik-so left a comment

Choose a reason for hiding this comment

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

Nice catch, and makes total sense. Please fix the tests though.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

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

LGTM, indeed gotta fix the bench.

The `height` argument passed to `OnchainTxHandler::block_disconnected`
represents the height being disconnected, and not the current height.
Due to the incorrect assumption, we'd generate a claim with a locktime
in the future.

Ultimately, we shouldn't be generating claims within
`block_disconnected`. Rather, we should retry the claim at a later block
height, since the bitcoin blockchain does not ever roll back without
connecting a new block. Addressing this is left for future work.
In a future commit, we plan to correctly enforce that the spending
transaction has a valid locktime relative to the chain for the node
broascasting it in `TestBroadcaster::broadcast_transaction` to. We catch
up these test node instances to their expected height, such that we do
not fail said enforcement.
While these transactions were still valid, we incorrectly assumed that
they would propagate with a locktime of `current_height + 1`, when in
reality, only those with a locktime strictly lower than the next height
in the chain are allowed to enter the mempool.
@wpaulino wpaulino force-pushed the off-by-one-locktime branch from b8ba85b to 97e4344 Compare April 22, 2023 18:16
@TheBlueMatt TheBlueMatt merged commit bc54441 into lightningdevkit:main Apr 22, 2023
@wpaulino wpaulino deleted the off-by-one-locktime branch April 22, 2023 22:21
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.

Post-merge review ACK 97e4344

@@ -1036,8 +1036,10 @@ impl<ChannelSigner: WriteableEcdsaChannelSigner> OnchainTxHandler<ChannelSigner>
}
}
for ((_package_id, _), ref mut request) in bump_candidates.iter_mut() {
// `height` is the height being disconnected, so our `current_height` is 1 lower.
Copy link

Choose a reason for hiding this comment

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

Trying to claim at next block connection works well, until a user calls invalidateblock and break this assumption, I think (though it’s a quite unorthodox uses of the consensus engine).

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.

Core rejected expired HTLC claim as too soon
5 participants