diff options
Diffstat (limited to 'bip-0159.mediawiki')
-rw-r--r-- | bip-0159.mediawiki | 64 |
1 files changed, 64 insertions, 0 deletions
diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki new file mode 100644 index 0000000..0226692 --- /dev/null +++ b/bip-0159.mediawiki @@ -0,0 +1,64 @@ +<pre> + BIP: 159 + Layer: Peer Services + 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 + Status: Draft + Type: Standards Track + Created: 2017-05-11 + License: BSD-2-Clause +</pre> + +== Abstract == + +Define a service bit that allow 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 +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 connecting some of its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers + +== Specification == + +=== New service bit === + +This BIP proposes a new service bit + +{|class="wikitable" +|- +| 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). +|} + +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 === + +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 than the signaled <code>NODE_NETWORK_LIMITED</code> threshold (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. + +== Compatibility == + +This proposal is backward compatible. + +== Reference implementation == + +* https://github.com/bitcoin/bitcoin/pull/11740 (signaling) +* https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay) + +== Copyright == + +This BIP is licensed under the 2-clause BSD license. |