diff options
-rw-r--r-- | README.mediawiki | 2 | ||||
-rw-r--r-- | bip-0159.mediawiki | 22 |
2 files changed, 11 insertions, 13 deletions
diff --git a/README.mediawiki b/README.mediawiki index bbdb1ba..1c1713e 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -710,7 +710,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0159.mediawiki|159]] | Peer Services -| NODE_NETWORK_LIMITED service bits +| NODE_NETWORK_LIMITED service bit | Jonas Schnelli | Standard | Draft diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index 2253922..79fd0fc 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -1,7 +1,7 @@ <pre> BIP: 159 Layer: Peer Services - Title: NODE_NETWORK_LIMITED service bits + 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 @@ -13,7 +13,7 @@ == Abstract == -Define service bits that allow pruned peers to signal their limited services +Define a service bit that allow pruned peers to signal their limited services ==Motivation== @@ -21,36 +21,34 @@ Pruned peers can offer the same services as traditional peer except of serving a 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) -# Peers no longer in initial block download should consider connection 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 its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers == Specification == -=== New service bits === +=== New service bit === -This BIP proposes two new service bits +This BIP proposes a new service bit {|class="wikitable" |- -| NODE_NETWORK_LIMITED_LOW || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 day / the current minimum limit for Bitcoin Core). -|- -| NODE_NETWORK_LIMITED_HIGH || bit 11 (0x800) || If signaled, the peer <I>MUST</i> be capable of serving at least the last 1152 blocks (~8 days) +| NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 day / the current minimum limit for Bitcoin Core). |} -A safety buffer of additional 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling <code>NODE_NETWORK_LIMITED_*</code> service bits. +A safety buffer of additional 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 === -Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</code> message) from peers they would connect to (including peers signaling <code>NODE_NETWORK_LIMITED_*</code>). +Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</code> message) from peers they would connect to (including peers signaling <code>NODE_NETWORK_LIMITED</code>). === 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 then the signaled <code>NODE_NETWORK_LIMITED_*</code> thresholds. +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 then the signaled <code>NODE_NETWORK_LIMITED</code> thresholds. === 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> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. == Compatibility == |