BTC was double spent this year—was BSV?

“…at 21:21 UTC, in the 21st year of the 21st century on a network of 21 quadrillion units, there was a magically small exploit of US$21 on the BTC network, and nobody seems to care—at least not yet.” 

I wrote that line the day after someone’s BTC disappeared from their wallet and was moved into another wallet on the BTC blockchain: a classic double spend by every definition accepted from 2008 until January 21, 2021. On that date, the small blocker censorship board went into overdrive to redefine one of the most important aspects of the Bitcoin protocol to protect their sacred calf: the fiat value of BTC. 

But it really was a double spend! A transaction was included in a block and displayed in the wallet of a BTC user. That balance then disappeared as the block was orphaned and the ledger reorganized by a different node on the network which built the valid block that went forward into history. Recipient A was robbed, and recipient B received his coins instead. To his credit, small blocker Peter Todd swung in to drop a truth bomb. 

In 2008, Satoshi Nakamoto explained the way this is designed to work when asked by Hal Finney. He said, “…nodes keep transactions in their working set until they get into a block… The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid…” 

Metzdowd.com: Sat Nov 8 20:58:48 EST 2008

In the first explanation of a reorganization of the bitcoin ledger (commonly called a “reorg” today), Satoshi explained how an attacker would not be adding new information to the ledger, but actually going back to previously accepted reconciliations and redoing them first while re-writing the history to strike their theft or other vandalism from the accepted history of the longest chain.

“The attacker isn’t adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he’s doing that. He’s rewriting history. Once his branch is longer, it becomes the new valid one.”

Metzdowd.com: Sat Nov 8 20:58:48 EST 2008

The funny thing is that, by the new standards set out by a cacophony of small blockers, BTC’s double spend wasn’t a double spend at all, and the media just let them get away with it. CoinDesk went so far as to say that double spends don’t exist unless they cause inflation, stating “…no bitcoin was ‘double-spent’ because no new coins were added to Bitcoin’s supply,” and then later in the same article stating, “Technically, the same bitcoin was spent twice in this scenario. But one transaction was double-spent to an address on a transaction history that the Bitcoin network does not consider valid.” 

In other words, it was a classic double spend!

BTC Core Developer Ben Carman even said, “It’s kinda a double-spend but not really. Normally a double-spend refers to when you intentionally replace a transaction that sends money to someone with one that sends it to your own wallet.” 

This is double-speak at its finest! 

So why do double spends matter?

Bitcoin is plainly [checks notes] imperfect. It only becomes a problem when malicious actors overpower the honest nodes of the network for extended periods of time, and break the trust model of the system. If users cannot rely on consistent experiences with the network or clear arbitration and remediation of mistakes, then the system is worthless.

Good thing Satoshi thought of this!

In short, the system works because we trust the honest nodes, the reputable peers, the people with whom we have built economic rapport to connect to other reputable peers for the security of the network during times of upheaval and in times of business-as-usual. This is why the proverbial “51% attack” does not exist. If a malicious actor gains majority hash power and uses it to break a bitcoin rule, the minority hash rate of honest nodes on the network becomes the majority by virtue of the fact that they are honest, and they cease acceptance of the blocks of the malicious actor regardless of how much power he brings. 

During a war, are the invading barbarians the rightful kings if they win? No. No they are not. Much the same in bitcoin. 

Satoshi Nakamoto explains in Section 8 of Bitcoin: A Peer-to-Peer Electronic Cash System: “verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker’s fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and alerted transactions to confirm the inconsistency.” 

In Section 12, Nakamoto clarifies further: “…that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power… They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.” 

So who wins? The longest chain? Or the honest chain? 

This is the socio-economic nature of the consensus process. It is the human element of being a Byzantine General and making decisions among honest nodes and honest people during times of trial and tribulation. 

What is a Byzantine General? 

Picture a city surrounded by six Generals from the ancient city of Byzantium. They know each other. They have come up through the ranks together and grown to know each other’s strengths, weaknesses and temperaments. While each general wishes to be the greatest, they understand that they must be good at coordinating and cooperating in order to do so—an incentivized relationship. 

Unfortunately, when laying siege upon a large city, they cannot communicate with one another directly. They are geographically disconnected, so they must trust riders, pigeons, letters and a host of other mediums which are difficult to validate, but they need to make coordinated decisions in order to successfully seize the city.

In short, they have a trust problem with their communication channels. This theoretical problem in communications is a computer science conundrum that was solved by bitcoin using proof of work and a public ledger. 

However, small blockers, the purveyors of BTC, misunderstand this story in assuming that the generals are malicious actors. This is to their peril. The generals trust one another. They are good. They have rapport because of the lifetime of work that they have all put in together. They cannot trust the riders or the letters. Reiterated: it is the communications channel which cannot be trusted, but if the generals could communicate, they could conquer anything! 

