Send channel_announcement for splice transactions on public channels#2968
Merged
Conversation
t-bast
force-pushed
the
per-commitment-channel-announcement
branch
3 times, most recently
from
defefb4 to
54de064
Compare
t-bast
changed the title
channel_announcement to Commitment
t-bast
changed the title
channel_announcement for splice transactions on public channels
t-bast
force-pushed
the
per-commitment-channel-announcement
branch
2 times, most recently
from
29abd57 to
29628d5
Compare
This was referenced Jan 3, 2025
remyers
suggested changes
Jan 10, 2025
remyers
left a comment
remyers
left a comment
Contributor
There was a problem hiding this comment.
I've taken a first pass and it looks good so far. I've focused mostly on the channel and router behavior; less on the serialization so far.
During a channel reestablishment it seems like we only resend announcement sigs when no announcement was sent during initial funding, but not during splices.
I also have a few questions and suggestions to add tests for a few incidental bug fixes you made during the refactor that probably don't have associated tests.
t-bast
force-pushed
the
per-commitment-channel-announcement
branch
from
29628d5 to
1bf54c1
Compare
remyers
suggested changes
Jan 14, 2025
remyers
left a comment
remyers
left a comment
Contributor
There was a problem hiding this comment.
The serialization code looks pretty straight forward for the most part. I do have one suggestion and found one potential issue related to moving the real scid to the funding status.
remyers
previously approved these changes
Jan 15, 2025
t-bast
dismissed
remyers’s stale review
The merge-base changed after approval.
t-bast
force-pushed
the
per-commitment-channel-announcement
branch
from
1bf54c1 to
ab2a830
Compare
We now support splicing on public channels: once the splice transaction is confirmed and locked on both sides, nodes will exchange announcement signatures that allows them to create a `channel_announcement` that they then broadcast to the network. This requires reworking the data model to include the announcement and the real `short_channel_id` in each commitment, which lets us cleanly distinguish real `short_channel_id`s from aliases (which are set at the channel level regardless of the current commitments). The flow now becomes: - when the funding transaction of a commitment confirms, we set the corresponding real `short_channel_id` in that commitment - if the channel is public and we've received `channel_ready` or `splice_locked`, we send our `announcement_signatures` - if we receive `announcement_signatures` for a commitment for which the funding transaction is unconfirmed, we stash it and replay it when the transaction confirms - if we receive `announcement_signatures` for a confirmed commitment, and we don't have a more recently announced commitment, we generate a `channel_announcement`, store it with the commitment and update our router data When creating a `channel_update` for a public channel, we always use the `short_channel_id` that matches the latest announcement we created. This is very important to guarantee that nodes receiving our updates will not discard them because they cannot match it to a channel. For private channels, we stop allowing usage of the `short_channel_id` for routing: `scid_alias` MUST be used, which ensures that the channel utxo isn't revealed. Note that when migrating to taproot channels, `splice_locked` will be used to transmit nonces for the announcement signatures, which will be compatible with the existing flow (and similarly, `channel_ready` will be used for the initial funding transaction). They are retransmitted on reconnection to ensure that the announcements can be generated.
t-bast
force-pushed
the
per-commitment-channel-announcement
branch
from
ab2a830 to
aae0c20
Compare
pm47
reviewed
Jan 28, 2025
It was a bit overkill to put it inside each `Commitment`, as we only care about the last one: we can keep this in the channel state instead.
pm47
reviewed
Jan 30, 2025
And make past codecs decode-only.
pm47
approved these changes
Jan 30, 2025
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
3 participants
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 now support splicing on public channels: once the splice transaction is confirmed and locked on both sides, nodes will exchange announcement signatures that allows them to create a
channel_announcementthat they then broadcast to the network.This requires reworking the data model to include the announcement and the real
short_channel_idin each commitment, which lets us cleanly distinguish realshort_channel_ids from aliases (which are set at the channel level regardless of the current commitments).The flow now becomes:
short_channel_idin that commitmentchannel_readyorsplice_locked, we send ourannouncement_signaturesannouncement_signaturesfor a commitment for which the funding transaction is unconfirmed, we stash it and replay it when the transaction confirmsannouncement_signaturesfor a confirmed commitment, and we don't have a more recently announced commitment, we generate achannel_announcement, store it with the commitment and update our router dataWhen creating a
channel_updatefor a public channel, we always use theshort_channel_idthat matches the latest announcement we created. This is very important to guarantee that nodes receiving our updates will not discard them because they cannot match it to a channel.For private channels, we stop allowing usage of the
short_channel_idfor routing:scid_aliasMUST be used, which ensures that the channel utxo isn't revealed.Note that when migrating to taproot channels,
splice_lockedwill be used to transmit nonces for the announcement signatures, which will be compatible with the existing flow (and similarly,channel_readywill be used for the initial funding transaction). They are retransmitted on reconnection to ensure that the announcements can be generated.Don't be scared by the large number of added lines: most of them are JSONs for backwards-compatibility serialization tests.