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

Remove explicit 6-blocks delay for announcements (#1215)

Browse source 
We previously required waiting for 6 confirmations before sending
`announcement_signatures`, but the real criteria is that it should only
be sent once you are confident that a reorg will not invalidate it.
This commit is contained in:
Bastien Teinturier 2025-01-14 10:22:19 +01:00 • committed by GitHub
parent c41536829c
commit 8707471dbc
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 7 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
07-routing-gossip.md
View file

@ -84,8 +84,8 @@ The `announcement_signatures` message is created by constructing a `channel_anno
A node: A node:
- if the `open_channel` message has the `announce_channel` bit set AND a `shutdown` message has not been sent: - 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 send the `announcement_signatures` message.
- MUST NOT send `announcement_signatures` messages until `channel_ready` - MUST NOT send `announcement_signatures` until `channel_ready` has been sent and received.
has been sent and received AND the funding transaction has at least six confirmations. - MUST NOT send `announcement_signatures` until the funding transaction has enough confirmations to ensure that it won't be reorganized.
- otherwise: - otherwise:
- MUST NOT send the `announcement_signatures` message. - MUST NOT send the `announcement_signatures` message.
- upon reconnection (once the above timing requirements have been met): - upon reconnection (once the above timing requirements have been met):
@ -104,11 +104,10 @@ A recipient node:
- if it has sent AND received a valid `announcement_signatures` message: - if it has sent AND received a valid `announcement_signatures` message:
- SHOULD queue the `channel_announcement` message for its peers. - SHOULD queue the `channel_announcement` message for its peers.
- if it has not sent `channel_ready`: - if it has not sent `channel_ready`:
- MAY defer handling the announcement_signatures until after it has sent `channel_ready` - MAY defer handling the `announcement_signatures` until after it has sent `channel_ready`.
- otherwise: - otherwise:
- MUST ignore it. - MUST ignore it.
### Rationale ### Rationale
The reason for allowing deferring of a premature announcement_signatures is The reason for allowing deferring of a premature announcement_signatures is
@ -116,6 +115,10 @@ that an earlier version of the spec did not require waiting for receipt of
funding locked: deferring rather than ignoring it allows compatibility with funding locked: deferring rather than ignoring it allows compatibility with
this behavior. 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`.
## The `channel_announcement` Message ## The `channel_announcement` Message
This gossip message contains ownership information regarding a channel. It ties This gossip message contains ownership information regarding a channel. It ties