lightningd: use CPFP on peer's commitment tx if we can't broadcast our own #6752
Conversation
This file contains 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
rustyrussell
force-pushed
the
guilt/push-peer-anchor
branch
from
97bfd12
to
08a68d4
Compare
Merged
rustyrussell
force-pushed
the
guilt/push-peer-anchor
branch
2 times, most recently
from
07ef6ac
to
92b40ad
Compare
|
Trivial fix: postgres caught me accessing an int field with a u64 accessor. And rebased. |
We try to use anchors to CPFP our own commitment, but what if they get there first? We also need to use anchors on the commitment txs they broadcast. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…ing_commitsig We don't actually use this at all. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
channel_txs was a thin wrapper around channel_splice_txs, but that's just confusing. Rename channel_splice_txs to channel_txs, and just call it everywhere. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're going to want this, soon. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's going to want to remember these, in case it encounters peers' commitment tx and needs to boost it with CPFP on the anchor. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Store enough to know how to CPFP the peer's commitment tx. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We actually only need to remember the last two, worst case. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
…ur own. This means refactoring out some of the generic anchor info, from the per-commitment-tx info (we can have at least two, perhaps more with splicing!). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
nepet
force-pushed
the
guilt/push-peer-anchor
branch
from
92b40ad
to
d3d6e5b
Compare
|
Rebased, merged |
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 #6751(Merged!)@t-bast pointed out that we should do this. He's right, but I didn't want to try to reconstruct the peer's commitment transaction, so I save them at signing time: we only need to keep information about anchors on the last two commitment transactions, worst case (there may be more than two, due to splicing), as earlier ones are sure to be revoked.