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:
|
| claimed_htlcs: ref mut update_claimed_htlcs, .. | ||
| } = &mut update { | ||
| debug_assert!(update_claimed_htlcs.is_empty()); | ||
| *update_claimed_htlcs = claimed_htlcs.clone(); |
There was a problem hiding this comment.
Hm, it'd be nice to not have this duplicated data, but I guess it's pretty small anyway.
Somewhat related, in #3606 we're introducing a new update variant (for the counterparty commitment only, but we'll need to do the same for the holder commitment as well) that only tracks the commitment transaction. I wonder if we can get away with using it for the additional funding scopes as a way to simplify the transition to the new variant, as you wouldn't be allowed to downgrade with a pending spliced channel anyway.
|
👋 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 |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
eac7be9 to
8b4e46a
Compare
jkczyz
changed the title
FundedChannelcommitment_signed messages for splicing
lightning/src/ln/channel.rs
Outdated
| // May or may not have a pending splice | ||
| Some(batch) => { | ||
| self.commitment_signed_batch.push(msg.clone()); | ||
| if self.commitment_signed_batch.len() < batch.batch_size as usize { |
There was a problem hiding this comment.
We should also consider the number of scopes available. We shouldn't receive a batch with anything other than that number.
There was a problem hiding this comment.
There may be an edge case to consider. I started a discussion on the spec: https://github.com/lightning/bolts/pull/1160/files/8c907f6b8d26fad8ec79ad1fe3078eb92e5285a6#r1990528673
Though if pending_funding is empty, the spec states we should ignore any batched commitment_signed messages that don't match the new funding_txid.
- If
batchis set:
...
- Otherwise (no pending splice transactions):
- MUST ignore
commitment_signedwherefunding_txiddoes not match
the current funding transaction.- If
commitment_signedis missing for the current funding transaction:
- MUST send an
errorand fail the channel.- Otherwise:
- MUST respond with a
revoke_and_ackmessage.
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 |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
c66e554 to
2db5c60
Compare
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
2 times, most recently
from
3872586 to
e371143
Compare
|
Rebased on main. |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
e371143 to
0362159
Compare
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
0362159 to
7021e01
Compare
|
Responded and addressed a couple lingering comments. |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
3 times, most recently
from
48bdd52 to
6db1c42
Compare
|
Will rebase in a separate push. |
|
This is pretty much there, will give it a final pass once squashed and rebased |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
1695c74 to
1456a7d
Compare
|
Rebased and fixed fuzz tests (compilation error and log assertion update). |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
1456a7d to
19e8b5c
Compare
|
Rebased again to resolve a couple merge conflicts and squashed. |
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
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.
jkczyz
force-pushed
the
2025-03-multiple-funding-scopes
branch
from
cbd7bf8 to
80e3235
Compare
|
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).