I used XT nodes for half a year but one-by-one they all started to suffer from mysterious issues such as being unable to connect with any other nodes and even disallowing me to spend any of my own funds due to strange wallet conflitcts. For that reason I strongly suggest you to be very cautious when implementing double-spend relaying in BU nodes. I personally was not perfectly happy with the particular implementation XT had for double-spend relaying because 90% of the times it failed to notify me about real double-spends. I guess the hacker directly pushed to the mining pool which in turn did not relay double-spends, so the rest of the network only learned about it when a block containing the DS was finally mined by that pool.



That said, since it is technically impossible to distinguish between a malicious double-spend and the original TX we have an option of:

1) allowing the Scorched Earth arm-wrestling between the merchant and the double-spender where both outbid each-other's TX fees until no one gets their money and all the funds end up in TX fees via CPFP TXs.

2) try to enforce the first-seen rule and other kludges to combat double-spending of 0-conf TXs



Since the first option is vastly more radical than the second option, I will elaborate here how the first-seen rule could be reinforced. Implement a pre-mempool that stores all new 0-conf TXs that your node learns about. However, when a TX is insterted into the pre-mempool queue it will have to wait there for 10 seconds before it is allowed to enter the actual mempool. During that 10-second time it is possible that a conflicting TX is received by the same node. When that happens the node could fire the `-respendnotify` event so that the merchant could act on it. Whenever conflicting TXs enter the pre-mempool all of their 10-second timers should be reset because all of them become competitors and there could be more than one double-spend coming. It makes the most sense to allow the competitor with the greatest TX fee into the actual mempool because miners are incentivized to do exactly this whether we like it or not.



The 10-second gap is necessary so that the receiving node could relay the new TX immediately to all of its neighbours while still waiting for any potential double-spends to arrive. I would guess that within 10 seconds a TX will reach all the nodes of the network. If the double-spend arrives later than 10 seconds then the first-seen rule is naturally applied even by old nodes who don't relay double-spends. If the double-spend arrives within 10 seconds the merchant has a theoretical chance to quickly spawn a CPFP TX from the initial payment, donating all of the funds to the miners and thus making it unprofitable for the adversary to even attempt double-spending.



By implementing pre-mempool we are keeping this new double-spend relaying functionality more separate from the old and working implementation and thus there is a smaller chance for introducing new bugs and vulnerabilities. New RPCs should be added for polling the pre-mempool and getting events similar to walletnotify exclusively about the pre-mempool. In other words, the improvment should be backwards-compatible with any software using the current RPCs. Software relying solely on old RPCs would experience 10 second lag before gaining information about new payments.



The pre-mempool is useful because it would also provide an opt-in solution for the TX malleability problem. Zero-fee TXs are held in the pre-mempool for 10 seconds to allow a CPFP TX arrive right after the zero-fee parent TX. The child TX pays for the parent and for itself. Without the child the parent cannot be confirmed because it has a fee of zero, thus the parent TX cannot be malleated. A small consensus rule is needed though so that zero-fee TXs would be illegal if they are not paid for within the same block. In other words, all blocks containing a zero fee TX without a CPFP TX should be rejected by all nodes. As a result, we will have double-spend notifications and opt-in fix for TX malleability implemented within the same patch.