Latest replace by fee News

Just recently, BitMex Research’s ForkMonitor detected a split in the BTC chain, where the temporarily leading chain was re-org’d, and therefore 1 block was orphaned. Nothing substantially important or notable with that alone… Reorgs happen all the time, and they are a fundamental part of the design in which Bitcoin works and awards miners for the most work done on the network. What made this particularly unique, which ended up sending “crypto-twitter” (as it is colloquially termed) into a meltdown was the fact that one of the transactions showed a conflict. It did not fit the usual RBF type transaction. What is RBF? Replace-By-Fee is a method of transacting on the BTC chain that Core devs implemented to help speed up transactions on their plodding network. Because of BTC’s limited transactional through-put, only a certain number of transactions can be processed at a time. This puts the speed limit at approximately 3 transactions per second… a terrible speed for a payment network. Miners (who process transactions) pick up the transactions from the queue not in a first in first out service, but in a highest fee come first method. It is for this reason, every BTC transaction has a sizeable fee attached to it… everyone is trying to get to the head of the queue. At times of extreme traffic, users have been forced to wait several days and over to see their transactions proceed, even with reasonable fees attached. This is where BTC Core developers introduced RBF, a policy that allows a sender of a transaction, to redo the transaction and attach a bigger fee to it. So suppose my transaction has been waiting 2 days, and I had paid a 2 dollar fee, I can then rebroadcast the same transaction and increase the fee. I am basically creating a new transaction with a higher fee, to lure miners into picking it up first. So when people tried to hush it down the transaction with calls of RBF, it’s very easy to point out a few things… Firstly the values were different, both transactions were recorded on different blocks, and importantly, the lower fee transaction, a surprisingly low 1 sat/byte actually won out in the end. Author of Mastering Bitcoin, Andreas Antonopoulos, responded in damage control. In a tweet storm he explains that reorgs are part and parcel of BTC operations and business as usual. He then explains the probabilities of reorgs, and how tremendously infrequent they become statistically beyond 1 or 2 block deep reorgs. All this is fine and all are in agreeance. https://twitter.com/aantonop/status/1352258125932371968?s20 Andreas explains that “During a re-organization, there is a chance for someone to attempt a ‘double spend.’ This is not a double spend from the perspective of the blockchain as a whole. Only one spend survives, therefore no double spends happen.” Yes, there is only 1 chain that survives, only 1 transaction that survives, but as he points out later, it can by all means be the wrong transaction that survives. And that’s the whole point! Whenever we talk about double spends, or a 51% attack it is always a re-write of the blockchain, and rarely in the context of a coin spent twice within the same chain. Not too long ago over US$5 million was double spent on the Ethereum Classic network. This too only ended up with 1 history of events and 1 transaction. The transaction that lost out was orphaned. Granted this was a major re-org that was exceptionally deep for ETC. He then mentions page 8 of the whitepaper, where calculations are shown on probabilities of double spends. Except, the very page he refers to is specifically speaking about the attack that occurred. There is substantial evidence to show that the double spend was a carefully crafted and timed transaction designed to do what it did. The person that created the transaction knew very well what they were doing. Interestingly, Andreas makes a point about waiting for confirmations on bigger values. This is good advice indeed for all POW blockchains. But to take his advice directly and apply it to what happened in the reorged issue at hand presents the point of the problem. This was a mere US$21 double spend. The kind of amount where most people would accept a single confirmation. Antonopoulos concludes “Consider it debunked.” I think the issue is rather now flagged, and BTC community should now make considerations on a suitable number of confirms even for smaller amounts, and not just bigger amounts. But beyond this, how do Lightning Network developers resolve this issue with settlements that this presents? Compounding matters however, are the implications that this could have for Lightning Network channels and settlements, as noted by nChain’s chief scientist Dr. Craig S Wright. Dr. Wright, the inventor Bitcoin, states that “if you double spend a Lightning Network settlement, you effectively break the entire system. Watch towers are all about putative spends, no inputs, no punishment… By definition what happened was a double spend.” https://twitter.com/sgbett_614/status/1352604133417750533?s20 The effort in which Andreas went in to try to quash fears was understandable. People have real money invested, and panic can do ugly things to a market. It highlights a duplicity however, where in the past, mere reorgs on BSV (that had no double spends at all) were smeared all over media outlets. Dare I say if this incident was on BSV, the world would’ve known about it. Antonopoulos also criticized the fact that publications quoted BSV people, instead of an “actual Bitcoin developer or expert”: That’s a cheap shot, so here is a BTC Core developer from way back saying what we said: On the other hand, BSV accepts 0-confirmation payments for such small amounts quite easily and securely. Firstly, miners work on a first seen rule (as opposed to highest paid fee rule). Secondly, ecosystem wallets such as HandCash have built-in double-spend detection systems. Ivan Mlinarić, who is a software engineer at HandCash, had the following to say: Handcash had to do a little more than find a couple of reputable miners and make sure to broadcast or rebroadcast every transaction involved HC users. It’s mostly about being well connected, but avoiding comms with sybil nodes, especially for the wrong reasons. In essence, it's not much of a technical challenge, but rather, business related as we needed to establish relationships with miners and work on direct, efficient communication. There are other things we can do also, but those things are private at this stage. At any point if there’s an issue, an internal alarm is triggered. So far this happened a couple of times and it was due to our own bug. Understanding network topology is the key. When it comes to double spending in BTC or BSV we need to understand there are two distinct approaches. BSV works with zero conf out of the box because miners respect first seen rule. That also reduces complexity and scalability of the node itself. It's boiled down to simple ordering of transactions without doing too much mumbo-jumbo. BSV can have reorgs and they have no effect on individual transactions because they are all based on first seen rule and they get included in all competing chains if there is a chain split situation. HandCash running on BTC would be extremely boring wallet and I would rather use traditional banking service then as it's much faster. Handcash is one of several competing BSV wallets that are competing, but also working together to develop a more robust experience through various workshops organised by Bitcoin Association. Eli Afram @justicemate

Latest replace by fee News

Responding to Antonopoulos on the BTC double-spend analysis

400 Aussie merchants drop BTC as payment method over crypto exploit

Police in Canada hunt BTC ATM double-spend scammers