A must read safety article: Qubic security incident in-depth investigation: 1404 wallets were stolen, and the reason is the same as Chen Zhi's Bitcoin being taken away. What is truly alarming? one ️⃣ What are the reasons for asset theft? two ️⃣ The technical principle of theft caused by insufficient random numbers? three ️⃣ How to avoid problems with your asset storage wallet and establish a security line? This attack occurred on October 18th from 07:42 to 09:26 Beijing time. The theft of wallet assets and the opening of Chen Zhi's Bitcoin this time are actually similar in logic. Both are due to insufficient randomness in the wallet's private key generation, which may have caused attackers to exhaustively deduce the private key that should have been difficult to guess. Some Qubic wallets used unsafe random numbers when generating mnemonic words, which may result in the private key being calculated by attackers and ultimately causing asset theft. These two have exposed the same fatal problem: With the rapid development of AI and increasingly powerful algorithms, the lack of randomness in wallet private key generation can give attackers (most of the time AI) the opportunity to deduce the private key. What was breached was not Bitcoin or cryptographic algorithms, but the process of generating keys for the wallet. Returning to the Qubic incident, according to the project team's explanation, the attacker used predictable Seed to gain transaction control over some wallets and quickly transferred assets. one ️⃣ Security issues were identified at least 8 months ago; There is something that needs to be brought up and said. On February 12, 2026, a developer named fyllepo submitted a Pull Request to the Qubic official wallet repository: PR 229：fix: strengthen seed generation with crypto.getRandomValues() Chinese meaning: Fix Seed generation method by using a cryptographic secure random number generator. The developer explicitly states: The seedGen() function of Qubic wallet uses JavaScript's Math. random() to generate the wallet Seed. This method is not suitable for generating cryptographic secrets. He suggested using crypto. getRandomValues() and submitted the corresponding code and testing. More noteworthy is that: As of October 19, 2026, the PR submitted in February still shows as Open and the page shows no reviewer. That is to say, at least from public records, some developers pointed out similar issues eight months in advance, but that fix proposal has not been merged. This does not necessarily prove that the Qubic team had a complete grasp of the attack method at that time, nor does it prove that merging this PR would definitely prevent all losses. However, this fact is sufficient to raise a serious question: Why can a wallet project responsible for safeguarding user assets leave repair suggestions related to private key generation security unresolved for a long time? This deserves an explanation from the project team in the formal accident report. two ️⃣ Technical principle: Why can a 55 character Seed be easily cracked? I have talked to GPT about this for a long time: Qubic does not use the 12/24 word mnemonic commonly used in Bitcoin, but a Seed composed of 55 lowercase English letters. This is the wallet key format adopted by Qubic itself. Under normal circumstances, if each character is independently, unpredictably, and uniformly randomly generated, then 55 letters can provide a very large search space. But I saw this generation logic in Qubic's GitHub source code: const letters = 'abcdefghijklmnopqrstuvwxyz'; for (let i = 0; i < 55; i++) { seed += letters[Math.floor(Math.random() * 26)]; } The problem lies in Math. random(). This function in JavaScript is suitable for games, animations, regular sampling, and other purposes, but cannot guarantee cryptographic security. Mozilla's developer documentation explicitly reminds that it cannot be used to generate security sensitive random numbers, and that crypto. getRandomValues() should be used instead. three ️⃣ What should be noted and what inspirations should be given? If your Bitcoin mnemonic words were generated normally within a trusted hardware wallet and not created through problematic wallet software, there is currently no evidence to suggest that they were affected by the Qubic vulnerability. The Coldcard random number vulnerability, Qubic incident, as well as various database leaks and supply chain issues that we are paying attention to, are indeed reminding us: The risks of encrypted assets far exceed those of smart contracts and consensus protocols themselves. four ️⃣ How can we prevent it? It is recommended to establish five lines of defense 1. Try to use hardware wallets that have been verified for a long time, generate mnemonic words inside the device, and choose long-term verified ones as much as possible to improve security. For large assets, one can consider contributing a portion of random numbers themselves; For example, some hardware wallets support adding extra randomness to the process of generating mnemonic words by rolling real dice. A standard six sided dice can provide approximately 2.585 bits of entropy per fair and independent roll. Throwing 99 times theoretically can result in approximately 256 bits of randomness. The value of doing so lies in: Even if the random number generator inside the hardware wallet has defects, if the device correctly mixes the high-quality random numbers you provide, it may still generate secure keys. Coldcard officially provides relevant dice random number mixing and verification mechanisms. 3. Choose a wallet that can independently verify security mechanisms; Give a specific example. Trezor Safe 5 currently supports Entropy Check (Random Number Generation Process Check). It performs sampling verification when creating a wallet, checking whether the device uses random numbers in the published way. This feature can help detect issues with certain devices tampering or not generating keys as expected. But it cannot mathematically prove that every mnemonic word ultimately retained has sufficient randomness. 4. For your BTC, use different brands to form 2/3 of the signature; Even if one of the wallets has a random number vulnerability, the attacker can deduce a private key but still cannot transfer the assets separately. As long as the other two private keys remain secure and independent of each other, cracking a single private key is not enough to steal funds. 5. Pay attention to wallet security announcements, especially the firmware version used for generating mnemonic words, and frequently upgrade or even replace the device every 2-3 years