mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-22 14:22:46 +01:00
Code Issues Projects Releases Wiki Activity

Clarify announcement requirements

Browse source 
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.
This commit is contained in:
t-bast 2025-02-12 12:22:19 +01:00
parent 5912705ed4
commit c79dca9696
No known key found for this signature in database
GPG key ID: 34F377B0100ED6BB
2 changed files with 43 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
02-peer-protocol.md
View file

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

51
07-routing-gossip.md
View file

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