Exploiting BSV’s double-spend protection in the Genesis release

Craig Wright has relentlessly marketed himself as the sole inventor and developer responsible for Bitcoin. One would assume, he has more knowledge of the inner workings than anyone else, and could easily improve sections of the code at will, without help.

Anyone who’s aware of the 22,000+ commits (changes) made to the code since the original release — can tell you that version 0.1 was flawed, buggy and incomplete. The Bitcoin we use today was not developed by one person, it was the cooperation of hundreds if not thousands of people since 2008 and prior.

In the early days of BTC (Bitcoin), some people wondered why 0-confirmation payments are not always assumed to be valid before they’re mined. Recently, Craig Wright has misquoted Satoshi’s own posts from earlier to fit a new agenda for marketing features in BSV (Not Bitcoin).

What is the node “race condition”?

The network nodes only accept the first version of a transaction they receive to incorporate into the block they’re trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first. If one has a slight head start, it’ll geometrically spread through the network faster and get most of the nodes. A rough back-of-the-envelope example:

1 0

4 1

16 4

64 16

80% 20% So if a double-spend has to wait even a second, it has a huge disadvantage. The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn’t get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes. Satoshi Nakamoto on BitcoinTalk

https://bitcointalk.org/index.php?topic=423.msg3819#msg3819

How does the mempool double-spend attack work?

Satoshi attempted to explain in 2010 how the double-spend attack is done before transactions are mined in a block: as a transaction (TX) is sitting in the mempool.

One of the most important parts of this explanation is: “When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first.”

As shown above: When a payment is broadcast under normal conditions — It takes many “hops” to reach a final node destination known as the merchant wallet . During this process a slight delay occurs; The network nodes are fragmented in a state of partial consensus for the potential validity of that transaction (TX). Without actually “mining” or performing additional checks, nodes simply forward this new transaction to other peers they’re connected to.

At this point the network is NOT self-aware of this future “IOU” to pay the merchant once the TX is mined in a block (approximately every 10 minutes).

The mempool are transactions that qualify for inclusion in the next block only IF they’re valid. It is when they’re MINED and included in the blockchain — that full nodes check TX coin inputs and ensure they’re not found in other confirmed transaction blocks. They will reject a “double-spend” at this time and write it to the ledger for future reference, usually as an orphan block.

If mempool transactions are immutable, why are we mining blocks?

BSV doesn’t seam to understand the concept that a queue of transactions should not be assumed to be valid until they actually are confirmed by the nodes on the network. Consensus for payments are not based on a single wallet keeping track of the order in which they receive spent coinbase inputs… While unable to determine the actual consensus among the network; For an event that hasn’t even happened yet!

Consensus among the network nodes occur after the block is mined, broadcast and confirmed to be valid by the majority of nodes! This race-to-mine-first is the primary incentive driving the economic model of Bitcoin.

“Don’t count your eggs before they hatch”

How does BSV attempt to prevent this attack?

Included in the recent release “Genesis” are two new source code files: txn_double_spend_detector.cpp and txn_double_spend_detector.h.

Upon further examination, it’s clear to see in the code comments — the intended operation of these never before implemented functions by Satoshi.

These recent protocol alterations were submitted to Github from an account with the name of Richard Millis

// To avoid race conditions in double spends we need to take this mutex first

// This approach guarantees that:

// a) if dstxn1 is accepted to the mempool then dstxn2 will be rejected as a mempool conflict

// b) if dstxn1 and dstxn2 are valid txns (at this stage) then the first of them is allowed to

// continue processing but the other one is rejected as a double spend Line #26–30 found in https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/txn_double_spend_detector.cpp

Remembering Satoshi’s quote from 2010 “When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first.” One should never ASSUME that a transaction broadcast is more valid over the other based on the consecutive order in which it was received. More importantly, the self-awareness conclusion for the majority of nodes on the network is that the arbitrarily selected TX — will most likely be included in the next block is never guaranteed until after it was mined!

BSV’s altered code will now automatically give priority to the first transaction with the same coinbase inputs found in the mempool, rejecting the second one, even it it was a valid payment to a merchant or exchange!

Essentially what they did: Removed the randomized network “race-condition” described by Satoshi and implemented a default node-based settlement for detecting duplicate transactions not on the network itself! They guarantee that the duplicate TX2 will be rejected by that node, at the same time — The network could be including TX2 in the block it’s currently mining! Moments later, permanently writing it to the Blockchain ledger, invalidating TX1 NETWORK WIDE! In the process that could take minutes or seconds; The merchant or exchange suffers financial loss and the attacker receives their coins back in an address they control, minus a small fee.

How could a simple attack exploit this flaw:

