BTC also has the Dark Forest: exposing malicious bots on the chain

Author: Tal Be'ery

Source:

Translation: Vernacular blockchain

Zengo’s researchers revealed that malicious bots were monitoring the existence of unsafe random addresses on BTC blockchains and immediately exploited them to commit thefts, causing millions of dollars in losses – one of which happened on November 23, 2023.

As part of Zengo X’s ongoing research in the field of blockchain security, we investigated the case of the recently lost 139 BTC, which amounted to about $5.5 million at the time. Unbeknownst to us, by doing so, we opened BTC Pandora’s box of the Dark Forest.

In 2020, Paradigm researchers Dan Robinson and Georgios Konstantopoulos published an influential blog post titled “ETH Workshop is a Dark Forest”: revealing the bots that lurk in the darkness of ETH Workshop’s memory pools, monitoring pending transactions and trying to capitalize on the lucrative opportunities they create. **

Today, we reveal that this phenomenon is not limited to ETH blockchains, but also applies to BTC blockchains (and possibly many others).

1, this case of excessive fees

On Nov. 23, a BTC deal caught the attention of BTC analysts. **This transaction set a record for the payment of fees, paying more than $3 million (83 BTC) for the transfer of $2 million worth of BTC. **

Although the immediate explanation for these exorbitant fees (which are usually supposed to be less than $10) is to blame them on some kind of manual typing error, as has happened in the past, it didn’t take long for users to claim that they were the original owners on X (before Twitter) and were somehow hacked. **

The owner of Account X cryptographically proves that they actually own the BTC address by signing it with the associated private key.

2, our investigation has begun

As we begin to investigate this exorbitant fee deal in more depth, some more subtle but interesting facts emerge.

Marked transactions (Source: mempool.space)

The above shows some interesting insights:

CPFP: This stands for “Child Pays For Parent”, meaning that the input to this transaction is the output of another unconfirmed transaction. In this case, it means that while the first transaction was waiting in the mempool, the overcharged transaction occurred. According to the data of the explorer, it was actually sent in the same minute as the previous transaction. **The cost is exactly 60% of the total spent (83.65 / 139.4), so it is unlikely to be a mistake, but rather the result of some kind of automated action. **

RBF Disabled: The sender of the transaction has disabled the option to “Replace By Fee” (RBF), or has prevented other transactions from overwriting the transaction with a higher fee. In addition, another X user noticed that there were initially multiple candidate over-fee transactions, substituting each other by paying a higher fee (no longer visible in the explorer, as the replaced transaction information was cleared within a short period of time).

3. Actual situation: Let’s assume first

Based on the data, there are several possible hypotheses to explain this over-fee transaction:

The original owner overpaid for a mistype: The owner’s statement on X was just to save face, as claiming to have been hacked sounds more acceptable than admitting to being clumsy.

Note: This doesn’t seem very plausible, as the transaction was sent while the previous transaction was still in the mempool (see CPFP above), which required technical expertise, and the exact nature of the fee (exactly 60% of the total fee) does not match the misinput or general clumsy theory.

The original owner’s private key was hacked: The attacker revealed the private key and waited for the owner to send funds to the address.

Our Opinion: This is unlikely because the transaction was preempted by RBF, which means that multiple parties are aware of the private key.

The original owner’s private key is predictable: The private key is created in some predictable way, such as by hashing a passphrase (“Brian-wallet”) or selecting a key from a set that is too small (32 bits). These issues are discussed in depth in our recent blog post.

Attackers are generating a collection of all these predictable private keys and their corresponding addresses, and whenever a transaction to send funds to any of these addresses is in the mempool, they are immediately swift and scrambling to send subsequent transactions to transfer those funds to their address.

This last assumption explains everything: Immediate response (“CPFP” above) and exorbitant fees are what attackers have to do in order to defeat other attackers. The “fixed” nature of the fee (60%) is due to the automatic nature of the operation, which is necessary in order to defeat the other parties. Disabling RBF is another mechanism employed by attackers to increase their chances of defeating other parties.

This assumption is also consistent with the past behavior of the address on the receiving end of an excessively high fee transaction. Many of the transactions that flow into the address have the same characteristics as this high-fee transaction (though not as lucrative as this multi-million dollar transaction).

The attackers’ behavior is consistent (source: X/Twitter).

This conclusion is, of course, a very frightening and bold explanation that requires further evidence. **

4. Evidence

To verify our claims, we decided to generate a predictable private key, send funds to it, and observe the results. If our assumptions are correct, then the funds should be stolen immediately. To create a non-random private key and get the generated address, we used Ian Cloeman’s popular web tool (which has worked well in the past as well).

Set the private key to “1” (note that the generated mnemonic phrase is mainly composed of the word “abandon” with index 0)

Using this tool, we set the private key to “1” and got the generated address: bc1q4jgysxym8yvp6khka878njuh8dem4l7mneyefz. We verified that it had not been used before to rule out other possible explanations.

Then we sent a $10 transaction to this address… As expected, we found out that this was followed by an exorbitant fee transaction ($5, or 50%) that redirected the funds to another address!

In addition, we observed fierce competition between multiple parties trying to gain an advantage through RBF with higher fees, which even amounted to nearly 99% of the funds, but these attempts were unsuccessful due to the first transaction disabling RBF.

4 RBF transactions, the last one offered $9.87 out of a total of $10 as a fee.

5. Conclusion: Monsters do exist

If a user’s seed phrase or private key is generated in a predictable manner or subject to undesirable randomness, it will be exploited once the attacker learns the exact details of the predictable generation. **

As we detailed in our recent blog post, the issue of secure key generation in crypto wallets is overlooked by most users, but it proves to be an issue that plagues wallets and causes huge losses.

Since users can’t generate their own private keys, but they can’t prove that the private keys are random, users can’t verify the randomness of their keys and must trust their wallets.

This issue is yet another manifestation of a larger core problem that relies on single-party wallets. In order to solve this core problem, as well as the specific problem of randomness, we must accept the fact that users need to trust some external entities and move to a more robust architecture that reduces trust in each involved party by increasing the number of parties involved. **

Adding participants can reduce the trust required for each participant and make the system more robust (see our recent blog post for details).