I&#x27;ve never seen a more FUD headline than that. Got to love the journalistic sensationalism at play here.<p>To clear this up: the technique in the article is literally what we use in unit tests to check that our TX-based event code won&#x27;t break under malleability. It&#x27;s something that Bitcoin developers have been writing code around forever (and warning about just as long.) So truly: if there&#x27;s anyone out there still writing code that assumes static TXIDs they really do deserve what&#x27;s coming to them.<p>As I see it: the attack reaches critical mayhem in a similar way to accepting zero-conf transactions in that what you have is a consensus problem. The specific fix for TX malleability is to watch transactions based on their meaning, not their TXID (in this case &quot;meaning&quot; is looking at the inputs, outputs, version, timelock, etc to produce equivalent transactions.) And of course: don&#x27;t accept zero-confirmation transactions.<p>Here&#x27;s some of my ultra-1337 Python code for producing the &quot;attack&quot; just for laughs:<p>def mutate_tx(tx_hex):<p><pre><code>    &quot;&quot;&quot;
    Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn&#x27;t be used beyond testing as it uses an ugly eval() hack.

    https:&#x2F;&#x2F;en.bitcoin.it&#x2F;wiki&#x2F;Transaction_Malleability
    &quot;&quot;&quot;
    tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
    script_sig = repr(tx.vin[0].scriptSig)[9:]
    script_sig = eval(&quot;CScript([OP_1, OP_DROP, &quot; + script_sig)
    tx.vin[0].scriptSig = script_sig
    return b2x(tx.serialize())
</code></pre>
As you can see, there&#x27;s nothing to it. Just a clueless attention whore claiming to an even more clueless journalist that he can break Bitcoin.