lukechilds
/
bips
mirror of https://github.com/lukechilds/bips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

Merge pull request #592 from jonasschnelli/node_network_limited 

Remove second service bit from NODE_NETWORK_LIMITED/BIP159
master
Luke Dashjr 7 years ago
committed by GitHub
parent
e49aa21ef6 8b971ea4de
commit
7fccc601a0
2 changed files with 11 additions and 13 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 2
      README.mediawiki
  2. 22
      bip-0159.mediawiki

2
README.mediawiki
View File

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

22
bip-0159.mediawiki
View File

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

Write Preview
Loading…
Cancel
Save