From 8118a14dc813d895ff317604342808391219ce5b Mon Sep 17 00:00:00 2001
From: Jon Atack <jon@atack.com>
Date: Fri, 14 Feb 2025 14:26:22 -0600
Subject: [PATCH] BIP159: clarify pruned means not signaling serving complete
 block chain

e.g. that NODE_NETWORK is not set

See reference implementation

https://github.com/bitcoin/bitcoin/pull/10387

and this comment in that pull

https://github.com/bitcoin/bitcoin/pull/10387#discussion_r156861038
---
 bip-0159.mediawiki | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki
index 92f5e08b..6943db72 100644
--- a/bip-0159.mediawiki
+++ b/bip-0159.mediawiki
@@ -34,6 +34,8 @@ This BIP proposes a new service bit
 | NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 days).
 |}
 
+Pruned/limited peers <I>MUST NOT</I> set a service bit that signals serving the complete block chain (e.g., <code>NODE_NETWORK</code>). Rationale: nodes that signal serving the complete block chain may also signal <code>NODE_NETWORK_LIMITED</code>.
+
 A safety buffer of 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling the <code>NODE_NETWORK_LIMITED</code> service bit.
 
 === Address relay ===
@@ -42,13 +44,15 @@ Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</
 
 === 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 <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper than the signaled <code>NODE_NETWORK_LIMITED</code> threshold (288 blocks).
+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).
+
+Pruned nodes should therefore avoid leaking the prune depth and <I>SHOULD NOT</I> serve blocks deeper than the signaled <code>NODE_NETWORK_LIMITED</code> threshold of 288 blocks.
 
 === Risks ===
 
 Pruned peers following this BIP may consume more outbound bandwidth.
 
-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> and not also signaling serving the full block chain, if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
 
 == Compatibility ==