BIP-133 0-Conf Double Spends on BCH 2018-04-03
My last post was about a method for double-spending 0-conf transactions. I wanted to follow up and share some additional information that I've found.
To start off let me say this: wallets which use fee filters (BIP-133) are vulnerable to 0-conf double spends at no cost to the attacker. If that sounds a bit crazy, it is.
BIP-133 was added in March 2016 when blocks were becoming full and was meant to protect nodes from having their mempool max out (see mailing list discussion and Github PR). With full blocks there isn't an issue because fees are rarely below the fee filter level anyway. Also, since BTC is not intended to be used as cash, maintaining security of 0-conf is not a priority.
Remove BIP-133
In short, BIP-133 should be removed from Bitcoin Cash. It was added late in BTC's history and does not fit in the BCH philosophy. Fee filters lower the security of 0-conf transactions and wallets that are using it can be vulnerable to double spends.
The way it works is that a low-fee transaction is sent first and only propagated by nodes with low fee filters. Then a regular transaction is sent later and picked up by the rest of the nodes. If the receiver is using a fee filter they will only see the second transaction, meanwhile there's a good chance the first transaction will be mined.
For more info about these double spends, see the example below, or check out the previous post.
Example
Here's one of the double spends on doublespend.cash. The original transaction is what showed up in Electron Cash and was there for almost 2 minutes before being replaced (on average it would take about 5-10 minutes for the victim to realize a double spend had occurred).
As you can see, the confirmed transaction has a very low fee. It says the confirmed transaction was seen 97s after the original one. This is because the confirmed transaction was not seen until it was mined, which you can tell because the "first seen" timestamp matches the timestamp of the block.
The transaction was actually broadcast at 19:51, almost an hour earlier. There were two blocks mined during that time which did not include it. Had the lost normal transaction been broadcast earlier, it likely would've been included in one of those blocks (since those blocks were ignoring low-fee transactions). This is where the inconsistency is, and why the double spend works, but only some times.
For more info about this, see the previous post.