BIP159 Risks section: clarifications and fixups

This commit is contained in:
Murch 2025-02-25 17:45:25 -05:00 committed by Jon Atack
parent 22f7f0477c
commit d44f70e77a

View File

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