From d44f70e77a6b477eed8b1d1fa8d95fb6dc1aaa35 Mon Sep 17 00:00:00 2001
From: Murch <murch@murch.one>
Date: Tue, 25 Feb 2025 17:45:25 -0500
Subject: [PATCH] BIP159 Risks section: clarifications and fixups

---
 bip-0159.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki
index f915181a..1211a0fa 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 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 ==