[WIP] Bump Claim Txn #333
Closed
[WIP] Bump Claim Txn #333
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
March 28, 2019 20:49
Broadcasting a commitment tx means that we have to fail inbound HTLC in backward channel. Doing it prematurely would put us at risk in case of reorg. So we delay passing failure update upstream until solving tx mature to HTLC_FAIL_ANTI_ REORG_DELAY. Requirements differ if HTLC is a revoked/non-revoked dust/ non-revoked non-dust one. Add connect_blocks in test_utils to fix broken tests due to anti-reorg delay enforcement Remove anti-duplicate htlc update stuff in ManySimpleChannelMonitor
Modify ChainListener API by adding height field to block_disconnect
Fix tests broken by introduced change
Add test_failure_delay_htlc_local_commitment Move some bits of check_spend_remote as we need to fail dust HTLCs which can be spread on both prev/lastest local commitment tx
Add pruning of waiting-conf channel closing at block_disconnect Fix tests broken by introduced change
We need also to track claim tx until their maturation to know when we may safely remove them from could-be-bumped-txn buffer
When we generate a justice tx, a htlc tx on remote commitment or a htlc tx on local commitment we track them until first conf. If first conf doesn't happen before height timer expiration, we regenerate claim tx from its cached marerial with a higher fee. We use RBF or CPFP following the class of claim tx.
|
Much have been rewritten in #347 |
ariard
pushed a commit
to ariard/rust-lightning
that referenced
this pull request
Oct 14, 2020
We remove test_no_failure_dust_htlc_local_commitment from our test framework as this test deliberately throwing junk transaction in our monitoring parsing code is hitting new assertions. This test was added in lightningdevkit#333, but it sounds as an oversight as the correctness intention of this test (i.e verifying lack of dust HTLCs canceling back in case of junk commitment transaction) doesn't currently break.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #305, have to go after a yet-not-written-add-fee-estimator-thing-in-monitor PR.
Note: follow previous discussion, but need more thought on timer height.
Note: need to move spendable_output stuff after claim_tx maturation ( + TODO #334 (comment))