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

Merge pull request #1768 from jonatack/2025-02-bip159

Browse Source 
BIP159 updates
This commit is contained in:
Mark "Murch" Erhardt 2025-02-26 09:57:23 -05:00 committed by GitHub
commit cc81fde273
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bip-0159.mediawiki
View File

@ -13,15 +13,15 @@
== Abstract ==
Define a service bit that allow pruned peers to signal their limited services
Define a service bit that allows 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
Pruned peers can offer the same services as traditional peers, except that of serving all historical blocks.
Bitcoin right now only offers the <code>NODE_NETWORK</code> service bit to indicate 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
# Pruned peers can relay blocks, headers, transactions, and addresses, but they only guarantee serving a minimum number of historical blocks; thus, they should have a way to announce their service(s)
# Peers no longer in initial block download should consider connecting some of their outbound connections to pruned peers, to allow other peers to bootstrap from non-pruned peers
== Specification ==
@ -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 their 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 unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below the peer’s pruned depth. Light clients should therefore check the service bits and either (1) connect to peers signaling <code>NODE_NETWORK_LIMITED</code> that preferably do not also signal serving the full block chain, if they only require (filtered) blocks around the tip, or (2) connect to peers signaling serving the full block chain if they need data older than the latest 288 blocks. Light clients obtaining peer IPs through DNS seeds should use the DNS filtering option.
== Compatibility ==