From c77a6c5996d11db5f55f2916e5348db11b429ef4 Mon Sep 17 00:00:00 2001
From: Oghenovo Usiwoma <37949128+Eunovo@users.noreply.github.com>
Date: Tue, 7 Apr 2026 22:51:12 +0200
Subject: [PATCH] BIP-352: warn against stopping scan due to wallet policy
 filtering (#2134)

Adds a warning to the "if no matches are found, stop" scanning
step. Without it, wallet developers may be tempted to apply policy
filtering (e.g. dust) before deciding to continue,
causing subsequent outputs for the same sender to be missed.
---
 bip-0352.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0352.mediawiki b/bip-0352.mediawiki
index 21bca34f..90ddd28a 100644
--- a/bip-0352.mediawiki
+++ b/bip-0352.mediawiki
@@ -357,7 +357,7 @@ If each of the checks in ''[[#scanning-silent-payment-eligible-transactions|Scan
 ****** Add ''P<sub>k</sub> + label'' to the wallet
 ****** Remove ''output'' from ''outputs_to_check'' and rescan ''outputs_to_check'' with ''k++''
 ***** If a label is not found, negate ''output'' and check a second time<ref name="negate_output">''' Why negate the output?''' Unfortunately taproot outputs are X-only, meaning we don't know what the correct Y coordinate is. This causes this specific calculation to fail 50% of the time, so we need to repeat it with the other Y coordinate by negating the output.</ref>
-*** If no matches are found, stop
+*** If no matches are found, stop<ref name="always_continue_scanning_after_match">'''WARNING:''' The decision to continue scanning (increment ''k'') must be based on whether a cryptographic match was found, not on whether the wallet considers the output spendable or relevant. A match that is later filtered by wallet policy (e.g. dust) must still trigger a rescan with ''k++''; stopping early may cause subsequent outputs for the same sender to be missed.</ref>
 
 ==== Spending ====