From 22f7f0477c825031a8be80589464766cb2eb2559 Mon Sep 17 00:00:00 2001
From: Jon Atack <jon@atack.com>
Date: Mon, 17 Feb 2025 11:10:58 -0600
Subject: [PATCH] BIP159: unwillingly -> unwittingly

Not the same meaning, so not a purely editorial fixup, but I think "unwittingly"
expresses the intended meaning.
---
 bip-0159.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki
index 2ac5e9e4..f915181a 100644
--- a/bip-0159.mediawiki
+++ b/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 ==