Skip to content

Instantly share code, notes, and snippets.

@Enegnei
Last active September 26, 2021 17:52
Show Gist options
  • Save Enegnei/0bbfc8d7f23b79f3dbf1baffe967b599 to your computer and use it in GitHub Desktop.
Save Enegnei/0bbfc8d7f23b79f3dbf1baffe967b599 to your computer and use it in GitHub Desktop.
A list of several major errors in the BTC Threat Model

2.1.2 An attacker could use a quantum computer to guess everyone's private keys.”

It is very unlikely that quantum computing or any other field of scientific research will result in such a drastic rewriting of our understanding of the basic laws of physics.”

This is probably one of the easiest threats where he could have provided statistical analysis data, as private key collision is a very popular concern and there are numerous technical forums which have addressed it over the years.

He incorrectly states that “the private key is so large that it would take more energy than is produced by the sun in its entire lifetime to power a computer capable of guessing it.” This demonstrates a very poor understanding of not only Bitcoin, but cryptography and quantum computing, as the "size" of ECDSA keys is no match at all for a quantum computer with sufficient qubits.

The real “safety feature” Bitcoin already possesses, which prevents the theft of funds by an attacker using a quantum computer, is how addresses are generated and how funds are sent with pay-to-public-key-hash (P2PKH) instead of pay-to-public-key (P2PK). Bitcoin’s ECDSA public keys are double-hashed with SHA256 and RIPEMD160, and the public key is not revealed until funds are spent, which protects those funds from being stolen should someone manage to break ECDSA with a quantum computer and figure out private keys based on public keys. It is this double-hashing which makes such a quantum computing attack practically impossible (unless there is address reuse). In the event that a bitcoin user generated their private keys improperly, i.e. without sufficient entropy (which is less common now but still happens), a quantum computer would not even be needed. And for any coins sent with pay-to-public-key (P2PK), those public keys are exposed and would be vulnerable if ECDSA is broken.

As long as thefts of private keys is not systemic it will not prevent the adoption of Bitcoin as cash. This is especially true as long as theft of private keys remains more difficult than the theft [of] government money.

As we mentioned, he does not evaluate the threat of private key theft or loss, nor name factors which could lead to systemic loss (ex. hacking custodial systems, malicious wallets, vulnerabilities in laptops, mobile devices, or their network protocols).

Interestingly, he has said that he only has “a small portion of my net worth in bitcoin for security reasons.” When asked to explain why, he asserted that “you need to spend 10x on personal security when holding bitcoin as compared to holding government money.” Since he does not seem to believe in his own prior claim that private key theft is difficult, a more rigorous evaluation of the risks would be more than justified.

2.2.1 An attacker could broadcast a fake transaction to the network in order to steal bitcoins.”

While ‘JW’ is correct that transactions must be signed by the correct private key in order to not be considered “fake,” he does not mention the rest of the consensus rules a transaction must follow in order to be considered valid by the Bitcoin network. For example, a transaction will be considered invalid if it is trying to spend funds which have already been spent, spend more bitcoin than it controls (or exists in total), or if it exceeds the maximum script size, even if that transaction is properly signed. Creating transactions and blocks which follow a different set of rules that are incompatible with the rules of the chain up until that point is considered a fork. There are also additional rules that apply if conditions like timelocks are opted into.

It is possible that he omitted these rules because he considers consensus to be “an illusion" (LOL), yet the security of Bitcoin is very much underpinned by the fact that everyone participating must follow all of the consensus rules.

2.2.4 An attacker could identify the participants in a transaction through public transaction data.”

This is another area where he not only does not seem aware of privacy threats, but fails to offer mitigations. He claims that “addresses are randomly generated for each transaction and not tied to an individual's identity.” However, while this was something encouraged by Satoshi in the whitepaper to maintain privacy, using a new randomly generated address for each transaction is not something that most wallets actually enforce. Whether because users are unaware that they should generate multiple addresses, or because managing multiple addresses can be confusing and cumbersome, address reuse is widespread. Many people also choose to publicly associate addresses with their legal or pseudonymous identities, which makes clustering them even easier. As a privacy-focused wallet, Samourai has many features which automatically help prevent address reuse.

The math problem is so difficult that a significant amount of money must be spent on electricity in order to solve the problem.”

For someone claiming to be a security researcher, it is strange that his explanation of mining is so non-specific, or that he doesn’t at least link to a more accurate technical definition. His assertion that “a significant amount of money must be spent” is also historically inaccurate (bitcoin mining was once done on ordinary laptops instead of ASICs). The computational difficulty of brute-forcing these hash patterns fluctuates, depending on the cumulative amount of computational resources being applied by mining nodes in the network.

Layer 2 technologies such as the lightning network reduce this threat because transactions are confirmed instantly.”

This statement was made in the context of “running mining software in order to double spend bitcoins.” It is false because Lightning payments are not initially “confirmed” in the same way that on-chain bitcoin transactions are, i.e. by being included in blocks. Lightning payments are pre-signed contracts with their own routing protocol, nodes, and enforcement mechanisms for cheating. These payments are not “confirmed” until an on-chain settlement transaction is broadcast. Because the Lightning Network and other second layers rely on the consensus layer of Bitcoin for security, they have no ability to “reduce this threat” and their speed is irrelevant to the problem.

The Bitcoin proof of work has been in use on the Bitcoin network for over 8 years and the only flaw uncovered to date only allowed the attacker to fake ~20% of his work.”

In this section, ‘JW’ claims that ASICBoost was an “attack” on Bitcoin’s proof-of-work algorithm; in fact, he specifically cites the overt ASICBoost defensive patent website as evidence. He fails to distinguish between covert “merkle grinding” and overt “version rolling” ASICBoost, despite it being a topic that Block Digest covered, shared, and discussed with him in March 2018. While covert ASICBoost incentivised mining empty blocks, the biggest problem was that its use would have prevented the adoption of SegWit, a malleability fix; this is not the case with overt ASICBoost. Therefore his final claim that ASICBoost was “a result of a known design flaw (transaction malleability) that has been fixed” is also false, as overt ASICBoost and SegWit are not incompatible.

In another section of his document, he praises Bitcoin for using “cutting-edge chip design to produce computer power as efficiently as humanly possible,” not recognising that efficiency is precisely why overt ASICBoost is still being used today!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment