Home › Browse › BIP 159

BIP 159: NODE_NETWORK_LIMITED service bit

In plain English: Defines a signal that pruned nodes, which keep only recent blocks to save disk space, can use to advertise that they can serve recent history. This lets pruned nodes contribute more to the network while making clear they cannot provide the full blockchain.

Status
Deployed
Type
Specification
Layer
Peer Services
Authors
Jonas Schnelli
Assigned
Last changed
Topics
Network
Source
bip-0159.mediawiki on GitHub · Markdown

Abstract

Define a service bit that allows pruned peers to signal their limited services.

Motivation

Pruned peers can offer the same services as traditional peers, except that of serving all historical blocks. Bitcoin right now only offers the NODE_NETWORK service bit to indicate that a peer can serve all historical blocks.

  1. Pruned peers can relay blocks, headers, transactions, and addresses, but they only guarantee serving a minimum number of historical blocks; thus, they should have a way to announce their service(s)
  1. Peers no longer in initial block download should consider connecting some of their outbound connections to pruned peers, to allow other peers to bootstrap from non-pruned peers

Specification

New service bit

This BIP proposes a new service bit

NODE_NETWORK_LIMITEDbit 10 (0x400)If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).

Pruned/limited peers MUST NOT set a service bit that signals serving the complete block chain (e.g., NODE_NETWORK). Rationale: nodes that signal serving the complete block chain may also signal NODE_NETWORK_LIMITED.

A safety buffer of 144 blocks to handle chain reorganizations SHOULD be taken into account when connecting to a peer signaling the NODE_NETWORK_LIMITED service bit.

Address relay

Full nodes following this BIP SHOULD relay address/services (addr message) from peers they would connect to (including peers signaling NODE_NETWORK_LIMITED).

Counter-measures for peer fingerprinting

Peers may have different prune depths (depending on their configuration, disk space, etc.), which can result in a fingerprinting weakness (finding the prune depth through getdata requests).

Pruned nodes should therefore avoid leaking the prune depth and SHOULD NOT serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold of 288 blocks.

Risks

Pruned peers following this BIP may consume more outbound bandwidth.

Light clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below the peer’s pruned depth. Light clients should therefore check the service bits and either (1) connect to peers signaling NODE_NETWORK_LIMITED that preferably do not also signal serving the full block chain, if they only require (filtered) blocks around the tip, or (2) connect to peers signaling serving the full block chain if they need data older than the latest 288 blocks. Light clients obtaining peer IPs through DNS seeds should use the DNS filtering option.

Compatibility

This proposal is backward compatible.

Reference implementation

This BIP is licensed under the 2-clause BSD license.

Related proposals

  • BIP 14: Protocol Version and User Agent: Deployed. Separates the version of the Bitcoin network protocol from the version of any one program, and adds a "user agent" label identifying the software a node runs. As alternative clients appeared, this…
  • BIP 31: Pong message: Deployed. Adds a "pong" reply that a node sends back when it receives a "ping" containing a random number. This lets software reliably tell whether a connection to another node is still alive.
  • BIP 33: Stratized Nodes: Closed. Proposed specialized node roles so lightweight clients could rely on full nodes that serve them only the data they need. It aimed to keep Bitcoin usable for ordinary users as the blockchain grew too…
  • BIP 35: mempool message: Deployed. Adds a "mempool" message that lets a node ask a peer for the unconfirmed transactions it is holding. This helps lightweight wallets and freshly started nodes learn quickly about payments still…
  • BIP 36: Custom Services: Closed. Proposed a way for nodes to announce custom or optional services during their initial handshake without using up the small set of standard service flags. It would have made it easier to add new…
  • BIP 37: Connection Bloom filtering: Deployed. Lets lightweight wallets hand a full node a Bloom filter (a compact, approximate summary of what they care about) so they receive only relevant transactions. This made phone wallets practical,…