TL;DR: Zengo researchers shed light on malicious bots monitoring the Bitcoin blockchain for bad randomness addresses, exploiting them immediately, stealing Millions in USD – one of which happened on November 23rd, 2023.
This is a horror story.
Introduction
As part of Zengo X’s ongoing research in blockchain security, we investigated the recent case of 139 lost Bitcoin or about $5.5M at the time of this publication. Little did we know that by doing so we opened Pandora’s box of Bitcoin’s Dark Forest.
In 2020, Paradigm researchers Dan Robinson and Georgios Konstantopoulos published their seminal and influential blog post titled “Ethereum is a Dark forest”: Shedding light on bots lurking in the darkness of Ethereum’s mempool, monitoring pending transactions and attempting to exploit profitable opportunities created by them.
Today, we unveil how this phenomenon is not limited solely to the Ethereum blockchain, but also applies to the Bitcoin blockchain (and probably to many others).
The excessive fees case
On November 23rd, a Bitcoin transaction caught the eye of Bitcoin analysts. This transaction set a record for paid fees, spending more than $3M (83 BTC) in fees to transfer $2M worth of BTC.
While the immediate explanation for the excessive fees (normally fees would be less than $10) was blaming it on some manual typing error as happened in the past, soon a user had claimed on X (formerly Twitter) that they were the original owner and hacked in some way.
Source: X / Twitter
The X account owner cryptographically proved they actually owned the Bitcoin address by signing with the relevant private key.
Our investigation begins
When we started looking deeper into the excessive fee transaction, a few more subtle yet interesting facts popped up.
The annotated transaction (source: mempool.space)
The above depicts a few interesting insights:
- CPFP: “Child Pays For Parent” meaning this transaction’s input, is another unconfirmed transaction’s output. In this case, it means that the excessive fee transaction was sent while the first transaction was waiting in the mempool. According to the explorer data it was actually sent in the same minute of the previous transaction.
- The fees are exactly 60% (83.65 / 139.4) of the total funds spent, therefore unlikely to be a typo and likely a result of some automatic operation.
- RBF disabled: The sender of the transaction disabled the option of following transactions to “Replace By Fee” (RBF) or override this transaction with higher fees.
Additionally, another X user noticed that originally there were multiple candidates for the excessive fee transaction, replacing each other by paying higher fees, using the aforementioned RBF (no longer seen in explorer as the information of replaced transactions is purged after a short while).
What actually happened: Our hypotheses
As a result of the data, there could be multiple of possible hypotheses to explain the excessive fee transaction:
- The original owners paid excessive fees as a result of their typo: The claims of the owner on X are just to save face, as it is more acceptable to claim you were hacked and not just clumsy. Note: This does not seem reasonable, as this transaction was sent while the previous transaction was still in the mempool (see CPFP above) which requires technical expertise and the exact nature of fees (exactly 60%) which does not meet the theory of typos and general clumsiness.
- The original owners’ private key was hacked: The attacker revealed the key and waited for the owners to send funds to this address. Our take: This is unlikely, as the transaction was contested by RBF which means there were multiple parties aware of this private key
- The original owners’ private key was predictable: The private key was created in some predictable manner, e.g. by hashing a passphrase (“Brian-wallet”) or selecting the key from a too small set (32 bit). Such issues are discussed in depth in our recent blog post.
The attackers are generating a set of all such predictable private keys and their corresponding addresses, and whenever a transaction sending money to any of those addresses shows up in the mempool, they immediately rush and fight to send a subsequent transaction to move these funds to their addresses.
This last hypothesis explains it all: The immediate response (“CPFP” above) and excessive fees are required for the attackers to beat other attackers. The “round” nature of fees (60%) is due to the automatic nature of operation, required to beat other parties. Disabling RBF is another mechanism taken by attackers to increase their chances to best other parties.
This hypothesis is also consistent with the past behavior of the address on the receiving end of the excessive fee transaction. Many of the transactions flowing into it, have the same characteristics of this high fee transaction (although not as lucrative as this Millions USD transaction.)
The attacker’s behavior is consistent ( source: X / Twitter)
This conclusion is of course a very scary and bold explanation that requires further proof.
The proof
To test our claim, we decided to generate a predictable private key, send funds to it, and observe the outcome. If our hypothesis is correct then it should be stolen immediately. To create a non-random private key and get the resulting address we used Ian Cloeman’s popular web tool (that has served as very well in the past).
Setting the private key to be “1” (note the resulting seed phrase is appropriately consists mainly of the 0 index word “abandon”)
Using the tool, we set the private key to “1” and got the resulting address: bc1q4jgysxym8yvp6khka878njuh8dem4l7mneyefz. We verified it was not used in the past to eliminate other possible explanations.
Then we sent a $10 transaction to this address… and discovered, as expected, that it was immediately followed by an excessive fee transaction ($5, or 50%) that redirected it to another address!
Moreover, we observed vivid competition between multiple parties trying to win it over with even higher fees, using RBF, reaching to almost 99% of the funds, but failing due to the fact that the first transaction disabled RBF.
4 RBF transactions, the last offering $9.87 in fees out of the total $10
The conclusion: Monsters are indeed real
If a user’s seed phrase or private key was generated in a predictable manner or suffered from bad randomness, it will be exploited as soon as attackers learn about the exact details of the predictable generation.
As thoroughly covered in our recent blog post on this issue, the topic of crypto wallets’ safe generation of the private key has been largely overlooked by most users, but proves to be an issue that keeps haunting wallets and causing great losses.
Since a private key cannot be generated by the users themselves, but also cannot be proven to be random, users do not have a way to validate the randomness of their key and must trust their wallet for it.
This issue is yet another manifestation of the greater core issue of relying on a single party for a wallet. In order to solve this core issue along with the specific randomness issue, we must accept the fact that users need to trust some external entities and switch to a more robust architecture that strives to reduce the trust in each involved party by increasing the number of parties.
Adding parties reduces the required trust in each and make the system more robust (See our recent blogpost.)
MPC to the rescue
Zengo’s unique MPC architecture allows users to avoid many Single Points of Failure (SPOFs) including this specific issue of randomness.
Learn more and dive into our open-source MPC library on or Github: www.zengo.com/research
