What Could Bitcoin Learn From the Internet?

Introduction

Money, in essence, is information. It establishes a common value system (a type of information), its distribution is a reflection of who has what (information), and the exchange of it signals which goods and services are valued in society (also information).

However, relative to other types of information, money is arguably the most impactful when it comes to moving the world. As the historian Harari eloquently put it:

“Money is more open-minded than language, state laws, cultural codes, religious beliefs, and social habits. Money is the only trust system created by humans that can bridge almost any cultural gap, and that does not discriminate on the basis of religion, gender, race, age, or sexual orientation. Thanks to money, even people who don’t know each other and don’t trust each other can nevertheless cooperate effectively.”

Bitcoin, by disrupting money, could trigger bigger societal changes than the Internet — which has revolutionized the way we communicate. Yet, there are important lessons Bitcoin could learn from its forebearer. In this series, we will explore some of those lessons.

Lesson 1: Security Should Not Be an Afterthought

The Internet architecture can be traced back to its original blueprint at the US Department of Defense (DoD). Its primary goal at the time was to link together a couple of DoD military networks. It also had seven secondary goals:

1. Internet communication must continue despite loss of networks or gateways.

2. The internet must support multiple types of communications service.

3. The internet architecture must accommodate a variety of networks.

4. The internet architecture must permit distributed management of its resources.

5. The internet architecture must be cost effective.

6. The internet architecture must permit host attachment with a low level of effort.

7. The resources used in the internet architecture must be accountable.

One thing immediately stands out: there is no mention of security, much less privacy. This is unthinkable in today’s world but not surprising, given that the nascent entities that the Internet was designed to link together were friendly, trusted networks that belonged to the same organization.

However, once the Internet expanded beyond the US military, first onto academia then the public, the environment quickly changed. One could no longer assume that all nodes within the network could be trusted. But the original architecture stuck.

In short, the Internet was implicitly designed for a trusted, internal network. It was then extrapolated into the public sphere, without much modification.

This had many consequences. Much of our Internet today is insecure because security wasn’t a goal in the original architecture.

For example, Border Gateway Protocol (BGP) and Domain Name System (DNS) are two of the biggest security holes on the Internet. BGP hijacking happens almost daily, while unauthenticated DNS traffic offers a fertile ground for hackers, criminals and nation states alike. Safer alternatives do exist such as DNSSEC (secure extensions to DNS), but adoption has proven exceedingly slow and challenging. Similar to IPv6 deployment, what we’ve learned over the past few decades is that fixing legacy Internet infrastructure running in production is painfully hard.

Cross-site scripting, denial-of-service, and other types of vulnerabilities are also manifestations of a trusted and security-deprived architecture.

We will now take a look at how security issues are addressed at the Bitcoin protocol and application layers.

Security Review: The Bitcoin Protocol

In contrast to the Internet, Bitcoin was designed to be trust-minimized. This philosophy is crystalized in the mantra “do not trust, verify”.

Instead of relying on trusted nodes, the Bitcoin protocol uses an objective, energy-driven metric that is Proof-of-Work (PoW). Nodes are expected to follow the heaviest and valid PoW chain, regardless of where that chain comes from. A bad actor would have to control 51% of total Bitcoin hash rate in order to attempt rewriting the chain. PoW neatly solves the double-spending problem and at the same time protects the Bitcoin ledger — the asset that gives Bitcoin all of its value.

There are also other important security mechanisms within the Bitcoin protocol.

First, a variant of public-key cryptography called ECDSA secures each and every Bitcoin transaction on the blockchain. An upgrade called Schnorr signature would make this mechanism even more elegant and cost-efficient in the near future.

Second, network spamming is mitigated by requiring fees (crucially, in Bitcoin’s native currency) for sensitive activities, such as transaction relay or broadcast. Unlike the original Internet, fees make it harder for attackers to spam the Bitcoin network with bogus data, since it will cost them real money.

