Add support for the official splicing protocol#2887
Open
Conversation
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.
We replace our experimental version of
splice_init,splice_ackandsplice_lockedby their official version (see lightning/bolts#1160). 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_signaturesandsplice_lockedto 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 they won't understand the even TLV field.We do the same thing for the
commit_sigTLV. For peers who support the official splicing version, we insert thestart_batchmessage before the batch ofcommit_sigmessages as specified in lightning/bolts#1160.We also support both the legacy and official reconnection logic (TLV fields in
channel_reestablish). It is a bit painful because both protocols use TLV 1, but for different purposes, so we need to do it in a somewhat hacky way at the codec level.This ensures that we're able to create splice transactions, even with non-upgraded nodes (full backwards-compatibility). It would be best to make sure Phoenix users upgrade to a version that uses the official protocol though, to allow cleaning up the codebase and guarantee that we haven't missed an edge case.
Builds on top of #3261
E2E tests: