BIP53: Fix inversion

The current state of things requires more implementation complexity.

Author: hodlinator

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==