[nullc]

Wow that's super-confused!

The original Bitcoin software supported transaction replacement. You could mark a transaction as non-final and then it could be replaced until it got confirmed (potentially gated by its locktime) or until a replacement was made that was marked final. As is necessary in a distributed system, the replacement and non-replacement was best-effort and an older version could be confirmed (or a version made later than a final version). Replacement was intended for use with payment channels, like incrementally updating an open account paying someone.

Unfortunately, the functionality had a flaw: It enabled a DOS attack. You could make a transaction then replace it 2^32 times and only pay one fee. So we disabled it. Without the explicit functionality you could still replace transactions by spamming nodes (and esp miners) with the new transaction and hoping they accepted it, but it wasn't very reliable but also no longer DOS-attackable.

Later, people pointed out that the DOS attack could be avoided if it was also required that each replacement increase the tx fee by at least the minimum transaction fee that would have been accepted. And the functionality was re-enabled: you could again mark transactions as non-final.

When BCH was created they ripped out the functionality and falsely claimed that this made 'instant payments with 0 confirmations for small values' possible. This makes literally zero sense: First, in BCH you can still replace unconfirmed transactions, it's just less reliable. Secondly, replacement is functionality intended to enable faster transactions! Thirdly, you can disable it in Bitcoin (or replace a non-final one with a final version) and get the same behaviour as BCH if that's what your use case requires.

Finally, its alleged that this was some dastardly move by Bitcoin devs to "break" "0-conf" transactions, fuled by people who can't understand that Bitcoin devs saying 0-conf transactions are not very secure doesn't mean that they don't like your ability to make them if you want to, and it ignores the fact that the basic replacement functionality was there in the very first version ( https://github.com/trottier/original-bitcoin/blob/92ee8d9a99... ) and had been disabled by the self-same people being attacked for adding it.

It's basically 5G CAUSES COVID level of inanity, and it breaks my heart to see people duped by telephone-game polished versions of it.

[haolez]

Thanks for the thoughtful response. According to it, 0-conf transactions are possible in BTC as well. Why isn't more people using this? It seems safe enough, since attacking such a transaction is probably more expensive than the gains from the scam.

[nullc]

It's only safe in the sense that most people aren't trying to rip you off.

A moderately technically sophisticated attacker will concurrently broadcast one txn version near miners, and another to as many other nodes as they can reach. Their success rate on double spends can easily be >90% and the marginal cost of the attack is approximately zero.

Other than the technical know-how to setup the transaction broadcasting and the risk that you might just pay for what you were buying, there is no cost to the scam.

Same story on Bitcoin and BCH (here is a tweet about making 2511 successful double spends on BCH: https://twitter.com/peterrizun/status/1051088866743017473?la...).

The situation is somewhat worse on BCH in the sense that they only have ~1.2% of Bitcoin's hashrate, so there are many single Bitcoin miners that can reorg bch, so even single confirmations aren't particularly safe.

There are, of course, plenty of cases where 0-conf could be accepted-- e.g. you could credit someone assets but not allow withdraw until they clear, or if goods will ship the next day you need only check that they've confirmed before shipment. Some places do this now.

[haolez]

Can't this attack be made impractical with some heuristic? For example, only accept 0-conf transactions if a given number of nodes have this transaction in their mempool. (I'm thinking of both BTC and BCH)

[nullc]

No, because only a single node really matters: the next node to mine a block-- which may not even be reachable to you. Even if the attack worked just 10% of the time, that's like a free 10% rebate credit card for the attacker.

(and more generally, only a couple nodes matter at all for this purpose-- the set of nodes that could mine the next block)

Plus bch hashrate is so low the attacker can mine the next block themselves with rented hashrate, because the mining pays next to break even, renting the hashrate isn't a significant loss in the expectation.