Bitcoin is also a dark forest revealing the malicious bots in the BTC mempool

Bitcoin's Dark Side Uncovering the Malicious Bots Hidden in the BTC Mempool

Author: Tal Be’ery, Co-founder and CTO of ZenGo; Translation: LianGuaixiaozou

Researchers have uncovered malicious bots monitoring the Bitcoin blockchain for the presence of bad random address generation and immediately exploiting them to steal millions of dollars – one such incident occurred on November 23, 2023 (see LianGuai’s previous report on “A single Bitcoin transaction fee of 83 BTC“).

This is a terrifying story.

1. Introduction

As part of ongoing blockchain security research at ZengoX, we investigated a recent case of Bitcoin theft and, at the time of publication, 139 Bitcoins (approximately $5.5 million) had been stolen. Little did we know, this would open Pandora’s box of the Bitcoin dark forest.

• Why do professionals expect a spot Bitcoin ETF? How is it different from futures products?
• Long Post Inscription – The Emperor’s New Clothes of Big Blockism
• Bitcoin’s new bull market kicks off 6 charts show that 80% of BTC wallets have made a fortune.

In 2020, LianGuairadigm researchers Dan Robinson and Georgios Konstantopoulos published their influential and impactful blog post titled “Ethereum is a Dark Forest,” revealing the hidden bots lurking in the Ethereum mempool, monitoring pending transactions and attempting to profit from them.

Today, we will reveal that this phenomenon not only exists in Ethereum but also in Bitcoin (and perhaps many other blockchains).

2. Overpayment Case

On November 23rd, a Bitcoin transaction caught the attention of Bitcoin analysts. This transaction created a fee record, paying over $3 million (83.65 BTC) in transaction fees for a Bitcoin transfer worth $2 million (55.77 BTC).

While there is a straightforward explanation for such an excessive fee (usually fees are less than $10), users soon claimed on X (formerly Twitter) that they were the original owners, somehow hacked.

Source: X/Twitter

The owner of the X account proved their ownership of the Bitcoin address by signing with the associated private key, providing cryptographic proof.

3. Investigation Begins

As we delved deeper into the overpayment transaction, we discovered some more subtle but intriguing facts.

Annotated Transaction Source: mempool.sLianGuaice

The image above provides some interesting insights:

• CPFP: CPFP (Child Pays For Parent) means that the input of this transaction is the output of another unconfirmed transaction. In this case, it means that the overpayment transaction was sent while the first transaction was waiting in the mempool. Browser data shows that it was actually sent in the same minute as the previous transaction.

• The transaction fee is exactly 60% of the total spending amount (83.65 / 139.4), so it’s unlikely to be a manual input error and likely the result of some automated operation.

• RBF Disabled: The sender of the transaction disabled the RBF (Replace By Fee) option or had a higher fee transaction override this one.

In addition, another X user noticed that there were initially multiple overpaying candidate transactions that were replaced by each other by paying higher fees using the above RBF scheme (no longer visible in the browser as the replaced transaction information is cleared after a while).

4. What happened: Our hypothesis

Based on this data, there are several possibilities to explain the overpaying transaction:

Hypothesis 1: The original owner paid too much fee due to a manual input error. The owner’s claim on X is just to save face, as it is easier to accept being hacked rather than admitting to clumsy operations. Note: This seems unlikely since the transaction was sent when the previous transaction was still in the mempool (see the CPFP section above), which requires technical expertise and a clear exact fee of 60, which does not fit with the theory of manual input errors and general clumsiness.

Hypothesis 2: The private key of the original owner was hacked. The attacker leaked the key and waited for the owner to send funds to this address. Our view is: This is also unlikely as the transaction is subject to RBF competition, which means multiple parties already know this private key.

Hypothesis 3: The private key of the original owner is predictable. The key is created in a predictable way, such as by hashing a (“Brian-wallet”) password (LianGuaissphrase) or selecting a key from a too small dataset (32 bits).

The attacker generates a set of all these predictable private keys and their corresponding addresses. Whenever a transaction sending funds to any of these addresses appears in the mempool, they immediately rush to send subsequent transactions to move the funds to their addresses.

The last hypothesis can explain everything: the attacker needs an immediate response and overpaying fees to beat other attackers. Disabling RBF is another mechanism taken by the attacker to increase their chances of beating other parties.

This hypothesis also aligns with the historical behavior of the recipients of overpaying transactions. Many transactions flowing into them have the same characteristics of high fee transactions (though not as profitable as million-dollar transactions like this).

Attacker’s behavior is consistent (source: X/Twitter)

This conclusion is undoubtedly a very scary and bold explanation that requires further evidence.

5. Proof

To verify our hypothesis, we decided to generate a predictable private key, send funds to it, and observe the results. If our hypothesis is correct, it should be immediately stolen. To create a non-random private key and obtain a resulting address, we used the popular web tool Ian Cloeman (which has been very useful in the past).

Set the private key to “1” (note that the generated mnemonic should mainly consist of 0-indexed word “abandon”)

Using this tool, we set the private key to “1” and obtained the resulting address: bc1q4jgysxyym8yvp6khka878njuh8dem4l7mneyefz. To rule out other possible explanations, we verified that this address has not been used in the past.

Then we sent a $10 transaction to this address and found that, as expected, it was immediately redirected through an overcharged transaction ($5, or 50%) to another address!

In addition, we observed intense competition among multiple parties trying to use RBF to win this transaction at a higher fee, almost up to 99% of the transaction amount, but all failed due to the RBF disabled in the first transaction.

4 RBF transactions, with the last transaction fee being $9.87, totaling $10

6. Conclusion: There are indeed ghosts

If a user’s mnemonic or private key is generated in a predictable way or has poor randomness, attackers will exploit this once they know the exact details of the predictable generation.

The security of cryptographic wallet private key generation is often overlooked by most users, but it has proven to be a persistent problem in the wallet space and has caused significant losses.

Since private keys cannot be generated by users themselves and cannot be proven to be random, users have no way to verify the randomness of their keys and must trust their wallets without alternatives.

This problem is a manifestation of the larger core issue of relying on single-party wallets. To address this core issue and the randomness problem, we must accept the fact that users need to trust some external entities and turn to a more reliable architecture by increasing the number of participants to minimize trust dependency on all relevant parties.

Adding multiple parties reduces the trust required for each party and makes the system more robust.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!