From 3f86dc4ea6c475469b4f4a6cbf5409238110377c Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Fri, 14 Feb 2025 14:22:46 -0600 Subject: [PATCH 1/5] BIP159: emphasize minimum number of blocks --- bip-0159.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index a659e726..92f5e08b 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -20,7 +20,7 @@ Define a service bit that allow pruned peers to signal their limited services 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. -# 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) +# 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) # 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 == From 8118a14dc813d895ff317604342808391219ce5b Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Fri, 14 Feb 2025 14:26:22 -0600 Subject: [PATCH 2/5] 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 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 === @@ -42,13 +44,15 @@ Full nodes following this BIP SHOULD relay address/services (addrSHOULD avoid leaking the prune depth and therefore not serve blocks deeper than the signaled NODE_NETWORK_LIMITED 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 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 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. +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 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 == From 5b85dbe120c2e770bde950aff638ca6084094752 Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Fri, 14 Feb 2025 14:39:44 -0600 Subject: [PATCH 3/5] BIP159: editorial fixups --- bip-0159.mediawiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index 6943db72..2ac5e9e4 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -13,15 +13,15 @@ == Abstract == -Define a service bit that allow pruned peers to signal their limited services +Define a service bit that allows 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 +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. # 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) -# 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 +# 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 == @@ -44,7 +44,7 @@ Full nodes following this BIP SHOULD relay address/services (addrSHOULD NOT serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold of 288 blocks. From 22f7f0477c825031a8be80589464766cb2eb2559 Mon Sep 17 00:00:00 2001 From: Jon Atack Date: Mon, 17 Feb 2025 11:10:58 -0600 Subject: [PATCH 4/5] BIP159: unwillingly -> unwittingly Not the same meaning, so not a purely editorial fixup, but I think "unwittingly" expresses the intended meaning. --- bip-0159.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index 2ac5e9e4..f915181a 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -52,7 +52,7 @@ Pruned nodes should therefore avoid leaking the prune depth and SHOULD NOTnServiceFlags (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 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. +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 their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling NODE_NETWORK_LIMITED 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 == From d44f70e77a6b477eed8b1d1fa8d95fb6dc1aaa35 Mon Sep 17 00:00:00 2001 From: Murch Date: Tue, 25 Feb 2025 17:45:25 -0500 Subject: [PATCH 5/5] BIP159 Risks section: clarifications and fixups --- bip-0159.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index f915181a..1211a0fa 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -52,7 +52,7 @@ Pruned nodes should therefore avoid leaking the prune depth and SHOULD NOTnServiceFlags (service bits) from a relayed addr-message may unwittingly 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 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. +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 ==