Inventory

Announce first, deliver on request. That pattern is why the network does not drown in duplicates: each entry costs 36 bytes, a four-byte type tag plus a 32-byte hash, and a single inv message may carry up to 50,000 of them. A peer that already holds the object never asks, and the bandwidth is never spent.

How it works

An inventory entry is a pair: a number saying what kind of thing this is, and the hash that identifies it.

The type codes are small integers. 1 is a transaction, 2 is a block, 3 is a filtered block from the old bloom filter scheme, 4 is a compact block, 5 is a transaction identified by its witness hash. Setting bit 0x40000000 on top of a type marks the witness-carrying variant, so a segwit-aware peer requests MSG_WITNESS_BLOCK where an older one would have asked for a plain block.

The exchange runs in three steps. A node sends inv listing what is new. The peer scans the list, ignores everything it recognises, and replies with getdata naming only what it lacks. The node sends those objects, one message each, or notfound where something has since been discarded. The arithmetic behind the 50,000 cap is worth noticing: 50,000 entries at 36 bytes is 1,800,000 bytes, comfortably inside the 4,000,000-byte ceiling on a single message, and Bitcoin Core carries a compile-time assertion that keeps those two constants consistent with each other.

Timing is a privacy control rather than an implementation detail. Bitcoin Core does not announce a transaction the instant it learns of it. Announcements are batched and released on a randomised timer averaging two seconds towards outbound peers and five towards inbound ones, so an observer connected to many nodes cannot use arrival order to work out where a payment started. Blocks skip the delay completely, because there is nothing to hide and seconds cost money.

Shouting every hash at every peer is expensive, and Erlay is the proposed cure: peers periodically reconcile short sketches of what each other holds instead of flooding identifiers in all directions.

Where you see it

Inventories are the noisiest thing on a node's network interface and the easiest to observe.

The getpeerinfo call breaks traffic down by message type, and inv is almost always among the largest counters. A well-connected node spends a real share of its bandwidth announcing hashes that nobody turned out to need. This is also why a payment appears on one block explorer seconds before another: they are separate observers hearing separate announcements from different parts of the network.

One habit worth unlearning: an inv is not a commitment. A node can announce a transaction and then evict it minutes later when its mempool fills, and it owes nobody a correction.

Inventory vs mempool

An inventory is a message; a mempool is a store, and only one of them outlives the moment. The inv tells a peer that a hash exists somewhere. The mempool is the set of unconfirmed transactions a node has actually validated, keeps in memory and is willing to forward or mine, sized at 300 MB by default with an eviction policy that drops the cheapest first. Watching your txid propagate through inv announcements tells you the network heard about your payment. It does not tell you that anybody still has it an hour later.