mirror of
https://github.com/bitcoin/bips.git
synced 2025-03-17 13:22:51 +01:00
BIP159 Risks section: clarifications and fixups
This commit is contained in:
parent
22f7f0477c
commit
d44f70e77a
@ -52,7 +52,7 @@ Pruned nodes should therefore avoid leaking the prune depth and <I>SHOULD NOT</I
|
|||||||
|
|
||||||
Pruned peers following this BIP may consume more outbound bandwidth.
|
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 unwittingly 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> and not also signaling serving the full block chain, 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 ==
|
== Compatibility ==
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user