highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 13:22:51 +01:00
Code Issues Packages Projects Releases Wiki Activity

BIP159: clarify pruned means not signaling serving complete block chain

Browse Source 
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
This commit is contained in:
Jon Atack 2025-02-14 14:26:22 -06:00
parent 3f86dc4ea6
commit 8118a14dc8
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
bip-0159.mediawiki
View File

@ -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 ==