Send `channel_announcement` for splice transactions on public channels #2968

t-bast · 2024-12-18T15:53:13Z

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_ids 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.

NB: builds on top of #2969

We already use a minimum depth of 6 before announcing channels to protect against reorgs. However, we allowed using the channel for payments after only 3 confirmations (for small channels). A reorg of 3 blocks that invalidates the funding transaction would allow our peer to potentially steal funds. It's more consistent to use the same depth for announcing the channel and actually using it. Note that for wumbo channels, we already scaled the number of confirmations based on the size of the channel. For closing transaction, we don't need the same reorg safety, since we keep watching the funding output for any transaction that spends it, and concurrently spend any commitment transaction that we detect. We thus keep a minimum depth of 3 for closing transactions.

We were still using values from before the halving. We update those values and change the scaling factor to a reasonable scaling. This protects channels against attackers with significant mining power.

Now that we wait for at least 6 confirmations before considering a channel confirmed, we can simplify our channel announcement logic. Whenever a channel reaches the confirmed state, it can be announced to the network (if nodes wish to announce it). We thus don't need the "deeply buried" state and the "temporary" scid anymore. The logic is much simpler to follow: when the channel confirms, we internally update the real scid to match the confirmed funding tx and send our `announcement_signatures`. When we receive our peer's `announcement_signatures`, we stash them if the funding tx doesn't have enough confirmations yet, otherwise we announce the channel and create a new `channel_update` that uses the real scid. Whenever we create a `channel_update`, we simply look at whether the channel is announced or not to choose which scid to use. This will make it much simpler to announce splice transactions, which don't need a "deeply buried" state either and will instead simply rely on whether the splice transaction is confirmed or not to generate `announcement_signatures`.

t-bast · 2024-12-31T15:47:16Z

eclair-core/src/main/scala/fr/acinq/eclair/wire/internal/channel/version3/ChannelCodecs3.scala

@@ -327,6 +327,14 @@ private[channel] object ChannelCodecs3 {
        ("claimHtlcDelayedPenaltyTxs" | listOfN(uint16, claimHtlcDelayedOutputPenaltyTxCodec)) ::
        ("spent" | spentMapCodec)).as[RevokedCommitPublished]

+    private val shortids: Codec[ShortIdAliases] = (


Important note: for channels encoded with v3 or lower, we don't add any migration code, so it looks like we're losing information about the real short_channel_id, but that isn't the case: since we set localFundingStatus to unconfirmed (in ChannelTypes0.scala and ChannelTypes3.scala), we will set a WatchFundingConfirmed when restarting which lets us obtain details about the funding transaction and correctly set the short_channel_id.

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 added 3 commits December 26, 2024 10:36

Update confirmation scaling factor post-halving

083da33

We were still using values from before the halving. We update those values and change the scaling factor to a reasonable scaling. This protects channels against attackers with significant mining power.

t-bast force-pushed the per-commitment-channel-announcement branch 3 times, most recently from defefb4 to 54de064 Compare December 31, 2024 15:41

t-bast changed the title ~~Move channel_announcement to Commitment~~ Add support for announcing public splice transactions Dec 31, 2024

t-bast changed the title ~~Add support for announcing public splice transactions~~ Send channel_announcement for splice transactions on public channels Dec 31, 2024

t-bast commented Dec 31, 2024

View reviewed changes

t-bast force-pushed the per-commitment-channel-announcement branch from bf46309 to 29abd57 Compare December 31, 2024 16:56

t-bast force-pushed the per-commitment-channel-announcement branch from 29abd57 to 29628d5 Compare January 2, 2025 10:58

t-bast mentioned this pull request Jan 2, 2025

Use final spec values for splicing #2887

Draft

t-bast marked this pull request as ready for review January 2, 2025 14:51

t-bast requested review from remyers and pm47 January 2, 2025 14:51

This was referenced Jan 3, 2025

Update scid when splice funding tx confirms #2941

Closed

Splicing out funds should update router balances #2912

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Send `channel_announcement` for splice transactions on public channels #2968

Send `channel_announcement` for splice transactions on public channels #2968

t-bast commented Dec 18, 2024 •

edited

Loading

t-bast Dec 31, 2024

Send channel_announcement for splice transactions on public channels #2968

Are you sure you want to change the base?

Send channel_announcement for splice transactions on public channels #2968

Conversation

t-bast commented Dec 18, 2024 • edited Loading

t-bast Dec 31, 2024

Choose a reason for hiding this comment

Send `channel_announcement` for splice transactions on public channels #2968

Send `channel_announcement` for splice transactions on public channels #2968

t-bast commented Dec 18, 2024 •

edited

Loading