gossip_store: Direct Access To Lightning Gossip
The lightning_gossipd dameon stores the gossip messages, along with some internal data, in a file called the "gossip_store". Various plugins and daemons access this (in a read-only manner), and the format is documented here.
The File Header
The gossmap header consists of one byte. The top 3 bits are the major version: if these are not all zero, you need to re-read this (updated) document to see what changed. The lower 5 bits are the minor version, which won't worry you: currently they will be 11.
After the file header comes a number of records.
The Record Header
Each record consists of a header and a message. The header is big-endian, containing flags, the length (of the following body), the crc32c (of the following message, starting with the timestamp field in the header) and a timestamp extracted from certain messages (zero where not relevant, but ignore it in those cases).
The flags currently defined are:
Deleted fields should be ignored: on restart, they will be removed as the gossip_store is rewritten.
The push flag indicates gossip which is generated locally: this is important for gossip timestamp filtering, where peers request gossip and we always send our own gossip messages even if the timestamp wasn't within their request.
The ratelimit flag indicates that this gossip message came too fast: we record it, but don't relay it to peers.
Other flags should be ignored.
Each messages consists of a 16-bit big-endian "type" field (for efficiency, an implementation may read this along with the header), and optional data. Some messages are defined by the BOLT 7 gossip protocol, others are for internal use. Unknown message types should be skipped over.
BOLT 7 Messages
These are the messages which gossipd has validated, and ensured are in order.
channel_announcement(256): a complete, validated channel announcement. This will always come before any
channel_updatewhich refers to it, or
node_announcementwhich refers to a node.
channel_update(258): a complete, validated channel update. Note that you can see multiple of these (old ones will be deleted as they are replaced though).
node_announcement(257): a complete, validated node announcement. Note that you can also see multiple of these (old ones will be deleted as they are replaced).
Internal Gossip Daemon Messages
These messages contain additional data, which may be useful.
This always immediately follows
channel_announcement messages, and
contains the actual capacity of the channel.
This contains information about a private (could be made public
later!) channel, with announcement in the same format as a normal
channel_announcement with invalid signatures.
This contains a private
channel_update (i.e. for a channel described
This is added when a channel is deleted. You won't often see this if
you're reading the file once (as the channel record header will have
deleted first), but useful if you are polling the file
This is only ever added as the final entry in the gossip_store. It
means the file has been deleted (usually because lightningd has been
restarted), and you should re-open it. As an optimization, the
equivalent_offset in the new file reflects the point at which the
new gossip_store is equivalent to this one (with deleted records
removed). However, if lightningd has been restarted multiple times it
is possible that this offset is not valid, so it's really only useful
if you're actively monitoring the file.
This is placed in the gossip_store file when a funding transaction is
blockheight is set to 12 blocks beyond the block containing
the spend: at this point, gossipd will delete the channel.
Using the Gossip Store File
- Always check the major version number! We will increment it if the format changes in a way that breaks readers.
- Ignore unknown flags in the header.
- Ignore message types you don't know.
- You don't need to check the messages, as they have been validated.
- It is possible to see a partially-written record at the end. Ignore it.
If you are keeping the file open to watch for changes:
- The file is append-only, so you can simply try reading more records using inotify (or equivalent) or simply checking every few seconds.
- If you see a
gossip_store_endedmessage, reopen the file.
Happy hacking! Rusty.