mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-13 11:35:41 +01:00
Code Issues Projects Releases Wiki Activity

More clarifications around channel_announcement handling

Browse source 
This is a follow-up of #1215, where we keep reworking the announcement
requirements.

We remove the rationale around deferring after `channel_ready` since
that has been changed years ago and shouldn't be an issue anymore.

We slightly rework the wording to minimize future conflicts with the
splicing PR.

While nodes are free to send `announcement_signatures` whenever they
feel that the channel is safe from reorg, we disallow broadcasting the
`channel_announcement` before at least 6 confirmations: this gives nodes
a simple heuristic to ignore `channel_announcement`s for remote channels
that aren't spec-compliant, without having to deal with the extra cost
of managing reorgs.
This commit is contained in:
t-bast 2025-01-15 11:31:40 +01:00
parent e96c3c59bb
commit c217e80e2b
No known key found for this signature in database
GPG key ID: 34F377B0100ED6BB
1 changed files with 26 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
07-routing-gossip.md
View file

@ -78,43 +78,37 @@ The willingness of the initiating node to announce the channel is signaled durin
### Requirements
The `announcement_signatures` message is created by constructing a `channel_announcement` message, corresponding to the newly established channel, and signing it with the secrets matching an endpoint's `node_id` and `bitcoin_key`. After it's signed, the
`announcement_signatures` message may be sent.
The `announcement_signatures` message is created by constructing a `channel_announcement` message,
corresponding to the newly confirmed channel funding transaction, and signing it with the secrets
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 send the `announcement_signatures` message.
- MUST NOT send `announcement_signatures` until `channel_ready` has been sent and received.
- MUST NOT send `announcement_signatures` until the funding transaction has enough confirmations to ensure that it won't be reorganized.
- otherwise:
- If the `open_channel` message has the `announce_channel` bit set AND a `shutdown` message has not been sent:
- 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.
- Otherwise:
- MUST NOT send the `announcement_signatures` message.
- upon reconnection (once the above timing requirements have been met):
- MUST respond to the first `announcement_signatures` message with its own
`announcement_signatures` message.
- if it has NOT received an `announcement_signatures` message:
- SHOULD retransmit 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.
A recipient node:
- if the `short_channel_id` is NOT correct:
- 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 `node_signature` OR the `bitcoin_signature` is NOT correct:
- 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.
- if it has sent AND received a valid `announcement_signatures` message:
- SHOULD queue the `channel_announcement` message for its peers.
- if it has not sent `channel_ready`:
- MAY defer handling the `announcement_signatures` until after it has sent `channel_ready`.
- otherwise:
- MUST ignore it.
- 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`.
### Rationale
The reason for allowing deferring of a premature announcement_signatures is
that an earlier version of the spec did not require waiting for receipt of
funding locked: deferring rather than ignoring it allows compatibility with
this behavior.
Channels must not be announced before the funding transaction has enough
confirmations, because a blockchain reorganization would otherwise invalidate
the `short_channel_id`.
@ -189,6 +183,8 @@ The origin node:
- MUST set `features` based on what features were negotiated for this channel, according to [BOLT #9](09-features.md#assigned-features-flags)
- MUST set `len` to the minimum length required to hold the `features` bits
it sets.
- If the funding transaction has less than 6 confirmations:
- MUST NOT send `channel_announcement`.
The receiving node:
- MUST verify the integrity AND authenticity of the message by verifying the
@ -202,6 +198,11 @@ The receiving node:
- MUST ignore the message.
- if the specified `chain_hash` is unknown to the receiver:
- MUST ignore the message.
- if the `short_channel_id`'s output does NOT have at least 6 confirmations:
- MAY accept the message if the output is close to 6 confirmations, in case
the receiving node hasn't received the latest block(s) yet.
- otherwise:
- SHOULD ignore the message.
- otherwise:
- if `bitcoin_signature_1`, `bitcoin_signature_2`, `node_signature_1` OR
`node_signature_2` are invalid OR NOT correct: