How to detect double spends with a BU node?

[Hyena]

I must admit, I don't know what a BU full node does when it receives a conflicting TX. I would assume that BU allows conflicting unconfirmed TXs to exist together in the mempool. It is up to the developer to handle these situations. Unfortunately, the double spends never appear in my mempool. I can see them in blockchain.info as double spends but I haven't seen any double spend in my own mempool. I'm periodically polling it and checking the inputs of all fresh mempool entrants.

 

[Hyena]

I learned that Core deliberately rejects double spends. This is wrong. Unfortunately BU has inherited this fallacy. As a result I feel like leaving the BU community. I will replace my economic nodes that currently run BU with Bitcoin XT because XT makes it easier to monitor double spends. Let me know when BU has started to accept double spends in its mempool because then I might be coming back. I am employed in the online gambling sector and in that business it is crucial to detect double spends as early on as possible.

 

[AdrianX]

Thanks. I used XT before switching to BU there are lots of behaviors inherited from Core that were not in the XT 0.11 fork.

Why don't you propose a BUIP to change it I'd be interested to know why and how best to handle double spends this is relevant as BU has not adopted RBF.

 

[Hyena]

Thanks for the reply, it certainly is nice to have some communication going on here and it's good to see BU gaining more and more miner support every day. I'm not much of a BUIP proposal maker I'm a lazy economic user and I expect things to just work sorry. But a BU command line flag like --allow-conflicts would be nice to have feature if it would simply make BU node relay double spends. Internally it shouldn't be much work I'd assume.

It's sort of a business secret right now at my employer but here's a hint: allowing double spends to be relayed is a key to (relatively) safely accepting 0-confirmation transactions (it perfectly aligns with the idea of total fee market). Economically, miners don't give a shit about scammers and why should they? All they should ever care of is to include the set of TXs in the block that pays the highest possible fee. If everyone took this into consideration and if relaying of double spend TXs was supported by all nodes then stuff like fraud proofs would be totally unnecessary.

 

[AdrianX]

thanks, am I correct in understanding that accepting 0 confirmation transactions would be more secure if nodes relayed valid double spends and rational miners picking the transaction with the highest fee, creating a free market incentive to identify the preferred transactions?

 

[Hyena]

@AdrianX exactly. this allows everyone to predict which set of unconfirmed TXs is most likely to be confirmed in the next block. Miners will get the highest possible fee and everyone else will be immediately able to react to any changes in that set of TXs (double spends with greater fee than the original, for example). For online games that accept 0-confirmation deposits it is crucial to kick/ban a double-spender ASAP even before the double spend itself gets confirmed.

 

[AdrianX]

https://bitcoinxt.software/patches.html

Double spend relaying. This set of patches makes the P2P network relay double spends when they are seen, so sellers can learn about attempts to defraud them faster and with a lower cost to the peer to peer network. The alternative approach, used today, requires finding and connecting to as many nodes as possible which is infeasible on mobile and wasteful even when it can be done. It also upgrades the Bitcoin-Qt wallet to show broadcast double spend attempts in red, adds a -respendnotify command line flag, and reports conflicts via the JSON-RPC API.

 

[torusJKL]

@Hyena
I have created BUIP085: Double spend relaying.
It would be great to get your input.

 

[Hyena]

@torusJKL
thanks for letting me know, I will give my input in the BUIP thread