From 8b971ea4deb5c99bbf99914b84d687982000ba22 Mon Sep 17 00:00:00 2001 From: Jonas Schnelli Date: Sat, 23 Sep 2017 09:23:38 -0600 Subject: Remove second service bit from NODE_NETWORK_LIMITED/BIP159 --- bip-0159.mediawiki | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) (limited to 'bip-0159.mediawiki') 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 @@ 
   BIP: 159
   Layer: Peer Services
-  Title: NODE_NETWORK_LIMITED service bits
+  Title: NODE_NETWORK_LIMITED service bit
   Author: Jonas Schnelli 
   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 MUST 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 MUST be capable of serving at least the last 1152 blocks (~8 days)
+| NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer MUST 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 SHOULD be taken into account when connecting to a peer signaling NODE_NETWORK_LIMITED_* service bits.
+A safety buffer of additional 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_*).
+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 then the signaled NODE_NETWORK_LIMITED_* 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 SHOULD avoid leaking the prune depth and therefore not serve blocks deeper then the signaled NODE_NETWORK_LIMITED thresholds.
 
 === 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 if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
 
 == Compatibility == 
 
-- 
cgit v1.2.3