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

@@ -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

07-routing-gossip.md

@@ -84,37 +84,47 @@ 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):
     - If it has NOT previously received `announcement_signatures` for the funding transaction:
       - 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
 
 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