Batch commitment_signed messages for splicing#3651
Batch commitment_signed messages for splicing#3651wpaulino merged 7 commits intolightningdevkit:mainfrom
commitment_signed messages for splicing#3651Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
|
@wpaulino Just looking for a quick concept ACK. Still needed:
|
wpaulino
left a comment
There was a problem hiding this comment.
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
FundedChannelcommitment_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
jkczyz
left a comment
There was a problem hiding this comment.
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
FundingScopeto 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_signedmessages).