Glossary / Nodes & software
P2P message
Also known as Message.
- Definition
- P2P messages are the fixed vocabulary bitcoin nodes use to talk to each other: short commands like version, inv, getdata, tx, and block, sent over a plain TCP connection.
No central server exists to call, so a node's entire relationship with the network is this conversation. Bitcoin Core advertises protocol version 70016, opens its connections on port 8333, and the whole vocabulary fits on one page. Your withdrawal reaches a miner because one machine said tx to another, forwarded a few thousand times in a few seconds.
How it works
Every connection opens with a handshake and then settles into a small set of recurring exchanges.
The first thing either side sends is version, carrying the protocol number it speaks, its service flags, the current time, the address it believes the other end has, a random nonce used to detect accidentally dialling itself, a user agent string, and the height of the best chain it knows about. Each side answers verack. Until both have done so, nothing else is processed.
That protocol number is a feature ladder rather than decoration. Direct header announcement needs 70012, compact block negotiation needs 70014, announcing a compact block before full validation needs 70015, and relaying transactions by witness identifier needs 70016. A node reads its peer's number and quietly declines to offer capabilities that peer cannot use, which is how the network upgrades without a coordinated cutover.
Grouped by purpose, the vocabulary is short. Finding peers: getaddr, addr, and the addrv2 form from BIP155 that can carry Tor and I2P addresses. Announcing: inv and headers. Requesting: getheaders, getdata, getblocks, mempool. Delivering: tx, block, cmpctblock, blocktxn, notfound. Housekeeping: ping, pong, sendheaders, sendcmpct, wtxidrelay, and feefilter, the last of which tells a peer not to bother forwarding transactions below a stated fee rate.
Two silences are deliberate. Unrecognised commands are ignored rather than rejected, which is what lets a new message type roll out gradually across a network nobody can update at once. And there is no way for a peer to tell you why it dropped your transaction: the reject message from BIP61 was disabled by default in Bitcoin Core 0.18.0 and the option removed altogether in 0.20.0, because the replies were unreliable, trivial to forge, and routinely mistaken for authoritative.
Where you see it
P2P messages are what your own node spends all day doing, and they are easy to watch.
Start Bitcoin Core with -debug=net and the log names each message as it arrives. The getpeerinfo call reports, for every connection, bytes sent and received broken down by message type, which is the quickest way to discover that one peer is feeding you almost everything while the rest sit idle. Broadcasting a payment from a wallet pointed at your own node produces a recognisable little sequence: an inv going out, a getdata coming back, a tx going out in reply.
P2P message vs RPC
Bitcoin has two interfaces and they are not interchangeable. P2P is node to node: unauthenticated, unencrypted unless both ends negotiate the v2 transport, on port 8333, with a vocabulary no single participant can extend. RPC is program to node: authenticated, local by default, on port 8332, with a method list that changes every release. A payment you create passes through both, entering your node as an RPC call and leaving it as a P2P message, and only the second half is anybody else's business.