From c79dca96969d7496f863e58768303ec56a0b3b90 Mon Sep 17 00:00:00 2001 From: t-bast Date: Wed, 12 Feb 2025 12:22:19 +0100 Subject: [PATCH] Clarify announcement requirements We make the requirements for `announcement_signatures` more clear. It is important that both nodes are able to generate the corresponding `channel_announcement` to allow them to create a new `channel_update` using the `short_channel_id` of the confirmed splice. We insist on exchanging `splice_locked` before generating signatures to ensure compatibility with taproot channels, where nonces will be exchanged in `splice_locked` messages. This means that we need to retransmit `splice_locked` on reconnection if `announcement_signatures` hasn't been fully exchanged. Importantly, after announcing a splice, nodes must still allow payments that use the previous `short_channel_id`, because remote nodes may not have processed the `channel_announcement` and `channel_update`s yet. --- 02-peer-protocol.md | 7 ++++++ 07-routing-gossip.md | 51 +++++++++++++++++++++++++++++++------------- 2 files changed, 43 insertions(+), 15 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 3085959..6942305 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -3259,6 +3259,13 @@ The sending node: - MUST set `my_current_funding_locked` to the txid of the channel funding transaction. - otherwise (it has never sent `channel_ready` or `splice_locked`): - MUST NOT set `my_current_funding_locked`. + - if `my_current_funding_locked` is included and `announce_channel` is set for this channel: + - if it has not received `announcement_signatures` for that transaction: + - MUST retransmit `channel_ready` or `splice_locked` after `channel_reestablish`. + - if it receives `channel_ready` for that transaction after `channel_reestablish`: + - MUST retransmit `channel_ready` in response, if not already sent. + - if it receives `splice_locked` for that transaction after `channel_reestablish`: + - MUST retransmit `splice_locked` in response, if not already sent. A node: - if `next_commitment_number` is 1 in both the `channel_reestablish` it diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 972bb8a..cc41ec2 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -84,10 +84,10 @@ matching an endpoint's `node_id` and `bitcoin_key`. A node: - If the `open_channel` message has the `announce_channel` bit set AND a `shutdown` message has not been sent: - - MUST NOT send `announcement_signatures` until `channel_ready` or `splice_locked` has been sent and received for that transaction. - - MUST NOT send `announcement_signatures` until the funding transaction has enough confirmations to ensure that it won't be reorganized. - - Otherwise: - - MUST send the `announcement_signatures` message. + - After `channel_ready` has been sent and received AND the funding transaction has enough confirmations to ensure that it won't be reorganized: + - MUST send `announcement_signatures` for the funding transaction. + - After `splice_locked` has been sent and received AND the splice transaction has enough confirmations to ensure that it won't be reorganized: + - MUST send `announcement_signatures` for the matching splice transaction. - Otherwise: - MUST NOT send the `announcement_signatures` message. - Upon reconnection (once the above timing requirements have been met): @@ -95,19 +95,23 @@ A node: - MUST send its own `announcement_signatures` message. - If it receives `announcement_signatures` for the funding transaction: - MUST respond with its own `announcement_signatures` message. + - If it has NOT previously received `announcement_signatures` for a splice transaction: + - MUST retransmit `splice_locked` for that splice transaction. + - After receiving the remote `splice_locked`: + - MUST send its `announcement_signatures` message. A recipient node: - - If the `short_channel_id` is NOT correct: - - SHOULD send a `warning` and close the connection, or send an - `error` and fail the channel. + - If the `short_channel_id` doesn't match one of its funding transactions: + - SHOULD send a `warning`. - If the `node_signature` OR the `bitcoin_signature` is NOT correct: - - MAY send a `warning` and close the connection, or send an - `error` and fail the channel. + - MAY send a `warning` and close the connection, or send an `error` and fail the channel. - If it has sent AND received a valid `announcement_signatures` message: - If the funding transaction has at least 6 confirmations: - SHOULD queue the `channel_announcement` message for its peers. - If it has not sent `channel_ready`: - SHOULD defer handling the `announcement_signatures` until after it has sent `channel_ready`. + - If it has not sent `splice_locked` for the transaction matching this `short_channel_id`: + - SHOULD defer handling the `announcement_signatures` until after it has sent `splice_locked`. ### Rationale @@ -115,6 +119,12 @@ Channels must not be announced before the funding transaction has enough confirmations, because a blockchain reorganization would otherwise invalidate the `short_channel_id`. +When splicing is used, a `channel_announcement` is generated for every splice +transaction once both sides have sent `splice_locked`. This lets the network +know that the transaction spending a currently active channel is a splice and +not a closing transaction, and this channel can still be used with its updated +`short_channel_id`. + ## The `channel_announcement` Message This gossip message contains ownership information regarding a channel. It ties @@ -164,9 +174,18 @@ The origin node: that the channel was opened within: - for the _Bitcoin blockchain_: - MUST set `chain_hash` value (encoded in hex) equal to `6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000`. - - MUST set `short_channel_id` to refer to the confirmed funding transaction, - as specified in [BOLT #2](02-peer-protocol.md#the-channel_ready-message). - - Note: the corresponding output MUST be a P2WSH, as described in [BOLT #3](03-transactions.md#funding-transaction-output). + - When announcing a channel creation: + - MUST set `short_channel_id` to refer to the confirmed funding transaction, + as specified in [BOLT #2](02-peer-protocol.md#the-channel_ready-message). + - When announcing a splice transaction: + - MUST set `short_channel_id` to refer to the confirmed splice transaction + for which `splice_locked` has been sent and received, as specified in + [BOLT #2](02-peer-protocol.md#the-splice_locked-message). + - SHOULD keep relaying payments that use the `short_channel_id`s of its + previous `channel_announcement`s. + - SHOULD send a new `channel_update` using the `short_channel_id` that + matches the latest `channel_announcement`. + - Note: the corresponding output MUST be a P2WSH, as described in [BOLT #3](03-transactions.md#funding-transaction-output). - MUST set `node_id_1` and `node_id_2` to the public keys of the two nodes operating the channel, such that `node_id_1` is the lexicographically-lesser of the two compressed keys sorted in ascending lexicographic order. @@ -254,9 +273,11 @@ optional) features will have _odd_ feature bits, while incompatible features will have _even_ feature bits (["It's OK to be odd!"](00-introduction.md#glossary-and-terminology-guide)). -A delay of 12 blocks is used when forgetting a channel on funding output spend -as to permit a new `channel_announcement` to propagate which indicates this -channel was spliced. +A delay of 12 blocks is used when forgetting a channel after detecting that it +has been spent: this can allow a new `channel_announcement` to propagate to +indicate that this channel was spliced and not closed. Thanks to this delay, +payments can still be relayed on the channel while the splice transaction is +waiting for enough confirmations. ## The `node_announcement` Message