From 0798f68aeeb34ee670bdfb14154166e1de682830 Mon Sep 17 00:00:00 2001
From: Hodlinator <172445034+hodlinator@users.noreply.github.com>
Date: Mon, 10 Nov 2025 22:35:23 +0100
Subject: [PATCH] BIP53: Fix inversion

The current state of things requires more implementation complexity.
---
 bip-0053.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0053.mediawiki b/bip-0053.mediawiki
index 60d3996c94..5762f5a25a 100644
--- a/bip-0053.mediawiki
+++ b/bip-0053.mediawiki
@@ -84,7 +84,7 @@ are less constrained than the first 32 bytes) are constructed so that they colli
 with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
 was included in a Bitcoin block rather than T with 81 bits<ref>[[bip-0053/2-BitcoinMerkle.pdf|An attacker who can do 81 bits of work (followed by another 40 bits of work, to
 construct the funding transaction whose coins will be spent by this one) is able
-to fool an SPV client in this way.]]</ref> of work. This also reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a transaction is secure.]</ref>.
+to fool an SPV client in this way.]]</ref> of work. This also increases implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a transaction is secure.]</ref>.
 
 ==Rationale==