The Bitcoin Network

Bitcoin SV uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin SV is fully able to use ports other than 8333 via the -port parameter. IPv6 is supported with all versions later than Bitcoind/Bitcoin-Qt v0.7.

Messages

• version - Information about program version and block count. Exchanged when first connecting.
• verack - 'Version Acknowledgement'. Sent in response to a version message to acknowledge that the peer is willing to connect.
• addr - List of one or more IP addresses and ports.
• inv - "I have these blocks/transactions: ..." Normally sent only when a new block or transaction is being relayed. This is only a list, not the actual data.
• getdata - Request a single block or transaction by hash.
• merkleblock - Request a filtered block using the inventory type MSG_MERKLEBLOCK. Normally used to communicate transaction data to an SPV client.
• getblocks - Request an inv of all blocks in a range.
• getheaders - Request a headers message containing all block headers in a range.
• tx - Send a transaction. This is sent only in response to a getdata request.
• block - Send a block. This is sent only in response to a getdata request.
• headers - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
• getaddr - Request an addr message containing a bunch of known-active peers (for bootstrapping).
• mempool - Requests TXIDs of transactions that the receiving node has validated but has not appeared in a block.
• submitorder, checkorder, and reply - Used when performing an IP transaction.
• alert - Send a network alert.
• ping - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.
• pong - the pong message replies to a ping message, proving to the pining node that the ponging node is still responsive.
• notfound - Reply to a 'getdata' message which requested an object not available for relay.
• reject - Informs the receiving node that one of it's previous messages has been rejected.
• sendheaders - Indicates that the node prefers to receive new block announcements via 'headers' as opposed to 'inv' messages.
• feefilter - Tells the receiving peer not to send any transactions that do not meet the specified fee rate.
• sendcmpct - Indicates that a node is wiling to receive new block announcements via 'cmpctblock' message rather than an 'inv'.
• cmpctblock - Contains a 'CBlockHeaderAndShortTxIDs' object providing a header and list of short txids.
• getblocktxn - Block transactions request used to request a list transaction by specifying their indexes and block hash.
• blocktxn - Block transaction message provides the transactions requested by a 'getblocktxn' message.
• protoconf - Sent after 'verack' message, regardless of the peer's protocol version.

More information and in-depth technical information is in the Protocol Specification.

Connection

To connect to a peer, you send a version message containing your version number, block count, and current time. The remote peer will send back a verack message and his own version message if he is accepting connections from your version. You will respond with your own verack if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange getaddr and addr messages, storing all addresses that you don't know about. addr messages often contain only one address, but sometimes contain up to 1000. This is most common at the beginning of an exchange.

Standard relaying

When someone sends a transaction, they send an inv message containing it to all of their peers. Their peers will request the full transaction with getdata. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an inv, and so on. Peers ask for or relay transactions only if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an inv containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an addr containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial addr.

Network alerts are broadcast with alert messages. No inv-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

Initial block download

At the start of a connection, you send a getblocks message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an inv that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with getdata, and the peer will send them to you with block messages. After you have downloaded and processed all of these blocks, you will send another getblocks, etc., until you have all of the blocks.

Thin SPV Clients

Simplified Payment Verification was introduced as part of the Bitcoin whitepaper. BIP 0037 introduced support for thin or lite clients by way of Simple Payment Verification. SPV clients do not need to download the full block contents to verify the existence of funds in the blockchain, but rely on the chain of block headers and bloom filters to obtain the data they need from other nodes. This method of client communication allows high security trustless communication with full nodes, but at the expensive of some privacy as the peers can deduce which addresses the SPV client is seeking information about.

The desktop wallet ElectrumSV works in this fashion using the Python library bitcoinX as their foundation. Moneybutton on the other hand uses Javascript Bitcoin SV library for client communication.

Bootstrapping

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has three methods of finding peers.

Addr

The addr messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin SV comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.

The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node.

DNS

Bitcoin SV looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later.

IRC

As-of version 0.6.x of the Bitcoin client IRC bootstrapping is no longer enabled by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. The information below is accurate for most versions prior.

Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

Heartbeat

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

See Also

• Peer-to-Peer Network Architecture
• Exchanging "Inventory"
• Encrypted and Authenticated Connections
• Transaction Pools
• Protocol Specification
• Historical Network Status (no longer updated)
• Bitnodes.io's network size estimate
• How to run your own cheap full bitcoin node
• Bitcoin Mining
• Video: What is Bitcoin Mining