BIP 0159: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
934 (talk | contribs)
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0159.mediawiki
 
934 (talk | contribs)
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/83a1afd985984862/bip-0159.mediawiki
 
Line 9: Line 9:
   Comments-Summary: No comments yet.
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
   Status: Draft
   Status: Final
   Type: Standards Track
   Type: Standards Track
   Created: 2017-05-11
   Created: 2017-05-11
Line 54: Line 54:
Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.


== Compatibility ==  
== Compatibility ==


This proposal is backward compatible.
This proposal is backward compatible.

Latest revision as of 19:18, 9 October 2024

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

Please do not modify this page. This is a mirror of the BIP from the source Git repository here.

  BIP: 159
  Layer: Peer Services
  Title: NODE_NETWORK_LIMITED service bit
  Author: Jonas Schnelli <dev@jonasschnelli.ch>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
  Status: Final
  Type: Standards Track
  Created: 2017-05-11
  License: BSD-2-Clause

Abstract

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

Motivation

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

  1. Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s)
  2. Peers no longer in initial block download should consider connecting some of its 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_LIMITED bit 10 (0x400) If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).

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 the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers SHOULD avoid leaking the prune depth and therefore not serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold (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 unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling NODE_NETWORK_LIMITED if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.

Compatibility

This proposal is backward compatible.

Reference implementation

Copyright

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