<p>You should look at <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md" rel="nofollow noreferrer">BOLT 07 which describes the gossip protocol</a> and depends on <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md" rel="nofollow noreferrer">BOLT 08</a> (Transport via the Noise Protocol framework) and <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md" rel="nofollow noreferrer">BOLT 01</a> (Messaging)</p>

<p>In particular if you look at the <code>channel_update message</code> you will find this quote from the BOLT 07: </p>

<blockquote>
  <p>if timestamp is NOT greater than that of the last-received channel_update for this <code>short_channel_id</code> AND for <code>node_id</code>:
  SHOULD ignore the message.</p>
  
  <p>otherwise:
  if the timestamp is equal to the last-received <code>channel_update</code> AND the fields (other than signature) differ:
  MAY blacklist this node_id.
  MAY forget all channels associated with it.</p>
  
  <p>if the timestamp is unreasonably far in the future:
  MAY discard the channel_updat</p>
</blockquote>

<p>Also in the section about rebroadcasting you can find the following quotes: </p>

<blockquote>
  <p>upon receiving a new <code>channel_announcement</code> or a <code>channel_update</code> or <code>node_announcement</code> with an updated timestamp:
  SHOULD update its local view of the network's topology accordingly.</p>
  
  <p>after applying the changes from the announcement:</p>
  
  <p>[...]</p>
  
  <p>SHOULD update the appropriate metadata AND store the signature associated with the announcement.
  Note: this will later allow the node to rebuild the announcement for its peers.</p>
</blockquote>

<p>The way how I read this is that nodes only store the latest <code>channel_update message</code> per channel which they can detect via the timestamp. Also when the initial sync takes place the latest update messages for each channel are also being sent.</p>

CC BY-SA 4.0
2019-06-12T11:27:15.757Z
This looks like a pattern: I ask a question, you cite a BOLT and explain it to me :) With all due respect, BOLT's language is not easy to grasp... So, after A joins and connects to B, B sends to A all _latest_ updates for all channels B thinks are live? Does A even have to ask for this a-la GETADDR - ADDR in Bitcoin?
Sergei Tikhomirov
CC BY-SA 4.0
2019-06-12T11:17:11.673Z
2019-06-12T11:17:11.673Z
Rene Pickhardt
<p>If I understand correctly, after a new node connects to a peer in the Lightning network, it receives all past channel announcement / update messages for currently open channels to recreate a local snapshot of the network. What messages are replayed? For example, for a very old channel with lots of channel updates, are all of them replayed? Why not just report the latest update message?</p>

<lightning-network>
Lightning network: which update messages are replayed?
Sergei Tikhomirov
# Lightning network: which update messages are replayed?

(Asked by: username_0 on 2019-06-12)

If I understand correctly, after a new node connects to a peer in the Lightning network, it receives all past channel announcement / update messages for currently open channels to recreate a local snapshot of the network. What messages are replayed? For example, for a very old channel with lots of channel updates, are all of them replayed? Why not just report the latest update message?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2019-06-12. Score: 2

You should look at [BOLT 07 which describes the gossip protocol](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md) and depends on [BOLT 08](https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md) (Transport via the Noise Protocol framework) and [BOLT 01](https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md) (Messaging)

In particular if you look at the `channel_update message` you will find this quote from the BOLT 07:

> if timestamp is NOT greater than that of the last-received channel\_update for this `short_channel_id` AND for `node_id`:
> SHOULD ignore the message.
>
> otherwise:
> if the timestamp is equal to the last-received `channel_update` AND the fields (other than signature) differ:
> MAY blacklist this node\_id.
> MAY forget all channels associated with it.
>
> if the timestamp is unreasonably far in the future:
> MAY discard the channel\_updat

Also in the section about rebroadcasting you can find the following quotes:

> upon receiving a new `channel_announcement` or a `channel_update` or `node_announcement` with an updated timestamp:
> SHOULD update its local view of the network's topology accordingly.
>
> after applying the changes from the announcement:
>
> [...]
>
> SHOULD update the appropriate metadata AND store the signature associated with the announcement.
> Note: this will later allow the node to rebuild the announcement for its peers.

The way how I read this is that nodes only store the latest `channel_update message` per channel which they can detect via the timestamp. Also when the initial sync takes place the latest update messages for each channel are also being sent.

> **Comments:**
> **username_0**: This looks like a pattern: I ask a question, you cite a BOLT and explain it to me :) With all due respect, BOLT's language is not easy to grasp... So, after A joins and connects to B, B sends to A all _latest_ updates for all channels B thinks are live? Does A even have to ask for this a-la GETADDR - ADDR in Bitcoin?  

---