Setting up two separate nodes, with the same wallet.dat (coinbase inputs/ private keys) an attacker could send their transaction broadcasts in opposite order in relation to the merchant and majority of network nodes, then wait for the next block to be mined. It’s pretty much that simple to exploit their ill-fated protection by statically choosing validity for incomplete data.

Shown below is how it could be easily performed in a visual representation.

The TXs colored in green are payments made to the attacker’s own address and the TXs colored in red are sent to the merchant or exchange’s wallet.

The first frame shows attacker 1, and attacker 2 nodes sharing the same coinbase inputs for two separate transactions in opposite order in their mempools. Green TX1 from attacker 1 is actually the same as coinbase inputs from green TX2 from attacker 2 node. This specific ordering will eventually ensure that the double-spend transactions never actually reach a “race-condition” at all; They’re pre-determined in a static format to ensure the desired transaction is confirmed!

The second frame shows green TX from attacker 1 transferring to node 1, that’s accepted into the mempool only moments later, the green TX1 is forwarded to other connected nodes.

Meanwhile — Attacker 2 has sent green TX1 as green TX2 to the merchant directly! Without using advanced node isolation attacks such as Erebus or BGP hijacking to further increase success, as required with Bitcoin (BTC). BSV now ensures it’s 100% guaranteed that the merchant node will reject green TX2 because it’s a double spend.. It fails their new code checks!

Alright, everything appears normal at this point and the merchant software queries the wallet API and accepts TX1 as a valid payment to their address and credits the product or service to the attacker.

While this process is taking milliseconds, green TX1 from attacker 1 is still propagating through the nodes on the network, eventually reaching mining pools and waiting to be included in the next block discovered.

At this point, the queued transactions used for the product or service have already completed in the shopping cart software using the red TX1. The transaction payment success is written in the merchant software database and begin to execute shipping or delivery of services. Moments later, their records are deleted from mempool and simultaneously replaced by the green TX written to the blockchain in the most recent block. The merchant account was not credited as expected, and the funds are returned to the attacker 1 wallet private keys. This gives anyone the power to cancel payments before they’re actually mined in a block — on the chain. When the new block is built from attacker 1’s green TX, it then clears the mempools and as it broadcasts to all the the other nodes, including the merchant.

Merchant software that can’t detect this slight of hand switch — immediately stopping the cart-order process before the next block is found, will eventually realize their balance is not what would be expected. The payment that should have went to their wallet address, showed up confirmed for a brief moment before red TX1 eventually was discarded and replaced by green TX1 from attacker 1 back to attacker 1! Forever recorded in history regardless of the order of TXs in the mempool.. Past, present or future! Red TX was a fake, but looked real, now the product and service shipped anyways, automatically!

The massive challenge to use off-chain protections to detect this on-chain and mempool fraud at the merchant software level is a fruitless endeavor. The software is simply unaware of the blocks currently being mined on the rest of the network with transactions only sent to specific mining nodes and not the merchant itself. Some merchants will have the upper hand advantage by manually verifying orders or a delay in shipment, and could investigate fraud already occurred while unable to depend on their BSV node to prevent it from happening in the first place; Like the way Bitcoin was designed!

“You don’t need a time machine if you know how to remember” — Rodman-Philbrick

BSV merchants are sitting ducks in a pond surrounded by hunters not afraid to exploit the allegedly “original protocol” source code, you’ve all been warned!

A message to Craig Wright and BSV developers:

I am disclosing this security audit publicly now that you’ve rejected my numerous attempts to explain this in detail to your minions (or you) on Twitter for over a month! You offered no reasonable bounty and would change the subject in an attempt to debate something about BTC or Lightning Network to fit the narrative that Craig portrays in his dysfunctional lawsuits or regular technobabble rambling blog posts; To pump the price higher.

Instead, you assume I am a paid puppet from Greg Maxwell… I have never chatted, spoken or met him in my entire life! You’re going to need to find a better defense for your incompetence to live up to your marketing promises.

Instead, you all offered trivial reasons why BTC is not Bitcoin and repeated “BSV is the real thing” unaware or perhaps fully aware that I know more about Bitcoin than you do! Troll and shills relentlessly attempting to sell a “better version of Bitcoin” with a new use. I was unable to communicate with anyone competent enough to have a worthwhile technical debate.

Your ego(s) got the best of you while you frantically tried to prove to the world you know everything about Bitcoin because you allegedly invented it. While forgetting the nature of open-source development is relying on others to assist in aspects you can’t quite understand, even if you’re the so called “inventor”.

Keep your dirty money, I will let professional security experts teach you a lesson you failed to comprehend. Lulz

You want to be Satoshi so badly, now you’re dealing with his problems! You’re one step closer to the becoming a real developer responsible for protecting the protocol. Have fun fixing your — what should appear to be obvious mistakes.

Class dismissed…