Last but not least, Bitcoin can function without the TCP/IP stack by making use of amateur radio networks or satellite communication. Without redundant networking stacks, a BGP hijacking can cause the Bitcoin network to split off into multiple partitions.

However, even with all of the above, the security of the Bitcoin protocol is not perfect. Some level of trust is required to participate in the Bitcoin network, such as the use of DNS seeds or checkpoints. These issues are being worked on as we speak, but generally speaking, the Bitcoin protocol has significantly stronger security and requires much less trust than the original Internet architecture.

Security Review: Bitcoin Applications

On the other hand, there is a lot of room for improvements when it comes to security at the Bitcoin application layer.

To the detriment of Bitcoin users, Bitcoin application developers and businesses still frequently rely on the old tools and practices of the previous Internet era.

One such practice is regarding software reuse, long considered the “holy grail” of software development. Software reuse has been made significantly easier through the invention of the so-called package managers.

But this practice can backfire. It turns out that many third party libraries are written by one- or two-person teams. They rarely have stringent code reviews or good test coverage, if at all. In recent years, there has also been an increasing number of reports of popular OSS libraries getting backdoored, some of them specifically targeting Bitcoin users.

In general, software reuse is a good goal to strive for, but Bitcoin developers should be extremely selective in choosing which software to reuse.

Another software practice being abused is the over-reliance on the browser.

The fragmentation of platforms on desktop and mobile devices in the last few decades means that developers faced incredible pressure when trying to get their products to market. This pressure made cross-platform technologies such as the browser popular. The ubiquity of the web also played a role by helping create an overabundance of web developers ready to be hired.

Unfortunately, this approach comes at a huge cost. The attack surface of the browser and browser-based derivatives such as Electron is massive, and their security record is abysmal (see here, here and here for examples). Not to mention, applications built on such a stack often consume a large amount of resources.

While browser-based technologies are convenient and will likely continue to be popular, they are legacy of a security-deprived Internet architecture. They are not well suited for mission-critical applications.

Bitcoin applications, on the other hand, do belong in the category of mission-critical software that requires the most stringent quality standard. This is not unlike software written for banks (indeed, another mantra in Bitcoin is “be your own bank”). The reason a large fraction of the global banking infrastructure still runs COBOL code written decades ago is not because banks do not want to upgrade their software, but because every time they do so they face the existential risk of shutting down and losing money. In financial applications, reliability and security are of the highest priority, not convenience or speed of development. This is even more true in Bitcoin, since individual Bitcoin users don’t have the resources to maintain their systems like banks do.

As the industry matures, it is advisable that Bitcoin application developers and businesses re-examine their software practices. Attacks against Bitcoin users have already become more sophisticated, and will only get worse. The more attack surface we can minimize, the safer our Bitcoin applications.

A good place to start is to ask this hypothetical question: “Can our Bitcoin applications run and run securely ten or twenty years from now, even if there is no possibility of upgrades?”

Conclusion

In summary, one of the biggest lessons Bitcoin can learn from the first era of the Internet is that security measures have to be taken from day one. Security flaws get exponentially more expensive to fix down the line once systems have been deployed, and habits and inertia take hold.

The Bitcoin protocol is strong in this aspect, but there is lots of room for improvements for Bitcoin applications. Bitcoin software belongs in the special category of software that requires the highest standard of engineering. Bitcoin application developers should be extremely selective when it comes to software reuse, and try to avoid dependencies that come with a large attack surface such as the browser.

In the next article, we will explore how a healthy free market fostered Internet-era innovations, the importance of standards, and how those lessons might apply in Bitcoin.

*About Nunchuk: our mission is to bring multisig technology to as many people as possible, and Nunchuk is the first step. Visit our website at https://nunchuk.io or follow us on Twitter @nunchuk_io.

*About Nunchuk Journal: a collection of articles that discuss all things Bitcoin. The journal documents our thought processes in the creation of Nunchuk, how things impact the user, and observations about the industry at large.