P2P Connections
  • Outbound Peer
    • Attempts to maintain maximum # of outbound connections.
    • Local acquires remote addresses through gossiping
  • Inbound Peer
    • Node accepts up to maximum set # inbound connections.
    • Inbound peers obtains local address through gossiping.
  • Manual Peer
    • Node can set permanent peers in settings.
    • Will always attempt to maintain connection to these.
  • All peer connection types follow the same Bitcoin messaging protocol once established.

Version Protocol
  • P2P Messaging is Asynchronous
    • Different to Client-Server calls.
    • Each peer may handle messages at any time.
    • Received message notifications invoke handlers.
  • Peers negotiate highest common channel version
  • VERSION
    • Peer sends its P2P messaging version.
    • And additional information (available services ...)
  • VERACK
    • Peer acknowledges version from peer.

Ping Protocol
  • Ping protocol determines whether underlying TCP connection still active.
  • Received/Sent: PING
    • Peer attempts ping transmission.
    • Successful socket transmission indicates live connection.
    • Otherwise node will close peer connection.
    • Heartbeat intervals are in node settings.
  • Received: PONG
    • Version 60001 and above.
    • Peer responds to PING with PONG.
    • Includes same nonce as in PING.
    • Indicates responsive service/Roundtrip latency.
  • Received: PONG
    • Resubscriptions to messages are renewed after each received message.

Address Protocol
  • Peer discovery through address protocol.
  • Received: GETADDR
    • Requests known addresses from peer.
    • One response to GETADDR only allowed per connection.
  • Received: ADDR
    • Can be sent proactively.
    • Seeding Peer: Sends own address.
    • Response to GETADDR: Up to 1000 addresses.
  • Sent: GETADDR
    • Requests host address from peer.

Channel Lifetime
  • Handshake Protocol.
    • Negotiate channel version.
  • Subsequently: Ping/Pong/Address
    • Channel heartbeat.
    • Exchange of known peers.
    • Maintain channel is closed.
  • Other messaging protocols provide:
    • (Initial) blockchain sync.
    • Propagation of mempool transactions.
    • Exchange of chain-extending blocks.
    • Other protocol types for different sessions.
Peer Lifetime
  • Seed Sessions.
    • Contact seed peers to seed peer addresses.
    • Node Settings:
      • Seeding peer addresses.
      • Min # addresses to be acquired.
    • All seed channels disconnect after seeding.
  • Manual/Outbound/Inbound Session
    • Contact seed peers to seed peer addresses.
    • Node Settings:
      • Max In/Outbound channels.
      • Manual channel peers.
    • Same protocols attached to each channel.
  • Channel Protocols.
    • Seed/Address: Exchange known peer addresses.
    • Transaction in/out:
      • Propagate new mempool TX’s
    • Block in/out:
      • Propagate new blocks
      • Exchange of chain-extending blocks.
Transaction-In Protocol
  • Received: TRANSACTION(TX)
    • Can be received anytime.
    • OOrganised into mempool.
  • Received: INV(TX)
    • Inventory message includes up to 50’000 TXIDs.
    • GETDATA(INV) to request transaction data.
  • Sent: FEEFILTER
    • minimum feerate sat/kb for tx relay
  • Sent: MEMPOOL
    • Request mempool, peer responds with single/multiple INVs.

Transaction-Out Protocol
  • Received: FEEFILTER
    • Can be adjusted anytime.
  • Received: MEMPOOL
    • Inventory message includes up to 50’000 TXIDs.
  • Received: GETDATA
    • Payload identical to INV message
    • Respond with serialised transaction
  • Node mempool event:
    • For new transaction organised into mempool, announce to peer.

Block-In Protocol
  • Received: HEADERS
    • Headers are organised into header chain.
    • Blocks from strong header chain requested with get_data
  • Received: INV
    • Request headers if unknown.
  • Received: BLOCKS
    • Response to get_data(INV(Blocks))
  • Sent: SEND_HEADERS
    • Sendheaders >=70012 (BIP130).
    • Ask peer to announce headers rather than INV
  • Sent: GET_HEADERS
    • Includes hashes, height.
    • Header hashes begin with 10 highest known.
    • Hash heights increase exponentially until genesis hash.
    • Hash Stop: request headers up to this header.
      • 0x00..00 no limit
      • Hash of received orphan.
Block-Out Protocol
  • Received: GET_HEADERS
    • Lookup included header hashes.
    • Send beginning with highest common strong chain hash.
  • Received: GET_BLOCKS
    • Lookup included header hashes.
    • Send INV beginning with highest common strong chain hash.
  • Received: GET_DATA
    • Send type of block requested:
      • witness_block/block
      • compact_block
      • filtered_block
  • Sent: SEND_COMPACT
    • Send compact blocks (BIP152)
    • Compact block: Header+Short IDs.
    • Only unknown TXs data is requested.
  • Broadcast of new blocks
    • INV/Header/Compactblocks depending on peer.