highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-19 14:22:01 +01:00
Code Issues Packages Projects Releases Wiki Activity

BIP159: unwillingly -> unwittingly

Browse Source 
Not the same meaning, so not a purely editorial fixup, but I think "unwittingly"
expresses the intended meaning.
This commit is contained in:
Jon Atack 2025-02-17 11:10:58 -06:00
parent 5b85dbe120
commit 22f7f0477c
1 changed files with 1 additions and 1 deletions

2
bip-0159.mediawiki

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