A group of Bitcoin Core developers discussed various attack vectors for Bitcoin as well as ways to plan ahead and circumvent nefarious actors.
Bitcoin 2022, hosted in Miami, Florida, on April 6-9, featured a panel titled “Preventing Attacks on Bitcoin” with three Bitcoin Core developers: Luke Dashjr, Bryan Bishop and Jameson Lopp (substituting for Peter Todd). The panel was moderated by Shinobi.
The panelists discuss technical and social attack vectors, primarily in the development process of Bitcoin Core, that could hinder or wholly derail Bitcoin’s sole mission as immutable money. The purpose for openly brainstorming attack vectors is to formulate appropriate defense measures and, as Sun Tzu’s “The Art of War” strategizes:
“Do not trust that the enemy isn’t coming. Trust your readiness to meet him. Do not trust that the enemy won’t attack. Rely only on your ability to pick a place that the enemy can’t attack.”
The following is a summary of said panel with a quick overview of the Bitcoin Core development process.
The Bitcoin Core developers work through a development process to offer the Bitcoin protocol bug patches, software optimizations and enhanced features; they then publish these updates following community consensus via Bitcoin Improvement Proposals (BIPs). To successfully engineer an attack against the development process, on either a technical or social level, would potentially impede (sometimes critical) protocol updates and instill distrust between developers.
To clarify, Bitcoin Core is a free and open-source software implementation of a Bitcoin full node, referred to as a client. Although misleading in name, Bitcoin Core does not have centralized or “core” control over the Bitcoin network, but rather serves as just one possible client that people are free to use at their discretion. As well, the Bitcoin protocol consensus rules require that all Bitcoin full nodes and economic participants unfailingly enforce those rules when considering the validity of a block.
Additionally, Bitcoin Core updates are not downloaded automatically but rather manually, as automatic software updates provide an attack vector for a mischievous actor to compromise all the nodes and miners in a single stroke.
The Bitcoin Core team of developers do not pedestal a single leader or spokesperson — thus distancing the client and development process from personal character exploitation due to faults all earthly leaders inherently possess. For example, narcissistic leaders can be weakened by creating unrest within their fan base, or short-tempered leaders can behave irrationally when provoked with insults. To overturn an upstart movement, one must cleverly dispose of its leader or fracture their following.
Yet without a single leader, how do independent Bitcoin Core developers come to agreement on complex design choices or emergency bug fixes? The aforementioned BIPs are used in the Bitcoin Core development process to implement features or information to the Bitcoin protocol, but BIPs also work to standardize the communication of new ideas, as diagrammatically depicted below and as described in BIP 1:
How can we throw a wrench into this process? Despite introducing some formality via BIP 1 into an otherwise unstructured network, there presents an opportunity for malicious or simply misguided actors to subvert the development process through both technical and social means. Recognizing this “wrench” however is often only possible in hindsight — making certain attack vectors especially difficult to detect and avoid. If you can dodge a wrench, you can dodge a deviant developer hell-bent on pushing their self-serving agenda at Bitcoin’s expense.
In practice, actual BIP implementations are not as neat as a workflow diagram and the above explanation has been abridged. However, we can begin to theorize nefarious methods to subvert the decentralized development process.
Note: The term “consensus” is an ambiguous word used to imply several different things beyond the rules of Bitcoin. Typically used to indicate “everyone basically agrees” on a decision while, in reality, there are more accurate, distinct words that work to better define the varying levels of agreement on a decision than the catch-all term “consensus.” For simplicity’s sake, this article refers to near-unanimous and general agreement as achieving “consensus.”
The Bitcoin network deployed in 2009 with several critical bugs and oversights that could have resulted in serious technical attack vectors, but those publicly-known vulnerabilities were remedied long ago. Generally speaking, these bugs and oversights are hard to find as there is nothing in the code that is obtrusively or painfully obvious. A dedicated open-source development community voluntarily contributing to the codebase has worked incessantly to improve the protocol’s integrity over the past decade and then some. By understanding past vulnerabilities and their solutions, we can remain vigilant in mitigating future flaws and provide a basis for generating worst-case scenarios to search for potential defense mechanisms.
Certainly the most notable social attack on the Bitcoin community and development process occurred in 2015 when two well-respected and veteran Bitcoin developers at that time, Gavin Andresen and Mike Hearn, created and promoted a new, incompatible Bitcoin client labeled Bitcoin XT. Bitcoin XT proposed increasing the possible transactions per block, known as the blocksize, as a means of competing with conventional payment systems such as MasterCard or Visa. By adopting this incompatible version of Bitcoin, users would effectively hardfork, or make valid, previously invalid blocks and transactions which ultimately forces everyone to upgrade their clients similarly — else risking network stability and replay attacks.
Bitcoin’s creator, the anonymous Satoshi Nakamoto, had long since stepped away from Bitcoin when this controversial project was announced and the community was left to decipher Satoshi’s comments for guidance as though they were sacred writ. Bitcoin XT failed to gain consensus as it naively proposed increasing the maximum blocksize and its proponents sought to subvert user consensus through closed-door, developer-miner-corporation collusion. Without getting into every minute detail of the infamous “blocksize war” and spawning an entire book, we can plainly observe from the intensive two-year squabble the critical function of full nodes (users) coordinating to enforce new rules without support from miners via user-activated softforks (UASF).
Had Bitcoin fallen into the big block trap, network decentralization and Bitcoin’s apolitical nature would have suffered accordingly. To understand the ramifications of changing a seemingly simple variable, that being the blocksize limit, requires not only understanding the technical impact on the codebase integrity, but also hidden consequences inviting additional attack vectors against the nascent network ecosystem. One can extend this line of thinking toward today’s asinine suggestions of shifting Bitcoin to proof-of-stake in lieu of proof-of-work. Even though the solution to the blocksize war was resolved technically through a UASF, the social drama that ensued required non-technical solutions of simply remaining firm and not budging on a detrimental software implementation, no matter the corporate or celebrity developer backing.
Dashjr contends an attack on the Bitcoin Core development process occurred just last year: the “Speedy Trial” activation method of the much-anticipated “Taproot” softfork upgrade (BIP 343). The Speedy Trial logic works to activate a BIP implementation without the risk of an undesirable chain split by means of either quickly succeeding or quickly failing to activate within a three-month timeframe. Once the work to build Taproot was finalized, the developers could not come to general agreement on the activation method and essentially ignored the crucial step of first receiving undoubtable community consensus.
Although Taproot successfully activated and the subsequent features provided were unquestionably beneficial for users, its activation method was perceived as controversial and posed potential vectors of attack while setting poor precedence for future BIP activations. The Speedy Trial activation mechanism was seen as an attack on the Bitcoin Core development process because some developers stepped away from the perceived community consensus while refusing to consider BIP 8 as an activation method, otherwise known as the “Let’s see what happens” proposal, in the deployment of Taproot.
The Speedy Trial method was antithetical to the blocksize war outcome, where the feud concluded that users coordinating near-unanimous agreement should control the network consensus rules and not the miners. With Speedy Trial and without BIP 8, the decision to activate (or not activate by just not signaling when it’s deployed) entirely depended on the miners regardless of user consensus. The arguably reckless Speedy Trial deployment method went against perceived community consensus and, to mitigate this in future, would potentially require coordination of a UASF with enough viable adoption beyond a few concerned people in the corner of a room to counter a BIP’s activation.
The panelists at “Preventing Attacks On Bitcoin” considered how to assess these historical attacks and avoid similar attacks in future. The “attackers” pushing for Bitcoin XT or Speedy Trial may not have had malicious intent with their proposals, yet clearly their methods conflicted with certain principles which a portion of the community adamantly defends — that is, the users have the sole right to approve or veto changes to the consensus rules. In hindsight, the attackers simply did not follow the same principles of Bitcoin that the community did, which resulted in those attacks becoming a subjectively interpretive war of what was “best” for Bitcoin.
The aforementioned Bitcoin XT and Speedy Trial scenarios convey the methods in which Bitcoin Core’s development process could be made controversial, emphasizing the necessity to approach all BIP implementations cautiously and thoughtfully. In the following sections, the panelists theorize additional plausible attack vectors.
Bishop’s interests in the development process include deterministic builds and build signing which can be leveraged to prevent certain attack vectors on Bitcoin users, namely attacks that seek to fool the user into believing they have downloaded a bona fide Bitcoin Core client.
Anyone who is a user of a Bitcoin client must download it from somewhere on the spam-ridden internet. If the webpage hosting the download file is compromised or intercepted during download, then the file itself may have been maliciously modified. How can that user prove the version they downloaded is indeed the intended Bitcoin client?
The common method to provide non-repudiation of a software build, or proof of the integrity and origin of the data, is with digital signatures. Digital signatures, the tamper-proof wax seal’s electronic and mathematically-inclined cousin, are a standard element of most cryptographic protocols using asymmetric (public and private) keys to enable authentication between two strangers — but wait! This does not guarantee signature authenticity. Ultimately, authentication without confidence in the keys used to verify the signature is pointless as the recipient must be assured the verification key truly belongs to the sender.
There is then another sly attack vector if the verification software itself is compromised. A clever criminal claiming to be someone who they are not, but having to also prove their claim through a digital signature, could plant the compromised key-verifying software for the unsuspecting user to download and consequently be presented with a false result of authentication. The compromised software contains a very subtle bug that, at a quick glance of the code, would manipulate the user into reasoning the verification software yielded an accurate result.
While deterministic builds do not solve authentication of digital signature possession, it does work to reduce the trust required in a single source or claim to the software a user has downloaded. Deterministic builds work to protect the software implementation against a couple rogue developers or a compromised developer’s keys during the development process. This protection is achieved through cryptographic hashes of the software that developers digitally sign as the software is built during each step of the build process — effectively ensuring that the final software binary files are the same as the binary files that the honest developers built and therefore hasn’t been compromised in any form or fashion.
Altogether, with deterministic builds and build signing, one can basically trace trust in the software from the binaries to the source code to the git commits made by various developers and identify what changes were introduced by whom. The legitimacy of the software can then be further investigated through techniques like web of trust where users can arbitrate whether or not the keys being verified are authentic and they are operating the intended Bitcoin client. Therefore, without taking advantage of deterministic builds and build signing, the user is susceptible to a myriad of attack vectors.
One such example: if a user downloads a Bitcoin client through HTTP in lieu of HTTPS with a public Wi-Fi connection, perhaps at a foreign coffee shop or hotel, while not verifying the build signing, then attackers could very well intercept the user’s download connection and replace the download file with a villainous version of Bitcoin that may steal coins, spy on users, or perform other harmful functions.
Bishop finds that a “fun” part of the software building process is maintaining consistent development environment variables which work to eliminate any sources of non-determinism. Non-deterministic sources could result in undesirable variabilities of the build signing due to the naturally open environment developers are building on. A variability, like differing operating systems between individual developers, generates an entirely different hash at the end of the development process. Ideally, removing all sources of variability in the build environment would improve deterministic builds and subsequently improve trust in their integrity.
Lopp, channeling his inner Sun Tzu, devises a particularly devious method of dividing and manipulating Bitcoin Core a la nefarious developer(s) sowing discontent throughout the community and GitHub repositories. If a respected developer were to convey extreme irritation and anger towards any and all protocol improvements, patches or changes, then the growing general consensus will be one of fear towards touching the protocol. This “freezing” of the development process is known as ossification and would make continued protocol improvements practically impossible.
Perhaps achieving ossification is ultimately beneficial for the protocol since this would imply Bitcoin’s widespread established dominance, yet Lopp argues just the opposite in that ossification is an exploitable attack vector rather than an effective defense. While ossification works to defend against detrimental changes to the Bitcoin protocol, such as Bitcoin XT, it could also work to prevent beneficial or necessary updates that provide increased peer-to-peer privacy and more robust codebase improvements.
The attack vector Lopp describes would be extremely difficult to assess on the spot whether an active confrontation in the development process is an attack on the protocol or a legitimately constructive disagreement. This speaks to the previous point where, in hindsight, the attack is much more visible after the fact. Without possessing total omniscience of each developer’s true intent, the development process would be stuck between a rock and a hard place.
Defense against technical attacks, like the above-mentioned early bugs and oversights, are relatively straightforward and logical in their solution. When introducing the erratic, human element, however, we begin playing a dangerous game with far less predictability. Socially-engineered attacks are often packaged with fuzzy solutions and will likely have to be dealt with as they come. A targeted memetic or mainstream narrative attack can be entirely inconspicuous and determining a defense against them is largely a gray area.
Warfare is the philosophy of deception. Arguably, the most logical attack vector for would-be adversaries might be to incite social discontent and meme warfare. Lopp explains that deliberately forcing ossification is the perfect attack because many users would consider it a defense.
The continued prevalence of Craig Wright, an individual claiming to be the anonymous Satoshi Nakamoto, and his cryptographic antics plus judicial intimidation of Bitcoin Core developers represents a direct attack on the Bitcoin Core development process. Despite the mounting evidence that Craig Wright is not Satoshi Nakamoto, he continues to wreak havoc by racking up millions of dollars in legal fees and effectively outbidding the defense because of the astronomical costs — financial and personal — that Craig Wright imposes on volunteer developers and contributors via Strategic Lawsuits Against Public Participation (SLAPP suits). Recall the clever criminal claiming to be someone who they are not, but having to also prove their claim through a digital signature; this exact scenario played out but, due to the abstruse nature of asymmetric cryptography, has been ineffective in convincing the judicial system.
Consequently, Bitcoin Core developers should adopt anonymous contribution methods or risk being targeted by an expensive and burdensome litigation process. These methods of anonymity ultimately depend on the individual’s privacy practices, perhaps such as avoiding Bitcoin 2022 and conferences entirely to maintain anonymity. Yet litigation against a supposedly anonymous individual could still be possible if there is an IRL name or personally-identifying element tied to that developer’s pseudonym. However, the need for contributing privately is itself a present and future burden on developers and their families.
Eventually, if these judicial attacks on Bitcoin Core contributors persist or Jack Dorsey‘s Bitcoin Legal Defense Fund runs dry, developers will be pushed out of the space and further escalate protocol ossification since burning money in unending litigation is not very attractive; a “death by a thousand cuts,” as Shinobi eloquently summarized it.
If Bitcoin is expected to survive and thrive not just in this century, but for many centuries and so on, then careful steps must be taken in formulating defense mechanisms against expected and unexpected attacks on Bitcoin Core as well as the Bitcoin ecosystem. You can’t have a multi-generational wealth vehicle if it becomes worthless before you die.
While the panelists held differing views on whether attacking Bitcoin users is equivalent to attacking the Bitcoin protocol, there continue to exist vectors of attack on the users, like the aforementioned fraudulent digital signatures and the ongoing Craig Wright legal saga. Other vectors include poor wallet build practices or malicious mainstream narratives brainwashing users that could be significantly detrimental to certain principles of Bitcoin we find paramount.
In spite of advancements in Bitcoin private key management, known as wallets, there remains the possibility of bad actors intentionally building wallets that do not follow the latest nor ideal security practices available to them. For instance, there are still wallet implementations that use a single address to send and receive bitcoin — thus exposing any privacy users may have.
As well, although not necessarily intentional but rather a result of its limitations, any kind of light wallet (one that does not also operate as a full node itself) requires a connection to a full node in order to communicate transactions. Light wallets, particularly popular for casual users, pose the duality of a simple, easy-to-use interface, but also present gaps in security ripe for attack vectors. Users of these wallets are susceptible to their transaction communications being intercepted by potentially nefarious actors. A straightforward solution — but impractical for some — to this vector would be to forego using light wallets in favor of full node wallets.
Shinobi envisions alternative attack vectors stemming from plain disinformation campaigns against Bitcoin and then quickly spiraling into government lobbying for legal action and heavy regulations. One such obvious disinformation campaign is the unfounded notion that proof-of-stake is a viable alternative to proof-of-work. If all jurisdictions, primarily those with readily cheap and abundant energy infrastructure, fell in a domino-effect of power grabbing desperation to curb stomp Bitcoin through outright banishment of bitcoin mining, perhaps enforced via inspecting unique energy grid power modulations that can identify bitcoin mining rigs, then relocating all the existing hash power off-grid would prove quite challenging.
The process of replacing and procuring the necessary scales of energy off-grid — particularly in secret — is no easy task. As an example, solar panels and wind turbines remain far too restrictive to act as an equivalent substitute and fully shoulder a network-wide transition to off-grid bitcoin mining due to solar and wind’s inherent variable and intermittent power generation. Dashjr proposed a potential solution by deviating from the current proof-of-work standard only if the situation were dire enough. If the blockchain were halted from some unimaginable political dictation or the hashing algorithm (SHA256) used to secure Bitcoin were broken, then coming together to find a solution may be possible and would be beneficial for all network participants.
This proposal of modifying proof-of-work as we know it is itself a case-in-point for the unexpected attacks that could occur on Bitcoin and the inevitably controversial decisions through the Bitcoin Core development process that would follow given such a dire scenario.
Continuing down the path of hypothetical situations that would require time-sensitive BIP implementations, perhaps the worst-case scenario imaginable would be if the SHA256, RIPEMD-160, or ECDSA mechanisms were undoubtedly compromised — but even then, the question remains of what would be viable alternatives? Lopp jokes in saying a quantum-proof algorithm will make everybody happy, but this cheeky response will likely become reality at some point in the far future, necessitating unsavory hard fork discussions around practical defense mechanisms against quantum computing exploiting asymmetric cryptography.
Bitcoin is an apolitical money and peaceful protest against the incumbent and corrupt monetary regime. Because of the nature of the opponent Bitcoin is facing, i.e., the U.S. dollar, an unrelenting barrage of technical and social attacks against Bitcoin is likely to occur, if not already under way. Bishop relates Bitcoin’s entirely voluntary community, who is steadfastly defending Bitcoin at the ready, to that of a self-developed “immune system” that could be Bitcoin’s greatest defensive and offensive mechanism.
In summary, Bitcoin is by no means invincible. Without actively considering all potential attack vectors and seeking respective solutions, the always-waiting adversaries could find weaknesses in the code or in the community itself. Whether the attack be from colluding parties, counterfeit Bitcoin software, deliberate ossification, targeted attacks through the judicial system or some unknown future disaster scenario, Bitcoiners must work together and unite to seal any gaps that could be the beginning of the end for Bitcoin.
The aim of this panel is not to instill in the audience doom nor gloom, but rather to prescribe a proper dose of reality with the very possible attacks Bitcoin development and the network could encounter moving forward. Ignoring this would be incredibly detrimental to the overall security of Bitcoin if we decide to live in blissful ignorance of these attack vectors. Should history have anything to teach us, it would be that all existing and previous monetary regimes — outside of Bitcoin — have succumbed to the fallibility of human institutions. Let’s work to not have Bitcoin experience a similar fate.
Humans are rationally driven by monetary incentives which has enabled the open source, pseudo anonymous, monetary nature of Bitcoin to harness a large, skilled group of hackers with opportunity for a reward of the scarce currency that is bitcoin. The discovery and exploitation of flaws that could compromise Bitcoin would paradoxically diminish the attacker’s newfound wealth — thereby, in theory, monetarily encouraging hackers to continually support the Bitcoin network and responsibly report bugs and exploits.
Despite discussions of ways to attack the Bitcoin Core development process and the wider ecosystem with little readily-available solutions of how to exactly ascertain and prevent these attacks, Bishop ended the panel with a poignant statement that spoke to the greatest incentive of all: money. He remarked, “Bitcoin is the greatest bug bounty program of all time … good luck.”
This is a guest post by Okada. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.
Bitcoin 2022, hosted in Miami, Florida, on April 6-9, featured a panel titled “Preventing Attacks on Bitcoin” with three Bitcoin Core developers: Luke Dashjr, Bryan Bishop and Jameson Lopp (substituting for Peter Todd). The panel was moderated by Shinobi.
The panelists discuss technical and social attack vectors, primarily in the development process of Bitcoin Core, that could hinder or wholly derail Bitcoin’s sole mission as immutable money. The purpose for openly brainstorming attack vectors is to formulate appropriate defense measures and, as Sun Tzu’s “The Art of War” strategizes:
“Do not trust that the enemy isn’t coming. Trust your readiness to meet him. Do not trust that the enemy won’t attack. Rely only on your ability to pick a place that the enemy can’t attack.”
The following is a summary of said panel with a quick overview of the Bitcoin Core development process.
The Bitcoin Core developers work through a development process to offer the Bitcoin protocol bug patches, software optimizations and enhanced features; they then publish these updates following community consensus via Bitcoin Improvement Proposals (BIPs). To successfully engineer an attack against the development process, on either a technical or social level, would potentially impede (sometimes critical) protocol updates and instill distrust between developers.
To clarify, Bitcoin Core is a free and open-source software implementation of a Bitcoin full node, referred to as a client. Although misleading in name, Bitcoin Core does not have centralized or “core” control over the Bitcoin network, but rather serves as just one possible client that people are free to use at their discretion. As well, the Bitcoin protocol consensus rules require that all Bitcoin full nodes and economic participants unfailingly enforce those rules when considering the validity of a block.
Additionally, Bitcoin Core updates are not downloaded automatically but rather manually, as automatic software updates provide an attack vector for a mischievous actor to compromise all the nodes and miners in a single stroke.
The Bitcoin Core team of developers do not pedestal a single leader or spokesperson — thus distancing the client and development process from personal character exploitation due to faults all earthly leaders inherently possess. For example, narcissistic leaders can be weakened by creating unrest within their fan base, or short-tempered leaders can behave irrationally when provoked with insults. To overturn an upstart movement, one must cleverly dispose of its leader or fracture their following.
Yet without a single leader, how do independent Bitcoin Core developers come to agreement on complex design choices or emergency bug fixes? The aforementioned BIPs are used in the Bitcoin Core development process to implement features or information to the Bitcoin protocol, but BIPs also work to standardize the communication of new ideas, as diagrammatically depicted below and as described in BIP 1:
How can we throw a wrench into this process? Despite introducing some formality via BIP 1 into an otherwise unstructured network, there presents an opportunity for malicious or simply misguided actors to subvert the development process through both technical and social means. Recognizing this “wrench” however is often only possible in hindsight — making certain attack vectors especially difficult to detect and avoid. If you can dodge a wrench, you can dodge a deviant developer hell-bent on pushing their self-serving agenda at Bitcoin’s expense.
In practice, actual BIP implementations are not as neat as a workflow diagram and the above explanation has been abridged. However, we can begin to theorize nefarious methods to subvert the decentralized development process.
Note: The term “consensus” is an ambiguous word used to imply several different things beyond the rules of Bitcoin. Typically used to indicate “everyone basically agrees” on a decision while, in reality, there are more accurate, distinct words that work to better define the varying levels of agreement on a decision than the catch-all term “consensus.” For simplicity’s sake, this article refers to near-unanimous and general agreement as achieving “consensus.”
The Bitcoin network deployed in 2009 with several critical bugs and oversights that could have resulted in serious technical attack vectors, but those publicly-known vulnerabilities were remedied long ago. Generally speaking, these bugs and oversights are hard to find as there is nothing in the code that is obtrusively or painfully obvious. A dedicated open-source development community voluntarily contributing to the codebase has worked incessantly to improve the protocol’s integrity over the past decade and then some. By understanding past vulnerabilities and their solutions, we can remain vigilant in mitigating future flaws and provide a basis for generating worst-case scenarios to search for potential defense mechanisms.
Certainly the most notable social attack on the Bitcoin community and development process occurred in 2015 when two well-respected and veteran Bitcoin developers at that time, Gavin Andresen and Mike Hearn, created and promoted a new, incompatible Bitcoin client labeled Bitcoin XT. Bitcoin XT proposed increasing the possible transactions per block, known as the blocksize, as a means of competing with conventional payment systems such as MasterCard or Visa. By adopting this incompatible version of Bitcoin, users would effectively hardfork, or make valid, previously invalid blocks and transactions which ultimately forces everyone to upgrade their clients similarly — else risking network stability and replay attacks.
Bitcoin’s creator, the anonymous Satoshi Nakamoto, had long since stepped away from Bitcoin when this controversial project was announced and the community was left to decipher Satoshi’s comments for guidance as though they were sacred writ. Bitcoin XT failed to gain consensus as it naively proposed increasing the maximum blocksize and its proponents sought to subvert user consensus through closed-door, developer-miner-corporation collusion. Without getting into every minute detail of the infamous “blocksize war” and spawning an entire book, we can plainly observe from the intensive two-year squabble the critical function of full nodes (users) coordinating to enforce new rules without support from miners via user-activated softforks (UASF).
Had Bitcoin fallen into the big block trap, network decentralization and Bitcoin’s apolitical nature would have suffered accordingly. To understand the ramifications of changing a seemingly simple variable, that being the blocksize limit, requires not only understanding the technical impact on the codebase integrity, but also hidden consequences inviting additional attack vectors against the nascent network ecosystem. One can extend this line of thinking toward today’s asinine suggestions of shifting Bitcoin to proof-of-stake in lieu of proof-of-work. Even though the solution to the blocksize war was resolved technically through a UASF, the social drama that ensued required non-technical solutions of simply remaining firm and not budging on a detrimental software implementation, no matter the corporate or celebrity developer backing.
Dashjr contends an attack on the Bitcoin Core development process occurred just last year: the “Speedy Trial” activation method of the much-anticipated “Taproot” softfork upgrade (BIP 343). The Speedy Trial logic works to activate a BIP implementation without the risk of an undesirable chain split by means of either quickly succeeding or quickly failing to activate within a three-month timeframe. Once the work to build Taproot was finalized, the developers could not come to general agreement on the activation method and essentially ignored the crucial step of first receiving undoubtable community consensus.
Although Taproot successfully activated and the subsequent features provided were unquestionably beneficial for users, its activation method was perceived as controversial and posed potential vectors of attack while setting poor precedence for future BIP activations. The Speedy Trial activation mechanism was seen as an attack on the Bitcoin Core development process because some developers stepped away from the perceived community consensus while refusing to consider BIP 8 as an activation method, otherwise known as the “Let’s see what happens” proposal, in the deployment of Taproot.
The Speedy Trial method was antithetical to the blocksize war outcome, where the feud concluded that users coordinating near-unanimous agreement should control the network consensus rules and not the miners. With Speedy Trial and without BIP 8, the decision to activate (or not activate by just not signaling when it’s deployed) entirely depended on the miners regardlessof user consensus. The arguably reckless Speedy Trial deployment method went against perceived community consensus and, to mitigate this in future, would potentially require coordination of a UASF with enough viable adoption beyond a few concerned people in the corner of a room to counter a BIP’s activation.
The panelists at “Preventing Attacks On Bitcoin” considered how to assess these historical attacks and avoid similar attacks in future. The “attackers” pushing for Bitcoin XT or Speedy Trial may not have had malicious intent with their proposals, yet clearly their methods conflicted with certain principles which a portion of the community adamantly defends — that is, the users have the sole right to approve or veto changes to the consensus rules. In hindsight, the attackers simply did not follow the same principles of Bitcoin that the community did, which resulted in those attacks becoming a subjectively interpretive war of what was “best” for Bitcoin.
The aforementioned Bitcoin XT and Speedy Trial scenarios convey the methods in which Bitcoin Core’s development process could be made controversial, emphasizing the necessity to approach all BIP implementations cautiously and thoughtfully. In the following sections, the panelists theorize additional plausible attack vectors.
Bishop’s interests in the development process include deterministic builds and build signing which can be leveraged to prevent certain attack vectors on Bitcoin users, namely attacks that seek to fool the user into believing they have downloaded a bona fide Bitcoin Core client.
Anyone who is a user of a Bitcoin client must download it from somewhere on the spam-ridden internet. If the webpage hosting the download file is compromised or intercepted during download, then the file itself may have been maliciously modified. How can that user prove the version they downloaded is indeed the intended Bitcoin client?
The common method to provide non-repudiation of a software build, or proof of the integrity and origin of the data, is with digital signatures. Digital signatures, the tamper-proof wax seal’s electronic and mathematically-inclined cousin, are a standard element of most cryptographic protocols using asymmetric (public and private) keys to enable authentication between two strangers — but wait! This does not guarantee signature authenticity. Ultimately, authentication without confidence in the keys used to verify the signature is pointless as the recipient must be assured the verification key truly belongs to the sender.
There is then anothersly attack vector if the verification software itself is compromised. A clever criminal claiming to be someone who they are not, but having to also prove their claim through a digital signature, could plant the compromised key-verifying software for the unsuspecting user to download and consequently be presented with a false result of authentication. The compromised software contains a very subtle bug that, at a quick glance of the code, would manipulate the user into reasoning the verification software yielded an accurate result.
While deterministic builds do not solve authentication of digital signature possession, it does work to reduce the trust required in a single source or claim to the software a user has downloaded. Deterministic builds work to protect the software implementation against a couple rogue developers or a compromised developer’s keys during the development process. This protection is achieved through cryptographic hashes of the software that developers digitally sign as the software is built during each step of the build process — effectively ensuring that the final software binary files are the same as the binary files that the honest developers built and therefore hasn’t been compromised in any form or fashion.
Altogether, with deterministic builds and build signing, one can basically trace trust in the software from the binaries to the source code to the git commits made by various developers and identify what changes were introduced by whom. The legitimacy of the software can then be further investigated through techniques like web of trust where users can arbitrate whether or not the keys being verified are authentic and they are operating the intended Bitcoin client. Therefore, without taking advantage of deterministic builds and build signing, the user is susceptible to a myriad of attack vectors.
One such example: if a user downloads a Bitcoin client through HTTP in lieu of HTTPS with a public Wi-Fi connection, perhaps at a foreign coffee shop or hotel, while not verifying the build signing, then attackers could very well intercept the user’s download connection and replace the download file with a villainous version of Bitcoin that may steal coins, spy on users, or perform other harmful functions.
Bishop finds that a “fun” part of the software building process is maintaining consistent development environment variables which work to eliminate any sources of non-determinism. Non-deterministic sources could result in undesirable variabilities of the build signing due to the naturally open environment developers are building on. A variability, like differing operating systems between individual developers, generates an entirely different hash at the end of the development process. Ideally, removing all sources of variability in the build environment would improve deterministic builds and subsequently improve trust in their integrity.
Lopp, channeling his inner Sun Tzu, devises a particularly devious method of dividing and manipulating Bitcoin Core a la nefarious developer(s) sowing discontent throughout the community and GitHub repositories. If a respected developer were to convey extreme irritation and anger towards any and all protocol improvements, patches or changes, then the growing general consensus will be one of feartowards touching the protocol. This “freezing” of the development process is known as ossification and would make continued protocol improvements practically impossible.
Perhaps achieving ossification is ultimately beneficial for the protocol since this would imply Bitcoin’s widespread established dominance, yet Lopp argues just the opposite in that ossification is an exploitable attack vector rather than an effective defense. While ossification works to defend against detrimental changes to the Bitcoin protocol, such as Bitcoin XT, it could also work to prevent beneficial or necessary updates that provide increased peer-to-peer privacy and more robust codebase improvements.
The attack vector Lopp describes would be extremely difficult to assess on the spot whether an active confrontation in the development process is an attack on the protocol or a legitimately constructive disagreement. This speaks to the previous point where, in hindsight, the attack is much more visible after the fact. Without possessing total omniscience of each developer’s true intent, the development process would be stuck between a rock and a hard place.
Defense against technical attacks, like the above-mentioned early bugs and oversights, are relatively straightforward and logical in their solution. When introducing the erratic, human element, however, we begin playing a dangerous game with far less predictability. Socially-engineered attacks are often packaged with fuzzy solutions and will likely have to be dealt with as they come. A targeted memetic or mainstream narrative attack can be entirely inconspicuous and determining a defense against them is largely a gray area.
Warfare is the philosophy of deception. Arguably, the most logical attack vector for would-be adversaries might be to incite social discontent and meme warfare. Lopp explains that deliberately forcing ossification is the perfect attack because many users would consider it a defense.
The continued prevalence of Craig Wright, an individual claiming to be the anonymous Satoshi Nakamoto, and his cryptographic antics plus judicial intimidation of Bitcoin Core developers represents a direct attack on the Bitcoin Core development process. Despite the mounting evidence that Craig Wright is not Satoshi Nakamoto, he continues to wreak havoc by racking up millions of dollars in legal fees and effectively outbidding the defense because of the astronomical costs — financial and personal — that Craig Wright imposes on volunteer developers and contributors via Strategic Lawsuits Against Public Participation (SLAPP suits). Recall the clever criminal claiming to be someone who they are not, but having to also prove their claim through a digital signature; this exact scenario played out but, due to the abstruse nature of asymmetric cryptography, has been ineffective in convincing the judicial system.
Consequently, Bitcoin Core developers should adopt anonymous contribution methods or risk being targeted by an expensive and burdensome litigation process. These methods of anonymity ultimately depend on the individual’s privacy practices, perhaps such as avoiding Bitcoin 2022 and conferences entirely to maintain anonymity. Yet litigation against a supposedly anonymous individual could still be possible if there is an IRL name or personally-identifying element tied to that developer’s pseudonym. However, the need for contributing privately is itself a present and future burden on developers and their families.
Eventually, if these judicial attacks on Bitcoin Core contributors persist or Jack Dorsey‘s Bitcoin Legal Defense Fund runs dry, developers will be pushed out of the space and further escalate protocol ossification since burning money in unending litigation is not very attractive; a “death by a thousand cuts,” as Shinobi eloquently summarized it.
If Bitcoin is expected to survive and thrive not just in this century, but for many centuries and so on, then careful steps must be taken in formulating defense mechanisms against expected and unexpected attacks on Bitcoin Core as well as the Bitcoin ecosystem. You can’t have a multi-generational wealth vehicle if it becomes worthless before you die.
While the panelists held differing views on whether attacking Bitcoin users is equivalent to attacking the Bitcoin protocol, there continue to exist vectors of attack on the users, like the aforementioned fraudulent digital signatures and the ongoing Craig Wright legal saga. Other vectors include poor wallet build practices or malicious mainstream narratives brainwashing users that could be significantly detrimental to certain principles of Bitcoin we find paramount.
In spite of advancements in Bitcoin private key management, known as wallets, there remains the possibility of bad actors intentionally building wallets that do not follow the latest nor ideal security practices available to them. For instance, there are still wallet implementations that use a single address to send and receive bitcoin — thus exposing any privacy users may have.
As well, although not necessarily intentional but rather a result of its limitations, any kind of light wallet (one that does not also operate as a full node itself) requires a connection to a full node in order to communicate transactions. Light wallets, particularly popular for casual users, pose the duality of a simple, easy-to-use interface, but also present gaps in security ripe for attack vectors. Users of these wallets are susceptible to their transaction communications being intercepted by potentially nefarious actors. A straightforward solution — but impractical for some — to this vector would be to forego using light wallets in favor of full node wallets.
Shinobi envisions alternative attack vectors stemming from plain disinformation campaigns against Bitcoin and then quickly spiraling into government lobbying for legal action and heavy regulations. One such obvious disinformation campaign is the unfounded notion that proof-of-stake is a viable alternative to proof-of-work. If all jurisdictions, primarily those with readily cheap and abundant energy infrastructure, fell in a domino-effect of power grabbing desperation to curb stomp Bitcoin through outright banishment of bitcoin mining, perhaps enforced via inspecting unique energy grid power modulations that can identify bitcoin mining rigs, then relocating all the existing hash power off-grid would prove quite challenging.
The process of replacing and procuring the necessary scales of energy off-grid — particularly in secret — is no easy task. As an example, solar panels and wind turbines remain far too restrictive to act as an equivalent substitute and fully shoulder a network-wide transition to off-grid bitcoin mining due to solar and wind’s inherent variable and intermittent power generation. Dashjr proposed a potential solution by deviating from the current proof-of-work standard only if the situation were dire enough. If the blockchain were halted from some unimaginable political dictation or the hashing algorithm (SHA256) used to secure Bitcoin were broken, then coming together to find a solution may be possible and would be beneficial for all network participants.
This proposal of modifying proof-of-work as we know it is itself a case-in-point for the unexpected attacks that could occur on Bitcoin and the inevitably controversial decisions through the Bitcoin Core development process that would follow given such a dire scenario.
Continuing down the path of hypothetical situations that would require time-sensitive BIP implementations, perhaps the worst-case scenario imaginable would be if the SHA256, RIPEMD-160, or ECDSA mechanisms were undoubtedly compromised — but even then, the question remains of what would be viable alternatives? Lopp jokes in saying a quantum-proof algorithm will make everybody happy, but this cheeky response will likely become reality at some point in the far future, necessitating unsavory hard fork discussions around practical defense mechanisms against quantum computing exploiting asymmetric cryptography.
Bitcoin is an apolitical money and peaceful protest against the incumbent and corrupt monetary regime. Because of the nature of the opponent Bitcoin is facing, i.e., the U.S. dollar, an unrelenting barrage of technical and social attacks against Bitcoin is likely to occur, if not already under way. Bishop relates Bitcoin’s entirely voluntary community, who is steadfastly defending Bitcoin at the ready, to that of a self-developed “immune system” that could be Bitcoin’s greatest defensive and offensive mechanism.
In summary, Bitcoin is by no means invincible. Without actively considering all potential attack vectors and seeking respective solutions, the always-waiting adversaries could find weaknesses in the code or in the community itself. Whether the attack be from colluding parties, counterfeit Bitcoin software, deliberate ossification, targeted attacks through the judicial system or some unknown future disaster scenario, Bitcoiners must work together and unite to seal any gaps that could be the beginning of the end for Bitcoin.
The aim of this panel is not to instill in the audience doom nor gloom, but rather to prescribe a proper dose of reality with the very possible attacks Bitcoin development and the networkcould encounter moving forward. Ignoring this would be incredibly detrimental to the overall security of Bitcoin if we decide to live in blissful ignorance of these attack vectors. Should history have anything to teach us, it would be that all existing and previous monetary regimes — outside of Bitcoin — have succumbed to the fallibility of human institutions. Let’s work to not have Bitcoin experience a similar fate.
Humans are rationally driven by monetary incentives which has enabled the open source, pseudo anonymous, monetary nature of Bitcoin to harness a large, skilled group of hackers with opportunity for a reward of the scarce currency that is bitcoin. The discovery and exploitation of flaws that could compromise Bitcoin would paradoxically diminish the attacker’s newfound wealth — thereby, in theory, monetarily encouraging hackers to continually support the Bitcoin network and responsibly report bugs and exploits.
Despite discussions of ways to attack the Bitcoin Core development process and the wider ecosystem with little readily-available solutions of how to exactly ascertain and prevent these attacks, Bishop ended the panel with a poignant statement that spoke to the greatest incentive of all: money. He remarked, “Bitcoin is the greatest bug bounty program of all time … good luck.”
This is a guest post by Okada. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.
Feedzy
MicroStrategy's (MSTR) bitcoin (BTC) treasury model is unparalleled and the company is expected to attract…
The crypto market should see a pick up in volatility at the end of this…
Bitcoin Development Company MicroStrategy (MSTR) added 55,500 of the largest cryptocurrency for $5.4 billion, bringing…
Starting next Monday, First Mover Americas will become Crypto Daybook Americas, your new morning briefing…
What does the ragtag group including a fitness equipment maker, biopharmaceutical company and producer of…
After a prolonged downtrend relative to bitcoin (BTC), Ethereum's ether (ETH) is showing signs of…