This is where BSV shines. 

Honest nodes (Taal, MatterPool, ViaBTC, SVPool, F2Pool, SBI, etc…) know each other. They trust each other and they can coordinate not to accept information from unknown entities both because of proof of work, but also because they can call or text with one another to organize for ideal outcomes. This mitigates the risk of any ongoing attack from ever being successful at stealing the funds of the users of the network. Under siege, the honest nodes can coordinate, reorganize, ignore and/or orphan malicious blocks. This is why the quality of nodes is far superior to the quantity of nodes in surviving attacks. 

So was there a double spend on BSV? 

Are we going by Satoshi’s definition? Pomp’s? Peter Todd’s? Ben Carman’s?

Given what we have all been through and in light of lessons we have learned in the last twelve years of bitcoin, this is a little bit of a nuanced question with an even more nuanced answer.

Let’s accept Nic Carter’s for the time-being. 

This bitcoin address [1G47mSr3oANXMafVrR8UC4pzV7FEAzo3r9] has a long history of use in “sextortion” scams, ransomware attacks and other malfeasances on the dark web. Billions of dollars’ worth of bitcoins have passed through that wallet, and it appears that that user was able to pay for the reorganization of a few blocks on a few different dates to move a UTXO from one spot to another in his own possession. 

So, the ledger was reorganized, there was no theft, but this malicious actor was able to reorganize his own portion of the UTXO set. 

But again, he didn’t take anything from anyone… So is that a double spend? 

I’ll be honest. I really don’t know, and the answer has become political because we live in a postmodern world where facts are fluid. 

Out of an abundance of caution, Bitcoin Association alerted exchanges of the possibility of an on-going attack. The response has been to pause deposits and withdrawals to mitigate the possibility of any theft, and some liquidity has needed to be shifted around to compensate for the hiccup. That’s it. 

The coins of exactly zero BSV users have been reported missing, moved or vandalized by some criminal messing with the coins in his own wallet.

Gravity, the exchange managed by Bitstocks, made a public announcement that they were halting deposits and withdrawals to investigate, which sounded alarm bells across social media and triggered “R.I.P.” posts from BSV’s enemies, but BSV never died, much to their chagrin. 

Bitstocks CEO Michael Hudson reached out to let us know, “There was little to no threat to Gravity due to the “double spend” that occurred on the network. Arguable that it wasn’t even really a double spend. However the political response was a bigger and is a bigger issue to deal with. There’s a lot of FUD being spread to liquidity providers and they have acted out of fear. We always take the safety of customers’ funds as priority and have every intention of maintaining our 7 year track record in doing so. After we completed our external investigations we had deposits and withdrawals reactivated within 16 hours, and are now doing our best to help appease the misplaced concerns of liquidity providers.”

In closing

Whether there was a double-spend or not depends on how strictly we are defining it these days. In the court of public opinion, BTC didn’t have one, so by their metrics, it is reasonable to argue that BSV didn’t have one either. But in both situations, the ledger was reorganized with a change to the UTXO set. 

The difference was that on BTC, someone lost money. On BSV, nobody lost money. 

You be the judge. 

But remember that Bitcoin still works; imperfectly by design, and because of the “first seen rule” most users would never know that anything was amiss regardless of how deeply the chain could be reorganized. And because BSV has the benefit of highly committed, honest nodes, users need not fear any enemy at the gates. Add in the highly connected nature of BSV’s nodes, the coming era of Miner ID and the simple application of the law to enforce justice upon criminals, and these problems are solved. 

“…at 21:21 UTC, in the 21st year of the 21st century on a network of 21 quadrillion units, there was a magically small exploit of US$21 on the BTC network, and nobody seems to care—at least not yet.”

And now, suddenly, people care. Maybe BTC should stop moving away from the small world network of closely connected peers at the mining level too. It might save them an incredible headache some day. 

In the meantime, for high value transactions, wait for a few block confirmations.

New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.

[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]
[10]
[10]
[id^="_form"]
[id^="_form"]
[id$="_submit"]
[id$="_submit"]
[^;]
[^;]
['on' + event]
['on' + event]
[?&]
[?&]
[^&#]
[^&#]
[(d+)]
[(d+)]
[i]
[i]
[results[1]]
[results[1]]
[elem.name]
[elem.name]
[+_a-z0-9-'&=]
[+_a-z0-9-'&=]
[+_a-z0-9-']
[+_a-z0-9-']
[a-z0-9-]
[a-z0-9-]
[a-z]
[a-z]
[el.name]
[el.name]