Remove support for the legacy splicing protocol used by Phoenix#3262
Draft
Remove support for the legacy splicing protocol used by Phoenix#3262
Conversation
In lightning/bolts#1160 we add a TLV field to `commit_sig` messages to let the receiver know to which `funding_txid` this signature applies. This is more resilient than relying on the order of the `commit_sig` messages in the batch. This is an odd TLV, so we can start writing it right now without creating compatibility issues. We also slightly refactor existing code to make it easier to introduce a backwards-compat layer when migrating to the official splicing. We also increase the default number of RBF attempts allowed.
In lightning/bolts#1160, we introduce a message to let our peer know how many `commit_sig` messages they will receive and treat them as a batch. This replaces our previous version that did something similar, but by adding a batch TLV in every `commit_sig` message we send. We currently do both: we keep inserting the experimental batch TLV, and we start by sending a `start_batch` message (with the same information). Since it is an odd message (127), it should be safely ignored if our peer doesn't understand it.
We replace our experimental version of `splice_init`, `splice_ack` and `splice_locked` by their official version. If our peer is using the experimental feature bit, we convert our outgoing messages to use the experimental encoding and incoming messages to the official messages. We also change the TLV fields added to `tx_add_input`, `tx_signatures` and `splice_locked` to match the spec version. We always write both the official and experimental TLV to updated nodes (because the experimental one is odd and will be ignored) but we drop the official TLV if our peer is using the experimental feature, because it won't understand the even TLV field. We do the same thing for the `commit_sig` TLV. For peers who support the official splicing version, we insert the `start_batch` message before the batch of `commit_sig` messages. This guarantees backwards-compatibility with peers who only support the experimental feature.
We introduce a `retransmit_flags` field to `my_current_funding_locked` and `next_funding` to ask our peer to retransmit `commitment_signed` or `announcement_signatures` if we're expecting them. With this change, we don't need to retransmit `splice_locked` on reconnection anymore to trigger the exchange of `announcement_signatures`. We don't need to retransmit it to let our peer know that we've seen enough confirmations for the splice either, since `my_current_funding_locked` implies that. This allows us to completely remove retransmission of `splice_locked` on reconnection, and also get rid of the `your_last_funding_locked` TLV, which greatly simplifies the reconnection logic. We do keep them for backwards-compatibility with existing Phoenix users though, but we'll be able to clean it up once they have updated. Note that this works with taproot channels since we will simply provide nonces in `channel_reestablish` when we need our peer to send announcement signatures (not supported yet since taproot channels are never announced). We rollback using the `next_commitment_number` to let our peer know that we haven't received their `commit_sig` and instead use the retransmit flags added to the `next_funding` TLV, unless our peer is using the legacy splicing protocol.
We remove support for the legacy splicing protocol used by older Phoenix wallets. Phoenix users can simply update their app to get the latest version that supports the official splicing protocol.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
We remove support for the legacy splicing protocol used by older Phoenix wallets. Before merging this PR, we must:
phoenixandphoenixdthat includes Use official splice messages lightning-kmp#768Users that don't upgrade will not be able to reconnect once we deploy this change.
Builds on top of #2887