Peering Between Pools

A solo pool’s block latency is decided by how early its node hears a new block. The cheapest way to hear it early is to peer directly with nodes that already sit on a fast relay path — other pools first of all. It is trustless (your node validates every block regardless of who sent it) and it costs one line in bitcoin.conf.

This page lists nodes that accept peering from pools and explains how to tell whether it helped. Operators who want their node listed: open an issue or say so on the OSMU Discord #mining-pools channel.

Nodes

Add a peer with

# bitcoin.conf
addnode=91.98.76.244

or at runtime, without a restart:

bitcoin-cli addnode 91.98.76.244 add

addnode peers are retried forever and are not counted against the outbound slot budget. Up to 8 are honoured; the connection is a normal Bitcoin P2P connection, nothing else changes.

Measuring whether it helped

Turn on Bitcoin Core’s compact-block log and microsecond timestamps (debug=cmpctblock, logtimemicros=1), then compare the Initialized PartiallyDownloadedBlock timestamp per block with a reference — the fastest pool’s first job on a stratum connection is a good one, since that is what StratumStats measures. Before peering, the reference node heard blocks 12 ms after a relay-connected pool’s job went out; with one relay-connected peer it hears them 17 ms before. Details and the rest of the chain are on the Node Tuning page.

Etiquette

• Peer with nodes, not with hashrate: this is a P2P connection, not a stratum one. Nobody’s shares go anywhere.
• Keep listen=1 and the port open so the favour can be returned; a node with inbound peers is a node others can learn from.
• If a listed node is unreachable for days, say so — the list is only useful while it is true.