Drop archive files
Drop a peer-observer archive
.bin.zst or .bin, one file or a whole rotated set.
An archive that is still being written reads fine — everything up to the cut is shown.
All events over time
Drag to select a time range for the Events tab. Click a group to hide it.
Rate by type
Event breakdown
absent types may have been filtered at capture
Files
No peers. Peers come from eBPF message and connection events; an archive captured
with only mempool, RPC or log events has none.
Peer detail
Select a peer for its message mix and connection lifecycle.
Peer ids are assigned by Bitcoin Core and unique only within one node run, so an archive
spanning a restart can reuse them.
Traffic over this connection
One row per command, one column per pixel of this connection; mark height is how many
messages fell in that slice. Drag across it to scope the sequence diagram below to a
stretch of time, and click it to go back to the whole connection.
Message sequence
Message
Select a message in the diagram to decode it.
Messages by command
Connection lifecycle
Transaction relay
#time (UTC)eventpeeraddresssize
Event
Select an event to decode it in full.
How long connections lasted
One row per peer, one column per pixel of time. Each mark is the messages exchanged in
that slice — inbound above the line, outbound below — shaded by how many. Vertical ticks
are connection events.
Every transaction reaches this node more than once. The peers that announce it first are doing the work; the rest arrive to find it already held, and the bytes they spent getting there were spent again.
Which peers told you first
A peer that has been connected longer wins more races simply by being there, so
the rate beside the count is what makes two peers comparable. Wasted bytes are
transactions this node already had when they arrived.
How late the other announcements were
Mostly not the network. Bitcoin Core holds announcements back on a Poisson
timer averaging five seconds to inbound peers and two to outbound ones, so
this is largely its own scheduling seen from the other side.
How long this node went without the transaction
From the first announcement by anyone to holding the transaction, so it
includes Core's own request delay, not just the peer's response time.
What happened when either side asked the other for something: how many requests of each kind went out, how many were answered, and how long the answers took.
Requests and replies
select a row for its reply times