-
Notifications
You must be signed in to change notification settings - Fork 414
Batch commitment_signed
messages for splicing
#3651
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
Batch commitment_signed
messages for splicing
#3651
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
@wpaulino Just looking for a quick concept ACK. Still needed:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this makes sense. We'll need to support sending a commitment_signed
for each scope as well.
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
By this do you mean we'll need |
Pushed another commit for |
Yeah we'll need to go through each case where we owe the counterparty a |
eac7be9
to
8b4e46a
Compare
FundedChannel
commitment_signed
messages for splicing
Pushed a couple commits that I think accomplish this. Though I'm not sure about the following line from rust-lightning/lightning/src/ln/channel.rs Lines 8621 to 8622 in c66e554
It is called from methods like |
c66e554
to
2db5c60
Compare
3872586
to
e371143
Compare
Rebased on main. |
e371143
to
0362159
Compare
0362159
to
7021e01
Compare
Responded and addressed a couple lingering comments. |
48bdd52
to
6db1c42
Compare
This is pretty much there, will give it a final pass once squashed and rebased |
1695c74
to
1456a7d
Compare
Rebased and fixed fuzz tests (compilation error and log assertion update). |
1456a7d
to
19e8b5c
Compare
Rebased again to resolve a couple merge conflicts and squashed. |
19e8b5c
to
cbd7bf8
Compare
Looks like CI was failing because the benchmarks failed to compile. Fixed in the latest push. |
Oops already needs rebase. |
Once a channel is funded, it may be spliced to add or remove funds. The new funding transaction is pending until confirmed on chain and thus needs to be tracked. Additionally, it may be replaced by another transaction using RBF with a higher fee. Hence, there may be more than one pending FundingScope to track for a splice. This commit adds support for tracking pending funding scopes. The following commits will account for any pending scopes where applicable (e.g., when handling commitment_signed).
A FundedChannel may have more than one pending FundingScope during splicing, one for the splice attempt and one or more for any RBF attempts. When this is the case, send a commitment_signed message for each FundingScope and include the necessary batch information (i.e., batch_size and funding_txid) to the counterparty.
Splicing introduces a concept of batched commitment_signed messages for each pending splice transaction. These can be treated as one logical message, even though the protocol currently defines them as separate commitment_signed messages with a TLV for batch information. Add a LogicalMessage wrapper around wire::Message such that it can be used internally by PeerManager. A CommitmentSignedBatch variant will be added in the next commit.
During splicing, commitment_signed messages need to be collected into a single batch before they are handled. Rather than including this as part of the channel state machine logic, batch when reading messages from the wire since they can be considered one logical message.
A FundedChannel may have more than one pending FundingScope during splicing, one for the splice attempt and one or more for any RBF attempts. The counterparty will send a commitment_signed message for each pending splice transaction and the current funding transaction. Defer handling these commitment_signed messages until the entire batch has arrived. Then validate them individually, also checking if all the pending splice transactions and the current funding transaction have a corresponding commitment_signed in the batch.
A FundedChannel may have more than one pending FundingScope during splicing, one for the splice attempt and one or more for any RBF attempts. When calling get_available_balances, consider all funding scopes and take the minimum by next_outbound_htlc_limit_msat. This is used both informationally and to determine which channel to use to forward an HTLC. The choice of next_outbound_htlc_limit_msat is somewhat arbitrary but matches the field used when determining which channel used to forward an HTLC. Any field should do since each field should be adjusted by the same amount relative to another FundingScope given the nature of the fields (i.e., inbound/outbound capacity, min/max HTLC limit). Using the minimum was chosen since an order for an HTLC to be sent over the channel, it must be possible for each funding scope -- both the confirmed one and any pending scopes, one of which may eventually confirm.
cbd7bf8
to
80e3235
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebased to resolve merge conflict.
Merging this as the linting failure has already been fixed separately. |
Once a channel is funded, it may be spliced to add or remove funds. The new funding transaction is pending until confirmed on chain and thus needs to be tracked. Additionally, it may be replaced by another transaction using RBF with a higher fee. Hence, there may be more than one pending
FundingScope
to track for a splice.This PR adds support for tracking pending funding scopes and accounting for any pending scopes where applicable (e.g., when handling and sending
commitment_signed
messages).