# Quick peer gossip catchup protocol

**URL:** <https://delvingbitcoin.org/t/quick-peer-gossip-catchup-protocol/251>\
**Category:** Protocol Design\
**Tags:** lightning\
**Created:** [December 5, 2023, 3:22am UTC](https://delvingbitcoin.org/t/quick-peer-gossip-catchup-protocol/251 "2023-12-05T03:22:20Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![rustyrussell](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/rustyrussell/32/154_2.png) [@rustyrussell](https://delvingbitcoin.org/u/rustyrussell)\
**Post date:** [December 6, 2023, 8:01pm UTC](https://delvingbitcoin.org/t/quick-peer-gossip-catchup-protocol/251/5 "2023-12-06T20:01:08Z")

</div>

This is, in fact, what gossip\_timestamp\_filter does:

```auto
1. type: 265 (`gossip_timestamp_filter`) (`gossip_queries`)
2. data:
    * [`chain_hash`:`chain_hash`]
    * [`u32`:`first_timestamp`]
    * [`u32`:`timestamp_range`]

```

The “timestamp” for channel\_announcement is defined as " the `timestamp` of a corresponding `channel_update`." (rather than “all corresponding channel\_update” which is what you specified).

It turns out, however, that everyone uses “none”, “all” or “recent”, where recent is 10 minutes ago (CLN), now (LND and Eclair), 1 hour ago (LDK). To avoid scanning the entire gossip\_store (or keeping more metadata), we now keep a single “first record with timestamp \> 2 hours ago” offset and scan from there, unless they set first\_update to 0. This basically turns the field into a trinary.

But this is _still_ not what a single-peer-gossiper wants! The timestamp of the record is a very rough guide to “have you seen this before”. A better guide is when the _peer_ received the gossip: presumably it started streaming it within 60 seconds. It’s also much easier for us to implement: for speed we can keep the received timestamps at every ~1MB of gossip store, since they will be monotonic.

---

_[View the full topic](https://delvingbitcoin.org/t/quick-peer-gossip-catchup-protocol/251)._