Bitcoin Development Philosophy is a guide for new Bitcoin developers who already understand the basics of concepts and processes such as Proof-of-Work, block building, and the transaction life cycle, and who want to level up by gaining a deeper understanding of Bitcoin’s design trade-offs and philosophy. It should help new developers absorb the most important lessons of over a decade of Bitcoin development and discussion, and provide a context for evaluating new ideas (good ones and bad ones!).

Your feedback and contributions are most welcome! Instructions for building and contributing can be found in Appendix B.

### What to expect?

Bitcoin is a huge subject and we couldn’t possibly cover all of its aspects here. Nevertheless, we hope to discuss the necessary features to get you started as well as to enable you to further explore it on your own.

There are lots of people involved in Bitcoin; as some of them have opposing opinions, there are resources that express contradictory ideas. However, we always attempt to stick to the facts, where opinions do not matter.

### Who wrote this?

The main author of this book is Kalle Rosenbaum, and Linnéa Rosenbaum contributed as a co-author. This work was commissioned and funded by Chaincode Labs, a development center that runs educational programs for developers who want to learn about Bitcoin development.

Kalle is the author of “Grokking Bitcoin” (Manning Publications) and is a seasoned software developer. He’s been working professionally with Bitcoin-related development since 2015.

Linnéa has a Ph.D. in Electronic Systems. She is the Swedish translator of “The Little Bitcoin Book” and co-translator of “The Bitcoin Standard”. She is also on the board of the Swedish Bitcoin Association. Her background is in firmware development with a recent shift towards software development.

### How is this organized?

The book is sectioned into chapters covering different topics. Each chapter will guide you through a number of links to articles or videos that we recommend reading, and will briefly discuss each link. The reported material was written by individuals who have studied Bitcoin development for a long time.

The links refer to external resources on platforms we cannot control. We have therefore saved the linked articles locally in this repository, along with info on where it was copied from, and when. The resources are collected in a separate document (`sources/sources.adoc`) and organized by the chapter they are linked from. The links found in the chapters refer to the original sources, but if you don’t have an internet connection, the links appear dead, or the content seems severely changed, you can read the content locally instead.

## 1. Decentralization

This chapter analyzes what decentralization is and why it’s essential for Bitcoin to function. We distinguish between the decentralization of miners and that of full nodes, and discuss what they bring to the table for censorship resistance, one of Bitcoin’s most central properties. The discussion then shifts to understanding neutrality - or permissionlessness towards users, miners, and developers - which is a necessary property of any decentralized system. Lastly, we touch upon how hard it can be to grasp a decentralized system like Bitcoin, and present some mental models that might help you grok it.

A system without any central point of control is referred to as being decentralized. Bitcoin is designed to avoid having a central point of control, or more precisely a central point of censorship. Decentralization is a means to achieve censorship resistance.

There are two major aspects of decentralization in Bitcoin: miner decentralization and full node decentralization. Miner decentralization refers to the fact that transaction processing isn’t performed nor coordinated by any central entity. Full node decentralization refers to the fact that validation of the blocks, i.e. the data that miners output, gets done at the edge of the network, ultimately by its users, and not by a few trusted authorities.

### 1.1. Miner decentralization

There had been attempts at creating digital currencies before Bitcoin, but most of them failed due to a lack of governance decentralization and censorship resistance.

Miner decentralization in Bitcoin means that the ordering of transactions isn’t carried out by any single entity or fixed set of entities. It’s carried out collectively by all the actors who want to participate in it; this miners' collective is a dynamic set of users. Anyone can join or leave as they wish. This property makes Bitcoin censorship-resistant.

If Bitcoin were centralized, it would be vulnerable to those who wished to censor it, such as governments. It would meet the same fate as earlier attempts to create digital money. In the introduction of a paper titled “Enabling Blockchain Innovations with Pegged Sidechains”, the authors explain how early versions of digital money weren’t equipped for an adversarial environment:

David Chaum introduced digital cash as a research topic in 1983, in a setting with a central server that is trusted to prevent double-spending[Cha83]. To mitigate the privacy risk to individuals from this central trusted party, and to enforce fungibility, Chaum introduced the blind signature, which he used to provide a cryptographic means to prevent linking of the central server’s signatures (which represent coins), while still allowing the central server to perform double-spend prevention. The requirement for a central server became the Achilles’ heel of digital cash[Gri99]. While it is possible to distribute this single point of failure by replacing the central server’s signature with a threshold signature of several signers, it is important for auditability that the signers be distinct and identifiable. This still leaves the system vulnerable to failure, since each signer can fail, or be made to fail, one by one.

— various authors
Enabling Blockchain Innovations with Pegged Sidechains (2014)

It became clear that using a central server to order transactions was not a viable option due to the high risk of censorship. Even if one replaced the central server with a federation of a fixed set of n servers, of which at least m must approve of an ordering, there would still be difficulties. The problem would indeed shift to one where users must agree on this set of n servers as well as on how to replace malicious servers with good ones without relying on a central authority.

Let’s contemplate what could happen if Bitcoin were censorable. The censor could pressure users to identify themselves, to declare where their money is coming from or what they’re buying with it before allowing their transactions to enter the blockchain.

Also, the lack of censorship resistance would allow the censor to coerce users into adopting new system rules. For example, they could impose a change that allowed them to inflate the money supply, thereby enriching themselves. In such an event, a user verifying blocks would have three options to handle the new rules:

• Adopt: Accept the changes and adopt them into their full node.

• Reject: Refuse to adopt the changes; this leaves the user with a system that doesn’t process transactions anymore, as the censor’s blocks are now deemed invalid by the user’s full node.

• Move: Appoint a new central point of control; all of the users must figure out how to coordinate and then agree on the new central control point. If they succeed, the same issues will most likely resurface at some point in the future, considering that the system remained just as censorable as it was before.

None of these options are beneficial to the user.

Censorship resistance through decentralization is what separates Bitcoin from other money systems, but it is not an easy thing to accomplish due to the double-spending problem. This is the problem of making sure no one can spend the same coin twice, an issue that many people thought was impossible to solve in a decentralized fashion. Satoshi Nakamoto write in his Bitcoin whitepaper about how to solve the double-spending problem:

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.

— Satoshi Nakamoto
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)

Here he uses the peculiar-sounding phrase “peer-to-peer distributed timestamp server”. The keyword here is distributed, which in this context means that there is no central point of control. Nakamoto then goes on to explain how proof-of-work is the solution. Still, no one explains it better than Gregory Maxwell on Reddit, where he responds to someone who proposes to limit miners' hash power to avoid potential 51% attacks:

A decentralized system like Bitcoin uses a public election. But you can’t just have a vote of 'people' in a decentralized system because that would require a centralized party to authorize people to vote. Instead, Bitcoin uses a vote of computing power because it’s possible to verify computing power without the help of any centralized third party.

— Gregory Maxwell
r/Bitcoin subreddit (2019)

The post explains how the decentralized Bitcoin network can come to an agreement on transaction ordering through the use of proof-of-work. He then concludes by saying that the 51% attack is not particularly worrisome, compared to people not caring about or not understanding Bitcoin’s decentralization properties.

A far bigger risk to Bitcoin is that the public using it won’t understand, won’t care, and won’t protect the decentralization properties that make it valuable over centralized alternatives in the first place.

— Gregory Maxwell
r/Bitcoin subreddit (2019)

The conclusion is an important one. If people don’t protect Bitcoin’s decentralization, which is a proxy for its censorship resistance, Bitcoin might fall victim to centralizing powers, until it’s so centralized that censorship becomes a thing. Then most, if not all, of its value proposition is gone. This brings us to the next section on full node decentralization.

### 1.2. Full node decentralization

In the paragraphs above, we’ve mostly talked about miner decentralization and how centralizating miners can allow for censorship. But there’s also another aspect of decentralization, namely full node decentralization.

The importance of full node decentralization is related to trustlessness. Suppose a user stops running their own full node due to, for example, a prohibitive increase in the cost of operation. In that case, they have to interact with the Bitcoin network in some other way, possibly by using web wallets or lightweight wallets, which requires a certain level of trust in the providers of these services. The user goes from directly enforcing the network consensus rules to trusting that someone else will. Now suppose that most users delegate consensus enforcement to a trusted entity. In that case, the network can quickly spiral into centralization, and the network rules can be changed by conspiring malicious actors.

In a Bitcoin Magazine article, Aaron van Wirdum interviews Bitcoin developers about their views on decentralization and the risks involved in increasing Bitcoin’s maximum block size. This discussion was a hot topic during the 2014-2017 era, when many people argued over increasing the block size limit to allow for more transaction throughput.

A powerful argument against increasing the block size is that it increases the cost of verification (see the Scaling chapter). If verification cost rises, it will push some users to stop running their full nodes. This, in turn, will lead to more people not being able to use the system in a trustless way. Pieter Wuille is quoted in the article, where he explains the risks of full node centralization.

If lots companies run a full node, it means they all need to be convinced to implement a different rule set. In other words: the decentralization of block validation is what gives consensus rules their weight. But if full node count would drop very low, for instance because everyone uses the same web-wallets, exchanges and SPV or mobile wallets, regulation could become a reality. And if authorities can regulate the consensus rules, it means they can change anything that makes Bitcoin Bitcoin. Even the 21 million bitcoin limit.

— Pieter Wuille
The Decentralist Perspective or Why Bitcoin Might Need Small Blocks (2015)

There you go. Bitcoin users should run their own full nodes to deter regulators and big corporations from trying to change the consensus rules.

### 1.3. Neutrality

Bitcoin is neutral, or permissionless, as people like to call it. This means that Bitcoin doesn’t care who you are or what you use it for.

bitcoin is neutral, which is a good thing, and the only way it can work. if it was controlled by an organisation it’d just be another virtual object type and I would have zero interest in it

— wumpus on freenode IRC (punctuation added)
#bitcoin-core-dev 2012-04-04T17:34:04 UTC

As long as you play by the rules, you’re free to use it as you please, without asking anyone for permission. This includes mining, transacting in, and building protocols and services on top of Bitcoin.

• If mining were a permissioned process, we would need a central authority to select who’s allowed to mine. This would most likely lead to miners having to sign legal contracts in which they would agree to censor transactions according to the whims of the central authority, which defeats the purpose of mining in the first place.

• If people transacting in Bitcoin had to provide personal information, declare what their transactions were for, or otherwise prove that they were worthy of transacting, we would also need a central point of authority to approve users or transactions. Again, this would lead to censorship and exclusion.

• If developers had to ask for permission to build protocols on top of Bitcoin, only the protocols allowed by the central developer granting committee would get developed. This would, due to government intervention, inevitably exclude all privacy-preserving protocols and all attempts at improving decentralization.

At all levels, trying to impose restrictions on who gets to use Bitcoin for what will hurt Bitcoin to the point where it’s no longer living up to its value proposition.

Pieter Wuille answers a question on Stack Exchange about how the blockchain relates to normal databases. He explains how permissionlessness is achievable through the use of proof-of-work in combination with economic incentives. He concludes:

Using trustless consensus algorithms like PoW does add something no other construction gives you (permissionless participation, meaning there is no set group of participants that can censor your changes), but comes at a high cost, and its economic assumptions make it pretty much only useful for systems that define their own cryptocurrency. There is probably only place in the world for one or a few actually used ones of these.

— Pieter Wuille
Stack Exchange (2019)

He explains that, in order to achieve permissionlessness, the system most likely needs its own currency, thereby “limiting the use cases to effectively just cryptocurrencies”. This is because permissionless participation, or mining, requires economic incentives built into the system itself.

### 1.4. Grokking decentralization

A compelling aspect of Bitcoin is how hard it is to grasp that no one controls it. There are no committees or executives in Bitcoin. Gregory Maxwell, again on the Bitcoin subreddit, compares this to the English language in an intriguing way:

Many people have a hard time understanding autonomous systems, there are many in their lives things like the english language-- but people just take them for granted and don’t even think of them as systems. They’re stuck in a centralized way of thinking where everything they think of as a 'thing' has an authority that controls it.

Bitcoin doesn’t focus on anything. Various people who have adopted Bitcoin chose of their own free will to promote it, and how they choose to do so is their own business. Authority fixated people may see these activities and believe they’re some operation by the bitcoin authority, but no such authority exists.

— Gregory Maxwell
r/Bitcoin subreddit (2022)
Figure 1. Fish schools have no leaders.

The way Bitcoin works through decentralization resembles the extraordinary collective intelligence found among many species in nature. Computer scientist Radhika Nagpal speaks in a Ted talk about the collective behavior of fish schools and how scientists are trying to mimic it using robots.

Secondly, and the thing that I still find most remarkable, is that we know that there are no leaders supervising this fish school. Instead, this incredible collective mind behavior is emerging purely from the interactions of one fish and another. Somehow, there are these interactions or rules of engagement between neighboring fish that make it all work out.

What intelligent machines can learn from a school of fish (2017)

She points out that many systems, either natural or artificial, can and do work without leaders, and they are powerful and resilient. Each individual only interacts with their immediate surroundings, but together they form something tremendous.

No matter what you think about Bitcoin, its decentralized nature makes it difficult to control. Bitcoin exists, and there’s nothing you can do about it. It’s something to be studied, not debated.

## 2. Trustlessness

This chapter dissects the concept of trustlessness, what it means from a computer science perspective, and why Bitcoin has to be trustless to retain its value proposition. We then talk about what it means to use Bitcoin in a trustless way, and what kind of guarantees a full node can and cannot give you. In the last section, we look at the real-world interaction between Bitcoin and actual softwares or users, and the need to make trade-offs between convenience and trustlessness to get anything done at all.

People often say things like "Bitcoin is great because it’s trustless". What do they mean by trustless? Pieter Wuille explains this widely used term on Stack Exchange:

The trust we’re talking about in "trustless" is an abstract technical term. A distributed system is called trustless when it does not require any trusted parties to function correctly.

— Pieter Wuille
Bitcoin Stack Exchange (2016)

In short, the word trustless refers to a property of the Bitcoin protocol whereby it can logically function without "any trusted parties". This is different from the trust you inevitably have to put into the software or hardware you run. More on this latter aspect of trust will be discussed further in this chapter.

In centralized systems, we rely on a central actor’s reputation in order to make sure that they will take care of security or roll back in case of issues, as well as on the legal system to sanction any violations. These trust requirements are problematic in pseudonymous decentralized systems - there is no possibility of recourse so there really can’t be any trust. In the introduction to the Bitcoin whitepaper, Satoshi Nakamoto describes this problem:

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party

— Satoshi Nakamoto
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)

It seems that we can’t have a decentralized system based on trust, and that’s why trustlessness is important in Bitcoin.

To use Bitcoin in a trustless manner, you have to run a fully-validating Bitcoin node. Only then will you be able to verify that the blocks you receive from others are following the consensus rules; for example, that the coin issuance schedule is kept and that no double-spends occur on the blockchain. If you don’t run a full node, you outsource verification of Bitcoin blocks to someone else and trust them to tell you the truth, which means you’re not using Bitcoin trustlessly.

David Harding has authored an article on the bitcoin.org website explaining how running a full node - or using Bitcoin trustlessly - actually helps you.

The bitcoin currency only works when people accept bitcoins in exchange for other valuable things. That means it’s the people accepting bitcoins who give it value and who get to decide how Bitcoin should work.

When you accept bitcoins, you have the power to enforce Bitcoin’s rules, such as preventing confiscation of any person’s bitcoins without access to that person’s private keys.

Unfortunately, many users outsource their enforcement power. This leaves Bitcoin’s decentralization in a weakened state where a handful of miners can collude with a handful of banks and free services to change Bitcoin’s rules for all those non-verifying users who outsourced their power.

Unlike other wallets, Bitcoin Core does enforce the rules—so if the miners and banks change the rules for their non-verifying users, those users will be unable to pay full validation Bitcoin Core users like you.

— David Harding
Full Validation on bitcoin.org (2015)

He says that running a full node will help you verify every aspect of the blockchain without trusting anyone else, so as to ensure that the coins you receive from others are genuine. This is great, but there’s one important thing that a full node can’t help you with: it can’t prevent double- spending through chain rewrites:

Note that although all programs—including Bitcoin Core—are vulnerable to chain rewrites, Bitcoin provides a defense mechanism: the more confirmations your transactions have, the safer you are. There is no known decentralized defense better than that.

— David Harding
Full Validation on bitcoin.org (2015)

No matter how advanced your software is, you still have to trust that the blocks containing your coins won’t be rewritten. However, as pointed out by Harding, you can await a number of confirmations, after which you consider the probability of a chain rewrite small enough to be acceptable.

The incentives for using Bitcoin in a trustless way align with the system’s need for full node decentralization. The more people who use their own full nodes, the more full node decentralization, and thus the stronger Bitcoin stands against malicious changes to the protocol. But unfortunately, as explained in the full node decentralization section, users often opt for trusted services as consequence of the inevitable trade-off between trustlessness and convenience.

Bitcoin’s trustlessness is absolutely imperative from a system perspective. In 2018, Matt Corallo, spoke about trustlessness at the Baltic Honeybadger conference in Riga. The essence of that talk is that you can’t build trustless systems on top of a trusted system, but you can build trusted systems - for example, a custodial wallet - on top of a trustless system.

Figure 2. A trustless base layer allows for various trade-offs on higher levels.

This security model allows the system designer to select trade-offs that make sense to them without forcing those trade-offs on others.

### 2.1. Don’t trust, verify

Bitcoin works trustlessly, but you still have to trust your software and hardware to some degree. That’s because your software or hardware might not be programmed to do what’s stated on the box. For example:

• The CPU might be maliciously designed to detect private key cryptographic operations and leak the private key data.

• The operating system’s random number generator might not be as random as it claims.

• Bitcoin Core might have sneaked in code that will send your private keys to some bad actor.

So, besides running a full node, you also need to make sure you’re running what you intend to. Reddit user brianddk wrote an article about the various levels of trust you can choose from, when verifying your software. In the section "Trusting the builders", he talks about reproducible builds:

Reproducible builds are a way to design software so that many community developers can each build the software and ensure that the final installer built is identical to what other developers produce. With a very public, reproducible project like bitcoin, no single developer needs to be completely trusted. Many developers can all perform the build and attest that they produced the same file as the one the original builder digitally signed.

— brianddk on Reddit
Bitcoin v22.0 and Guix; Stronger defense against the "Trusting Trust Attack" (2022)

The article defines 5 levels of trust: trusting the site, the builders, the compiler, the kernel, and the hardware.

To further deepen the topic of reproducible builds, Carl Dong made a presentation about Guix (video) explaining why trusting the operating system, libraries, and compilers can be problematic, and how to fix that with a system called Guix, which is used by Bitcoin Core today.

So what can we do about the fact that our toolchain can have a bunch of trusted binaries that can be reproducibly malicious? We need to be more than reproducible. We need to be bootstrappable. We cannot have that many binary tools that we need to download and trust from external servers controlled by other organizations. We should know how these tools are built and exactly how we can go through the process of building them again, preferably from a much smaller set of trusted binaries. We need to minimize our trusted set of binaries as much as possible, and have an easily auditable path from those toolchains to what we use how to build bitcoin. This allows us to maximize verification and minimize trust.

— Carl Dong on Guix
Breaking Bitcoin Conference (2019)

He then explains how Guix allows us to only trust a minimal binary of 357 bytes that can be verified and fully understood if you know how to interpret the instructions. This is quite remarkable: one verifies that the 357-byte binary does what it should, then uses it to build the full build system from source code, and ends up with a Bitcoin Core binary that should be an exact copy of anyone else’s build.

There’s a mantra that many bitcoiners subscribe to, which captures well much of the above:

Don’t trust, verify.

— Bitcoiners everywhere

This alludes to the phrase "trust, but verify" that former U.S. president Ronald Reagan used in the context of nuclear disarmament. Bitcoiners switched it around to highlight the rejection of trust and the importance of running a full node.

It’s up to the users to decide to what degree they want to verify the software they use and the blockchain data they receive. As with so many other things in Bitcoin, there’s a trade-off between convenience and trustlessness. It’s almost always more convenient to use a custodial wallet compared to running Bitcoin Core on your own hardware. However, as Bitcoin software is maturing and user interfaces are improving, over time it should get better at supporting users willing to work towards trustlessness. Also, as users gain more knowledge over time, they should be able to gradually remove trust from the equation.

Some users think adversarially and verify most aspects of the software they run. As a consequence, they reduce the need for trust to the bare minimum, as they only need to trust their computer hardware and operating system. In doing so, they also help people who don’t verify their hardware as thoroughly by raising their voices in public to warn about any issues they might find. One good example of this is an event that occurred in 2018, when someone discovered a bug that would allow miners to spend an output twice in the same transaction:

CVE-2018-17144, a fix for which was released on September 18th in Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of Service component and a critical inflation vulnerability. It was originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited on September 17th as a Denial of Service bug only, however we quickly determined that the issue was also an inflation vulnerability with the same root cause and fix.

— CVE-2018-17144 Full Disclosure on bitcoincore.org (2018)

Here, an anonymous person reported an issue that turned out much worse than the reporter realized. This highlights the fact that people who verify the code often report security flaws instead of exploiting them. This is beneficial to those who aren’t able to verify everything themselves. However, users should not trust others to keep them safe, but should rather verify for themselves whenever and whatever they can; that’s how one remains as sovereign as possible, and how Bitcoin prospers. The more eyes on the software, the less likely it is that malicious code and security flaws slip through.

## 3. Privacy

This chapter deals with how to keep your private financial information to yourself. It explains what privacy stands for in the context of Bitcoin, why it’s important, and what it means to say that Bitcoin is pseudonymous. It also looks into how private data can leak, both on-chain and off-chain. Then, it talks about the fact that bitcoins should be fungible, meaning interchangeable for any other bitcoins, and how fungibility and privacy go hand in hand. Lastly, the chapter introduces some measures you can take to improve your privacy and that of others.

Bitcoin can be described as a pseudonymous system (see Section 3.3 for further details on this), where users have multiple pseudonyms in the form of public keys. At first glance, this looks like a pretty good way to protect users from being identified, but it is in fact really easy to leak private financial information unintentionally.

### 3.1. What does privacy mean?

Privacy can mean different things in different contexts. In Bitcoin, it generally means that users don’t have to reveal their financial information to others, unless they voluntarily do so.

There are many ways in which you may leak your private information to others, with or without knowing it. Data can either leak from the public blockchain or through other means, for example when malicious actors intercept your internet communications.

### 3.2. Why is privacy important?

It may seem obvious why privacy is important in Bitcoin, but there are some aspects of it that one might not immediately think about. On the Bitcoin Talk forum, Gregory Maxwell walks us through a lot of good reasons why he thinks privacy matters. Among them are free market, safety, and human dignity:

Financial privacy is essential for personal safety: if thieves can see your spending, income, and holdings, they can use that information to target and exploit you. Without privacy malicious parties have more ability to steal your identity, snatch your large purchases off your doorstep, or impersonate businesses you transact with towards you…​ they can tell exactly how much to try to scam you for.

Financial privacy is essential for human dignity: no one wants the snotty barista at the coffee shop or their nosy neighbors commenting on their income or spending habits. No one wants their baby-crazy in-laws asking why they’re buying contraception (or sex toys). Your employer has no business knowing what church you donate to. Only in a perfectly enlightened discrimination free world where no one has undue authority over anyone else could we retain our dignity and make our lawful transactions freely without self-censorship if we don’t have privacy.

— Gregory Maxwell
Bitcoin Talk forum (2013)

Maxwell also touches on fungibility, which will be discussed later in this chapter, as well as on how privacy and law enforcement are not contradictory.

### 3.3. Pseudonymity

We mentioned above that Bitcoin is pseudonymous, and that the pseudonyms are public keys. In the media you often hear that Bitcoin is anonymous, which is not correct. There is a distinction between anonymity and pseudonymity.

Andrew Poelstra explains in a Bitcoin Stack Exchange post what anonymity would look like in transactions:

Total anonymity, in the sense that when you spend money there is no trace of where it came from or where it’s going, is theoretically possible by using the cryptographic technique of zero-knowledge proofs.

— Andrew Poelstra on anonymity
Bitcoin Stack Exchange (2016)

The difference seems to be that in a pseudonymous form of money you can trace payments between pseudonyms, whereas in an anonymous form of money you can’t. Since bitcoin payments are traceable between pseudonyms, it’s not an anonymous system.

We have also said that the pseudonyms are public keys, but it’s actually addresses derived from public keys. Why do we use addresses as pseudonyms and not something else, for example some descriptive names, like “watchme1984”? This has been explained well by user Tim S., also on Bitcoin Stack Exchange:

In order for Bitcoin’s idea to work, you must have coins that can only be spent by the owner of a given private key. This means that whatever you send to must be tied, in some way, to a public key.

Using arbitrary pseudonyms (e.g. user names) would mean that you’d have to then somehow link the pseudonym to a public key in order to enable public/private key crypto. This would remove the ability to securely create addresses/pseudonyms offline (e.g. before someone could send money to the user name "tdumidu", you’d have to announce in the blockchain that "tdumidu" is owned by public key "a1c…​", and include a fee so others have a reason to announce it), reduce anonymity (by encouraging you to reuse pseudonyms), and needlessly bloat the size of the blockchain. It would also create a false sense of security that you’re sending to who you think you are (if I take the name "Linus Torvalds" before he does, then it’s mine and people might send money thinking they’re paying the creator of Linux, not me).

— Tim S. on pseudonyms
Bitcoin Stack Exchange (2014)

By using addresses, or public keys, we achieve important goals, such as removing the need to somehow register a pseudonym beforehand, reducing the incentives for pseudonym reuse, avoiding blockchain bloat, and making it harder to impersonate other people.

### 3.4. Blockchain privacy

Blockchain privacy refers to the information you disclose by transacting on the blockchain. It applies to all transactions, the ones you send as well as the ones you receive.

Satoshi Nakamoto ponders over on-chain privacy in section 7 of his Bitcoin whitepaper:

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.

— Satoshi Nakamoto
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)

The paper summarizes the main problems of blockchain privacy, namely address reuse and address clustering. The first is self-explaining, the latter refers to the ability to decide, with some level of certainty, that a set of different addresses belongs to the same user.

Figure 3. Typical privacy leaks on the blockchain.

Chris Belcher wrote in great detail about the different kinds of privacy leaks that can happen on the Bitcoin blockchain. We recommend you read at least the first few subsections under "Blockchain attacks on privacy."

The takeaway is that privacy in Bitcoin isn’t perfect. It requires a significant amount of work to transact privately. Most people aren’t prepared to go that far for privacy. There seems to be a clear trade-off between privacy and usability.

Another important aspect of privacy is that the measures you take to protect your own privacy affect other users as well. If you are sloppy with your own privacy, other people might experience reduced privacy, too. Gregory Maxwell explains this very plainly on the same Bitcoin Talk discussion that we linked above, and concludes with an example:

This actually works in practice, too…​ A nice whitehat hacker on IRC was playing around with brainwallet cracking and hit a phrase with ~250 BTC in it. We were able to identify the owner from just the address alone, because they’d been paid by a Bitcoin service that reused addresses and he was able to talk them into giving up the users contact information. He actually got the user on the phone, they were shocked and confused— but grateful to not be out their coin. A happy ending there. (This isn’t the only example of it, by far …​ but its one of the more fun ones).

— Gregory Maxwell
Bitcoin Talk forum (2013)

In this case, it all went well thanks to the philanthropically-minded hacker, but don’t count on that next time.

### 3.5. Non-blockchain privacy

While the blockchain proves to be a notorious source of privacy leaks, there are plenty of other leaks that don’t use the blockchain, some sneakier than others. These range from key-loggers to network traffic analysis. To read up on some of these methods, please refer again to Chris Belcher’s piece, specifically the section "Non-blockchain attacks on privacy".

Among a plethora of attacks, Belcher mentions the possibility of someone snooping on your internet connection, for example, your ISP:

If the adversary sees a transaction or block coming out of your node which did not previously enter, then it can know with near-certainty that the transaction was made by you or the block was mined by you. As internet connections are involved, the adversary will be able to link the IP address with the discovered bitcoin information.

— Chris Belcher
Bitcoin wiki

However, among the most obvious privacy leaks are exchanges. Due to laws, usually referred to as KYC (Know Your Customer) and AML (Anti-Money Laundering), that are valid in the jurisdictions they operate in, exchanges and related companies often have to collect personal data about their users, building up big databases about which users own which bitcoins. These databases are great honeypots for evil governments and criminals who are always on the lookout for new victims. There are actual markets for this kind of data, where hackers sell data to the highest bidder. To make things worse, the companies that manage these databases often have little experience with protecting financial data, in fact many of them are young start-ups, and we know for a fact that several leaks have already occurred. A few examples are India-based MobiQwik and HubSpot

Again, protecting data against this wide range of attacks is hard, and it is likely that you won’t be fully able to do so. You’ll have to opt for the trade-off between convenience and privacy that works best for you.

### 3.6. Fungibility

Fungibility, in the context of currencies, means that one coin is interchangeable for any other coin of the same currency. This funny word was briefly touched upon in Section 3.2. In the article discussed there, Gregory Maxwell stated

Financial privacy is an essential element to fungibility in Bitcoin: if you can meaningfully distinguish one coin from another, then their fungibility is weak. If our fungibility is too weak in practice, then we cannot be decentralized: if someone important announces a list of stolen coins they won’t accept coins derived from, you must carefully check coins you accept against that list and return the ones that fail. Everyone gets stuck checking blacklists issued by various authorities because in that world we’d all not like to get stuck with bad coins. This adds friction and transactional costs and makes Bitcoin less valuable as a money.

— Gregory Maxwell
Bitcoin Talk forum (2013)

Here, he speaks about the dangers derived from a lack of fungibility. Suppose that you have a UTXO. That UTXO’s history can normally be traced back several hops, fanning out to multitudes of previous outputs. If any of those outputs were involved in any illegal, unwanted, or suspicious activity, then some potential recipients of your coin might reject it. If you think that your payees will verify your coins against some centralized whitelist or blacklist service, you might start checking the coins you receive too, just to be on the safe side. The result is that bad fungibility will bolster even worse fungibility.

Adam Back and Matt Corallo gave a presentation about fungibility at Scaling Bitcoin in Milan in 2016. They were thinking along the same lines:

You need fungibility for bitcoin to function. If you receive coins and can’t spend them, then you start to doubt whether you can spend them. If there are doubts about coins you receive, then people are going to go to taint services and check whether “are these coins blessed” and then people are going to refuse to trade. What this does is it transitions bitcoin from a decentralized permissionless system into a centralized permissioned system where you have an “IOU” from the blacklist providers.

— Matt Corallo and Adam Back
Fungibility Overview (2016)

It seems that privacy and fungibility go hand-in-hand. Fungibility will weaken if privacy is weak, for example as coins from unwanted people may become blacklisted. In the same way, privacy will weaken if fungibility is weak: if there is a blacklist, you will have to ask the blacklist providers about which coins to accept, thereby possibly revealing your IP address, email address, and other sensitive information. These two features are so intertwined that it’s hard to talk about either of them in isolation.

### 3.7. Privacy measures

Several techniques have been developed to help people protecting themselves from privacy leaks. Among the most obvious ones is, as noted by Nakamoto above, using unique addresses for every transaction, but several others exist. We’re not going to teach you how to become a privacy ninja. However, Bitcoin Q+A has a quick summary of privacy-enhancing technologies, somewhat ordered by how hard they are to implement, at https://bitcoiner.guide/privacytips/. When you read it, you’ll notice that Bitcoin privacy often has to do with stuff outside of Bitcoin. For example, you shouldn’t brag about your bitcoins, and you should use Tor and VPN. The post also lists some measures directly related to Bitcoin:

Full node

If you don’t use your own full node, you will leak lots of information about your wallet to servers on the internet. Running a full node is a great first step.

Lightning Network

Several protocols exist on top of Bitcoin, for example the Lightning Network and Blockstream’s Liquid sidechain.

CoinJoin

A way for multiple people to merge their transactions into one, making it harder to do chain analysis.

In a talk at the Breaking Bitcoin conference, Chris Belcher gave an interesting practical example of how privacy has been improved.

They were a bitcoin casino. Online gambling is not allowed in the US. Any customers of Coinbase that deposited straight to Bustabit would have their accounts shutdown because Coinbase was monitoring for this. Bustabit did a few things. They did something called change avoidance where you go through– and you see if you can construct a transaction that has no change output. This saves miner fees and also hinders analysis. Also, they imported their heavily-used reused deposit addresses into joinmarket. At this point, coinbase.com customers never got banned. It seems Coinbase’s surveillance service was unable to do the analysis after this, so it is possible to break these algorithms.

— Chris Belcher in "Breaking Bitcoin Privacy"
Breaking Bitcoin conference (2019)

He also mentioned this example, among others, on the Privacy page on the Bitcoin wiki.

Note how better privacy can be achieved by building systems on top of Bitcoin, as is the case with Lightning Network:

Figure 4. Layers on top of Bitcoin can add privacy.

We noted in Trustlessness that the need for trust can only increase with layers on top, but that doesn’t seem to be the case for privacy, which can be improved or made worse arbitrarily in layers on top. Why is that? Any layer on top of Bitcoin, as explained in Section 8.2.4, must use on-chain transactions occasionally, otherwise it wouldn’t be "on top of Bitcoin". Privacy-enhancing layers generally try to use the base layer as little as possible to minimize the amount of information revealed.

The above are somewhat technical ways to improve your privacy. But there are other ways. At the beginning of this chapter, we said that Bitcoin is a pseudonymous system. This means that users in Bitcoin aren’t known by their real names or other personal data, but by their public keys. A public key is a pseudonym for a user, and a user can have multiple pseudonyms. In an ideal world, your in-person identity is decoupled from your Bitcoin pseudonyms. Unfortunately, due to the privacy problems described in this chapter, this decoupling usually degrades over time.

To mitigate the risks of having your personal data revealed is to not give it out in the first place nor to give it to centralized services, which build big databases that can leak (see Section 3.5). An article by Bitcoin Q+A explains KYC and the dangers derived from it. It also suggests some steps you can take to improve your situation.

Thankfully there are some options out there to purchase Bitcoin via no KYC sources. These are all P2P (peer to peer) exchanges where you are trading directly with another individual and not a centralised third party. Unfortunately some sell other coins as well as bitcoin so we urge you to take care.

— Bitcoin Q+A, noKYC only, Avoid the creep
bitcoiner.guide

The article suggests you avoid using exchanges that require KYC/AML and instead trade in private, or use decentralized exchanges like bisq.

For more in-depth reading about countermeasures, refer to the previously mentioned wiki article on privacy, starting at "Methods for improving privacy (non-blockchain)".

### 3.8. Conclusion

Privacy is very important but hard to achieve. There is no privacy silver bullet. To get decent privacy in Bitcoin, you have to take active measures, some of which are costly and time-consuming.

## 4. Finite supply

This chapter looks into the bitcoin supply limit of 21 million BTC, or how much is it actually? We talk about how this limit is enforced and what one can do to verify that it’s being respected. Moreover, we take a peek into the crystal ball and discuss the dynamics that will come into play when the block reward shifts from subsidy-based to fee-based.

The well-known finite supply of 21 million BTC is regarded as a fundamental property of Bitcoin. But is it really set in stone?

Let’s start by looking at what the current consensus rules say about the supply of bitcoin, and how much of it will actually be usable. Pieter Wuille wrote a piece about this on Stack Exchange, in which he counted how many bitcoins there would be once all coins are mined:

If you sum all these numbers together, you get 20999999.9769 BTC.

— Pieter Wuille
Stack Exchange (2015)

But due to a number of reasons — such as early problems with coinbase transactions, miners who unintentionally claim less than allowed, and loss of private keys — that upper limit will never be reached. Wuille concludes:

This leaves us with 20999817.31308491 BTC (taking everything up to block 528333 into account)

... However, various wallets have been lost or stolen, transactions have been sent to the wrong address, people forgot they owned bitcoin. The totals of this may well be millions. People have tried to tally known losses up here.

This leaves us with: ??? BTC.

— Pieter Wuille
Stack Exchange (2015)

We can thus be sure that the bitcoin supply will be 20999817.31308491 BTC at most. Any lost or unverifiably burnt coins will make this number lower, but we don’t know by how much. The interesting thing is that it doesn’t really matter, or better yet it does matter in a positive way for bitcoin holders, as explained by Satoshi Nakamoto:

Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone.

— Satoshi Nakamoto on lost bitcoins
Bitcointalk forum (2010)

The finite supply will shrink and this should, at least in theory, cause price deflation.

More important than the exact number of coins in circulation is the way the supply limit is enforced without any central authority. Alias chytrik puts it well on Stack Exchange.

So the answer is that you don’t have to trust someone to not increase the supply. You just have to run some code that will verify that they haven’t.

— chytrik
Stack Exchange (2021)

Even if some full nodes turn to the dark side and decide to accept blocks with higher-value coinbase transactions, all the remaining full nodes will simply neglect them and continue doing business as usual. Some full nodes may, intentionally or unintentionally (see Section 9.2.2), run evil softwares, yet the collective will robustly secure the blockchain. In conclusion, you can choose to trust the system without having to trust anyone.

### 4.1. Block subsidy and transaction fees

A block reward is composed of the block subsidy plus transaction fees. The block reward needs to cover Bitcoin’s security costs. We can say for sure that under today’s conditions with regard to block subsidy, transaction fees, bitcoin price, mempool size, hash power, degree of decentralization etc., the incentives for every player to play by the rules are high enough to preserve a secure monetary system.

What happens when the block subsidy approaches zero? To keep things simple, let’s assume it actually equals zero. At this point, the system’s security cost is covered through transaction fees only. What the future holds for us when this happens, we cannot know. The uncertainty factors are numerous and we are left to speculations. For example, Paul Sztorc’s contribution to the subject in his Truthcoin blog is mostly speculations, but he has at least one solid point (please note that M2, as referred to by Sztorc, is a measurement of a fiat money supply):

While the two are mixed into the same “security budget”, the block subsidy and txn-fees are utterly and completely different. They are as different from each other, as “VISA’s total profits in 2017” are from the “total increase in M2 in 2017”.

— Paul Sztorc, Security Budget in the Long Run
Truthcoin blog (2019)

Today, it is holders who pay for security (via monetary inflation). Tomorrow it will be the spenders' turn to somehow shoulder this burden, as illustrated below.

Figure 5. As time goes by, the bearing of security costs will shift from holders to spenders.

When transaction fees are the main motivation for mining, the incentives shift. Most notably, if the mempool of a miner doesn’t contain enough transaction fees, it might become more profitable for that miner to rewrite Bitcoin’s history rather than extending it. Bitcoin Optech has a specific section on this behavior, called fee sniping, written by David Harding:

Fee sniping is a problem that may occur as Bitcoin’s subsidy continues to diminish and transaction fees begin to dominate Bitcoin’s block rewards. If transaction fees are all that matter, then a miner with `x` percent of the hash rate has a `x` percent chance of mining the next block, so the expected value to them of honestly mining is `x` percent of the best feerate set of transactions in their mempool.

Alternatively, a miner could dishonestly attempt to re-mine the previous block plus a wholly new block to extend the chain. This behavior is referred to as fee sniping, and the dishonest miner’s chance of succeeding at it if every other miner is honest is `(x/(1-x))^2`. Even though fee sniping has an overall lower probability of success than honest mining, attempting dishonest mining could be the more profitable choice if transactions in the previous block paid significantly higher feerates than the transactions currently in the mempool—a small chance at a large amount can be worth more than a large chance at a small amount.

— David Harding, fee sniping
Bitcoin Optech website

Throwing a wet blanket over our hopes for the future is the fact that if miners start conducting fee sniping, this will incentivize others to do the same, leaving even fewer honest miners. This could severely impair the overall security of Bitcoin. Harding goes on to list a few countermeasures that can be taken, such as relying on transaction time locks to restrict where in the blockchain the transaction may appear.

So, given that the consensus on finite supply remains, the block subsidy will - thanks to BIP42 which fixed a very-long-term inflation bug - get to zero around year 2140. Will the transaction fees thereafter be enough to secure the network? It’s impossible to say, but we do know a few things:

• A century is a long time from the Bitcoin perspective. If it is still around, it will have probably evolved enormously.

• If an overwhelming economic majority finds it necessary to change the rules and introduce for example a perpetual annual 0.1% or 1% monetary inflation, the supply of bitcoin will no longer be finite.

• With zero block subsidy and an empty or nearly empty mempool, things can become shaky due to fee sniping.

Since the transition to a fee-only block reward is so far in the future, it might be wise not to jump to conclusions and try to fix the potential issues while we can. For example, Peter Todd thinks there’s an actual risk that Bitcoin’s security budget won’t be enough in the future, and consequently argues for a small perpetual inflation in Bitcoin. However, he also thinks it’s not a good idea to discuss such an issue at this time, as he said on the What Bitcoin Did podcast:

But, that’s a risk like 10, 20 years in the future. That is a very long time. And, by then, who the hell knows what the risks are?

— Peter Todd on security budget
What Bitcoin Did podcast (2019)

Perhaps we could think of Bitcoin as something organic. Imagine a small, slowly-growing oak plant. Imagine also that you have never seen a fully grown tree in your life. Wouldn’t it be wise then to restrain your control issues instead of setting in advance all the rules on how this plant should be allowed to evolve and grow?

### 4.2. Conclusion

Whether the bitcoin supply will grow past 21 million we cannot say today, and that is probably not so bad. Ensuring that the security budget remains high enough is crucial but not urgent. Let’s have this discussion in 10-50 years, when we know more. If it’s still relevant.

Upgrading Bitcoin in a safe way can be extremely difficult. Some changes take several years to roll out. In this chapter, we learn about the common vocabulary around upgrading Bitcoin, and explore some examples of historic upgrades to its protocol as well as the insights that we gained from them. Finally, we talk about chain splits and the risks and costs related to them.

To get in tune for this chapter, you should read David Harding’s piece on harmony and discord.

Bitcoin experts talk often of consensus, whose meaning is abstract and hard to pin down. But the word consensus evolved from the Latin word concentus, "a singing together, harmony,"[1] so let us talk not of Bitcoin consensus but of Bitcoin harmony.

Harmony is what makes Bitcoin work. Thousands of full nodes each work independently to verify the transactions they receive are valid, producing a harmonious agreement about the state of the Bitcoin ledger without any node operator needing to trust anyone else. It’s similar to a chorus where each member sings the same song at the same time to produce something far more beautiful than any of them could produce alone.

The result of Bitcoin harmony is a system where bitcoins are safe not just from petty thieves (provided you keep your keys secure) but also from endless inflation, mass or targeted confiscation, or simply the bureaucratic morass that is the legacy financial system.

— David Harding
Harmony and Discord

This chapter discusses how Bitcoin can be upgraded without causing discord. Staying in harmony, i.e. maintaining consensus, is indeed one of the biggest challenges in Bitcoin development. There are lots of nuances to upgrade mechanisms, which might be best understood by studying actual cases of previous upgrades. For this reason, the chapter puts much focus on historic examples, and it starts by setting the stage with some useful vocabulary.

### 5.1. Vocabulary

According to Wikipedia, forward compatibility refers to the condition in which an old software can process data created by newer softwares, ignoring the parts it doesn’t understand.

A standard supports forward compatibility if a product that complies with earlier versions can "gracefully" process input designed for later versions of the standard, ignoring new parts which it does not understand.

— Forward compatibility
Wikipedia

Vice versa, backward compatibility refers to when data from an old software is usable on newer softwares. A change is said to be fully compatible if it’s both forward and backward compatible.

A change to the Bitcoin consensus rules is said to be a soft fork if it is fully compatible. This is the most common way to upgrade Bitcoin, for a number of reasons that we’ll discuss further in this chapter. If a change to the Bitcoin consensus rules is backward compatible but not forward compatible, it is called a hard fork.

For a technical overview of soft forks and hard forks, please read chapter 11 of Grokking Bitcoin. It explains these terms and also dives into the upgrade mechanisms. It’s recommended, although not strictly necessary, to get a grip on this before you continue reading.

Bitcoin is not the same today as it was when the genesis block was created. Several upgrades have been made throughout the years. In 2017, Eric Lombrozo spoke at the Breaking Bitcoin conference (video) about Bitcoin’s different upgrading mechanisms, pointing out how much they have evolved over time. He even explained how Satoshi Nakamoto once upgraded Bitcoin through a hard fork.

There was actually a hard-fork in bitcoin that Satoshi did that we would never do it this way- it’s a pretty bad way to do it. If you look at the git commit description here [757f076], he says something about reverted makefile.unix wx-config version 0.3.6. Right. That’s all it says. It has no indication that it has a breaking change at all. He was basically hiding it in there. He also posted to bitcointalk and said, please upgrade to 0.3.6 ASAP. We fixed an implementation bug where it is possible that bogus transactions can be displayed as accepted. Do not accept bitcoin payments until you upgrade to 0.3.6. If you can’t upgrade right away, then it would be best to shutdown your bitcoin node until you do. And then on top of that, I don’t know why he decided to do this as well, he decided to add some optimizations in the same code. Fix a bug and add some optimizations.

— Eric Lombrozo
Changing Consensus Rules Without Breaking Bitcoin at Breaking Bitcoin conference (2017)

He points out that, be it intentionally or not, this hard fork created opportunities for future soft forks, namely the Script operators (opcodes) OP_NOP1-OP_NOP10. We’ll look more into this code change in chapter 9. These opcodes have been used for two soft forks so far: BIP65 (OP_CHECKLOCKTIMEVERIFY), and BIP113 (OP_SEQUENCEVERIFY).

Lombrozo also provides an overview of the way upgrade mechanisms have evolved throughout the years, up until 2017. Since then, only one other major upgrade, which we analyze in Section 5.2.3, has been deployed. The long and somewhat chaotic process that led to its activation has helped us gain further insights on upgrading mechanisms in Bitcoin.

While all the upgrades preceding Segwit had been more or less painless, this one was different. When Segwit activation code was released, in October 2016, there seemed to be overwhelming support for it among Bitcoin users, but for some reason miners didn’t signal support for this upgrade, which stalled the activation with no resolution in sight.

Aaron van Wirdum describes this winding road in his Bitcoin Magazine article The Long Road To Segwit. He starts by explaining what Segwit is and how that taps into the block size debate. Van Wirdum then outlines the turn of events that led to its final activation. At the center of this process was an upgrade mechanism called user activated soft fork, or UASF for short, that was proposed by user Shaolinfry.

Shaolinfry proposed an alternative: a user activated soft fork (UASF). Instead of hash power activation, a user activated soft fork would have a “‘flag day activation’ where nodes begin enforcement at a predetermined time in the future.” As long as such a UASF is enforced by an economic majority, this should compel a majority of miners to follow (or activate) the soft fork.

— Aaron van Wirdum
The Long Road To Segwit on Bitcoin Magazine (2017)

Among other things, he cites Shaolinfry’s email to the Bitcoin-dev mailing list. In that occasion Shaolinfry argued against miner activated soft forks, listing a number of problems with them.

Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it’s likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.

— Shaolinfry
Bitcoin-dev mailing list (2017)

Shaolinfry also drew attention to a common misinterpretation of miner signaling: people generally thought that it was a means by which miners could decide upon protocol upgrades, rather than an action that helped coordinate upgrades. Due to this misunderstanding, miners might have also felt obliged to proclaim in public their views on a certain soft fork, as if that gave weight to the proposal.

The UASF proposal is, in a nutshell, a "flag day" on which nodes start enforcing specific new rules. That way, miners don’t have to make a collective effort to coordinate the upgrade, and can even trigger activation earlier than the flag day if enough blocks signal support.

My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.

— Shaolinfry
Bitcoin-dev mailing list (2017)

This idea caught a lot of interest, but didn’t seem to reach near unanimous support, which caused concern for a potential chain split. The article by Aaron van Wirdum explains how this finally got resolved thanks to BIP91, authored by James Hilliard.

Hilliard proposed a slightly complex but clever solution that would make everything compatible: Segregated Witness activation as proposed by the Bitcoin Core development team, the BIP148 UASF and the New York Agreement activation mechanism. His BIP91 could keep Bitcoin whole — at least throughout SegWit activation.

— Aaron van Wirdum
The Long Road To Segwit on Bitcoin Magazine (2017)

There were some more complicating factors involved (e.g. the so-called "New York Agreement"), that this BIP had to take into consideration. We encourage you to read Van Wirdum’s article in full to learn about the many interesting details in this story.

#### 5.2.2. Post-Segwit discussion

After the Segwit deployment, a discussion about deployment mechanisms emerged. As noted by Eric Lombrozo in his talk at the Breaking Bitcoin conference (video) and by Shaolinfry (see Section 5.2.1 above), a miner activated soft fork isn’t the ideal upgrade mechanism.

At some point we’re probably going to want to add more features to the bitcoin protocol. This is a big philosophical question we’re asking ourselves. Do we do a UASF for the next one? What about a hybrid approach? Miner activated by itself has been ruled out. bip9 we’re not going to use again.

— Eric Lombrozo
Changing Consensus Rules Without Breaking Bitcoin at Breaking Bitcoin conference (2017)

In January 2020, Matt Corallo sent an email to the Bitcoin-dev mailing list that started a discussion on future soft fork deployment mechanisms. He listed five goals that he thought were essential in an upgrade. David Harding summarizes them in a Bitcoin Optech newsletter as:

1. The ability to abort if a serious objection to the proposed consensus rules changes is encountered

2. The allocation of enough time after the release of updated software to ensure that most economic nodes are upgraded to enforce those rules

3. The expectation that the network hash rate will be roughly the same before and after the change, as well as during any transition

4. The prevention, as much as possible, of the creation of blocks that are invalid under the new rules, which could lead to false confirmations in non-upgraded nodes and SPV clients

5. The assurance that the abort mechanisms can’t be misused by griefers or partisans to withhold a widely desired upgrade with no known problems

— David Harding

What Corallo proposes is a combination of a miner activated soft fork and a user activated soft fork:

Thus, as something a bit more concrete, I think an activation method which sets the right precedent and appropriately considers the above goals, would be:

1) a standard BIP 9 deployment with a one-year time horizon for activation with 95% miner readiness,
2) in the case that no activation occurs within a year, a six month quieting period during which the community can analyze and discussion the reasons for no activation and,
3) in the case that it makes sense, a simple command-line/bitcoin.conf parameter which was supported since the original deployment release would enable users to opt into a BIP 8 deployment with a 24-month time-horizon for flag-day activation (as well as a new Bitcoin Core release enabling the flag universally).

This provides a very long time horizon for more standard activation, while still ensuring the goals in #5 are met, even if, in those cases, the time horizon needs to be significantly extended to meet the goals of #3. Developing Bitcoin is not a race. If we have to, waiting 42 months ensures we’re not setting a negative precedent that we’ll come to regret as Bitcoin continues to grow.

— Matt Corallo
Modern Soft Fork Activation on Bitcoin-dev mailing list (2020)

#### 5.2.3. Taproot upgrade - Speedy Trial

When Taproot was ready for deployment [comm: add time coordinates], meaning all the technical details around its consensus rules had been implemented and had reached broad approval within the community, discussions on how to actually deploy it started to heat up. These discussions had been pretty low key up until that point.

Lots of proposals for activation mechanisms started floating around, and David Harding summarized them on the Bitcoin Wiki. In his article he explained some properties of BIP8, which at that time had some recent changes made in order to make it more flexible.

At the time this document is being written, BIP8 has been drafted based on lessons learned in 2017. One notable change following BIPs 9+148 is that forced activation is now based on block height rather than median time past; a second notable change is that forced activation is a boolean parameter chosen when a soft fork’s activation parameters are set either for the initial deployment or updated in a later deployment.

BIP8 without forced activation is very similar to BIP9 version bits with timeout and delay, with the only significant difference being BIP8’s use of block heights compared to BIP9’s use of median time past. This setting allows the attempt to fail (but it can be retried later).

BIP8 with forced activation concludes with a mandatory signaling period where all blocks produced in compliance with its rules must signal readiness for the soft fork in a way that will trigger activation in an earlier deployment of the same soft fork with non-mandatory activation. In other words, if node version x is released without forced activation and, later, version y is released that successfully forces miners to begin signaling readiness within the same time period, both versions will begin enforcing the new consensus rules at the same time.

This flexibility of the revised BIP8 proposal makes it possible to express some other ideas in terms of what they would look like using BIP8. This provides a common factor to use for categorizing many different proposals.

From this point forward the discussions became very heated, especially around whether `lockinontimeout` should be `true` (as in a user activated soft fork, referred to as “BIP8 with forced activation” by Harding) or `false` (as in a miner activated soft fork, referred to as “BIP8 without forced activation” by Harding).

Among the proposals listed, one of them was titled “Let’s see what happens”. For some reason, this proposal didn’t get much traction until seven months later.

During those seven months, the discussion went on and it seemed like there was no way to reach broad consensus over which deployment mechanism to use. There were mainly two camps: one that preferred `lockinontimeout=true` (the UASF crowd) and the other one that preferred `lockinontimeout=false` (the “try and if it fails rethink” crowd). Since there was no overwhelming support for any of these options, the debate went in circles with seemingly no way forward. Some of these discussions were held on IRC, in a channel called ##taproot-activation, but on March 5th 2021, something changed:

```06:42 < harding> roconnor: is somebody proposing BIP8(3m, false)?  I mentioned that the other day but I didn't see any responses.
[...]
06:43 < willcl_ark_> Amusingly, I was just thinking to myself that, vs this, the SegWit activation was actually pretty straightforward: simply a LOT=false and if it fails a UASF.
06:43 < maybehuman> it's funny, "let's see what happens" (i.e. false, 3m) was a poular choice right at the beginning of this channel iirc
06:44 < roconnor> harding: I think I am.  I don't know how much that is worth.  Mostly I think it would be a widely acceptable configuration based on my understanding of everyone's concerns.
06:44 < willcl_ark_> maybehuman: becuase everybody actually wants this, even miners reckoned they could upgrade in about two weeks (or at least f2pool said that)
06:44 < roconnor> harding: BIP8(3m,false) with an extended lockin-period.
06:45 < harding> roconnor: oh, good.  It's been my favorite option since I first summarized the options on the wiki like seven months ago.
06:45 <@michaelfolkson> UASF wouldn't release (true,3m) but yeah Core could release (false, 3m)
06:45 < willcl_ark_> harding: It certainly seems like a good approach to me. _if_ that fails, then you can try an understand why, without wasting too much time```
— #taproot-activation IRC log

The “let’s see what happens” approach finally seemed to click in peoples' minds. This process would later be labeled as “Speedy Trial” due to its short signaling period. David Harding explains this idea to the broader community in an email to the Bitcoin-dev mailing list.

The earlier version of this proposal was documented over 200 days ago[3] and taproot’s underlying code was merged into Bitcoin Core over 140 days ago.[4] If we had started Speedy Trial at the time taproot was merged (which is a bit unrealistic), we would’ve either be less than two months away from having taproot or we would have moved on to the next activation attempt over a month ago.

Instead, we’ve debated at length and don’t appear to be any closer to what I think is a widely acceptable solution than when the mailing list began discussing post-segwit activation schemes over a year ago.[5] I think Speedy Trial is a way to generate fast progress that will either end the debate (for now, if activation is successful) or give us some actual data upon which to base future taproot activation proposals.

— David Harding on Bitcoin-dev mailing list

This deployment mechanism was refined over the course of two months and then released in Bitcoin Core version 0.21.1. The miners quickly started signaling for this upgrade moving the deployment state to `LOCKED_IN`, and after a grace period the Taproot rules were activated mid-November 2021 in block 709632.

#### 5.2.4. Future deployment mechanisms

Given the problems with the recent soft forks, Segwit and Taproot, it’s not clear how the next upgrade will be deployed. Speedy Trial was used to deploy Taproot, but it was used to bridge the chasm between the UASF and the MASF crowds, not because it has emerged as the best known deployment mechanism.

### 5.3. Risks

During the activation of any fork, be it hard or soft, miner activated or user activated, there’s the risk of a long-lasting chain split. A split that lingers for more than a few blocks can cause severe damage to the sentiment around Bitcoin as well as to its price. But above all, it would cause great confusion over what Bitcoin is. Is Bitcoin this chain or that chain?

The risk with a user activated soft fork is that the new rules get activated even if the majority of the hash power doesn’t support them. This scenario would result in a long-lasting chain split, which would persist until the majority of the hash power adopts the new rules. It could be especially hard to incentivize miners to switch to the new chain if they had already mined blocks after the split on the old chain, because by switching branch they would be abandoning their own block rewards. However, it’s worth mentioning a remarkable episode: in March 2013 a long-lasting split, explained in Section 9.2.3, occurred due to an unintentional hard fork and, contrary to this incentive, two major mining pools made the decision to abandon their branch of the split in order to restore consensus.

On the other hand, the risk with a miner activated soft fork is a consequence of the fact that miners can engage in false signaling, which means that the actual share of the hash power that supports the change could be smaller than it looks. If the actual support doesn’t comprise a majority of the hash power, we’d probably see a long-lasting chain split similar to the one described in the previous paragraph. This, or at least a similar issue, has happened in reality when BIP66 was deployed (see Section 9.2.4), but it got resolved within 6 blocks or so.

#### 5.3.1. Costs of a split

Jimmy Song spoke about the costs associated with hard forks at Breaking Bitcoin in Paris, but much of what he said applies to a chain split due to a failed soft fork as well. He spoke about negative externalities, and defined them as the price someone else has to pay for your own actions.

The classic example of a negative externality is a factory. Maybe they are producing– maybe it’s an oil refinery and they produce a good that is good for the economy but they also produce something that is a negative externality, like pollution. It’s not just something that everyone has to pay for, to clean up, or suffer from. But it’s also 2nd and 3rd order effects, like more traffic going towards the factory as a result of more workers that need to go there. You might also have- you might endanger some wildlife around there. It’s not that everyone has to pay for the negative externalities, it might be specific people, like people who were previously using that road or animals that were near that factory, and they are also paying for the cost of that factory.

— Jimmy Song
Socialized Costs Of Hard Forks at Breaking Bitcoin conference (2017)

In the context of Bitcoin, he exemplifies negative externalities using Bitcoin Cash (bcash), which is a hard fork of Bitcoin created shortly prior to that conference in 2017. He categorizes the negative externalities of a hard fork into one-time costs and permanent costs.

Among the many examples of one-time costs, he mentions the ones incurred by exchanges.

So we have a bunch of exchanges and they had a lot of one-time costs that they had to pay. The first thing that happened is that deposits and withdrawals had to be halted for a day or two for these exchanges because they didn’t know what would happen. Many of these exchanges had to dip into cold storage because their users were demanding bcash. It’s part of their fidicuiary duty, they have to do that. You also have to audit the new software. This is something that we had to do at itbit. We want to spend bcash- how do we do it? We have to download electron cash? Does it have malware? We have to go and audit it. We had like 10 days to figure out if this was okay or not. And then you have to decide, are we going to just allow a one-time withdrawal, or are we going to list this new coin? For an exchange to lis ta new coin, it’s not easy- there’s all sorts of new procedures for cold storage, signing, deposits, withdrawals. Or you could just have this one-off event where you give them their bcash at some point and then you never think about it again. But that has its problems too. And finally, and whatever way you do it, withdrawals or listing– you are going to need new infrastructure to work with this token in some way, even if it’s a one-time withdrawal. You need some way to give these tokens to your users. Again, short-notice. Right? No time to do this, has to be done quickly.

— Jimmy Song
Socialized Costs Of Hard Forks at Breaking Bitcoin conference (2017)

He also lists the one-time costs incurred by merchants, payment processors, wallets, miners, and users, as well as some of the permanent costs, for example privacy loss and a higher risk of reorgs.

Indeed, when a split happens and the chain with the most general rules becomes stronger than the chain with the stricter rules, a reorg will occur. This will have a severe impact on all transactions carried out in the wiped-out branch. For these reasons it’s really important to try avoiding chain splits at all times.

### 5.4. Conclusion

Bitcoin grows and evolves with time. Different upgrade mechanisms have been used over the years and the learning curve is steep. More and more sophisticated and robust methods keep being invented, as we learn more about how the network reacts.

To keep Bitcoin in harmony, soft forks have proven to be the way forward, but the big question is still not fully answered: how do we safely deploy soft forks without causing discord?

This chapter addresses adversarial thinking, a mindset that focuses on what could go wrong and how adversaries might act. We start out by discussing Bitcoin’s security assumptions and security model, after which we explain how ordinary users can improve their self-sovereignty and Bitcoin’s full node decentralization by thinking adversarially. Then, we look into some actual threats to Bitcoin as well as into the adversary’s mind. Lastly, we talk about the axiom of resistance which can help you understand why people are working on Bitcoin in the first place.

When discussing security within various systems, it’s important to understand what the security assumptions are. A typical security assumption in Bitcoin is “the discrete logarithm problem is hard to solve”, which, simply put, means it’s practically impossible to find a private key that corresponds to a particular public key. Another pretty strong security assumption is that a majority of the network’s hashpower is honest, meaning that they play by the rules. If these assumptions are proven wrong, then Bitcoin is in trouble.

In 2015 Andrew Poelstra gave a talk at the Scaling Bitcoin conference in Hong Kong, during which he analyzed Bitcoin’s security assumptions. He starts by noticing that many systems disregard adversaries to some extent; for example, it’s really hard to protect a building against all types of adversarial events. Instead, we generally accept the possibility that someone may burn the building down, and to some extent prevent this and other adversarial behaviors through law enforcement etc.

But online things are different:

However, online we don’t have this. We have pseudonymous and anonymous behavior, anyone can connect to everyone and hurt the system. If it’s possible to adversarially hurt the system, then they will do it. We cannot assume they will be visible and that they will be caught.

— Andrew Poelstra
Security Assumptions at Scaling Bitcoin Hong Kong (2015)

The consequence is that all known weaknesses in Bitcoin must somehow be taken care of, otherwise they will be exploited. After all, Bitcoin is the greatest honey pot in the world.

Poelstra goes on to mention how Bitcoin is a new kind of system; it’s more nebulous than, for example, a signing protocol which has very clear-cut security assumptions.

On his personal blog, software engineer Jameson Lopp, dives into this:

In reality, the bitcoin protocol was and is being built without a formally defined specification or security model. The best that we can do is to study the incentives and behavior of actors within the system in order to better understand and attempt to describe it.

— Jameson Lopp
Bitcoin’s Security Model: A Deep Dive (2016)

So, we have a system that seems to be working in practice, but that we can’t formally prove to be secure. A proof is probably not possible due to the complexity of the system itself.

### 6.1. Not only for Bitcoin experts

The importance of adversarial thinking also extends to everyday Bitcoin users to some degree, not only to hardcore Bitcoin developers and experts. Ragnar Lifthasir mentions in a tweetstorm how simplistic narratives around Bitcoin - for example, “just HODL” - can be degrading to Bitcoin itself, and concludes by saying

To make Bitcoin and ourselves stronger we need to think like the software engineers who contribute to Bitcoin. They peer review, mercilessly seeking flaws. At their tech events they talk about every which way a proposal can fail. They think adversarially. They’re conservative

— Ragnar Lifthasir

He refers to these simplistic narratives as monomanias. Through this definition he’s saying that by focusing on a single thing - for example, “just HODL”- you risk to overlook the arguably more important stuff, such as keeping your Bitcoin secure or doing your best to use Bitcoin in a trustless manner.

### 6.2. Threats

There are a lot of known weaknesses in Bitcoin, and many of them are actively being exploited. To get a glimpse of that, have a look at the Weaknesses page on Bitcoin wiki. There are mentioned a wide variety of problems, such as wallet theft and denial-of-service attacks.

If an attacker attempts to fill the network with clients that they control, you would then be very likely to connect only to attacker nodes. Although Bitcoin never uses a count of nodes for anything, completely isolating a node from the honest network can be helpful in the execution of other attacks.

— Various authors
Bitcoin wiki

This type of attack is called Sybil attack, and it occurs whenever a single entity controls multiple nodes in a network and uses them to appear as multiple entities.

As the quote also mentions, the Sybil attack is not effective on the Bitcoin network because there is no voting through nodes or other numerable entities, but rather through computing power. Nonetheless, this flat structure leaves the system susceptible to other attacks. The Bitcoin wiki page also outlines other possible attacks, such as information hiding (often referred to as eclipse attack), and the way Bitcoin Core implements some heuristic countermeasures against such attacks.

The above are examples of real threats that need to be taken care of.

Figure 6. Excerpt from the Simple Sabotage Field Manual

To better understand the adversary’s mind, it might be helpful to get a glimpse into how they operate. A US government body named Office of Strategic Services, which operated during World War II and had among its purposes to conduct espionage, perform sabotage and spread propaganda, produced a manual for their personnel on how to properly sabotage the enemy. Its title was “Simple Sabotage Field Manual” and contained concrete tips on infiltrating the enemy to make their lives hard. The tips range from burning down warehouses to causing wear to drills in order to decrease the enemy’s efficiency.

For example, there is a section (Figure 6) about how an infiltrator can disrupt organizations. It’s not hard to see how such tactics could be used to target the Bitcoin development process (see Chapter 7), which is open for anyone to participate in. A dedicated attacker can keep stalling progress by endless concerns of irrelevant issues, haggle over precise wordings, and attempt to reiterate discussions that have already been comprehensively addressed. The attacker can also hire a troll army to multiply their own effectiveness; we can call this a social Sybil attack. Using a social Sybil attack, they can make it look like there’s more resistance against a proposed change than there actually is.

This highlights how a determined state can and will do everything in its power to destroy the enemy, including breaking it down from the inside. Since Bitcoin is a form of money that competes with established fiat currencies, chances are that states will regard Bitcoin as an enemy.

Eric Voskuil writes on his Cryptoeconomics wiki page about what he calls the “axiom of resistance”:

In other words there is an assumption that it is possible for a system to resist state control. This is not accepted as a fact but deemed to be a reasonable assumption, due to empirical study of behavior of similar systems, on which to base the system.

One who does not accept the axiom of resistance is contemplating an entirely different system than Bitcoin. If one assumes it is not possible for a system to resist state controls, conclusions do not make sense in the context of Bitcoin - just as conclusions in spherical geometry contradict Euclidean. How can Bitcoin be permissionless or censorship-resistant without the axiom? The contradiction leads one to make obvious errors in an attempt to rationalize the conflict.

— Eric Voskuil
Cryptoeconomics wiki (2017)

What he’s essentially saying is that only when one assumes it’s possible to create a system that states can’t control, is it meaningful to try.

This means that to work on Bitcoin you should accept the axiom of resistance, otherwise you’d better spend your time on other projects. Acknowledging that axiom helps you focusing your development efforts on the real problems at hand: coding around state-level adversaries. In other words, think adversarially.

## 7. Open Source

Bitcoin is built using open source software. In this chapter we analyze what this means, how maintenance of the software works, and how open source software in Bitcoin allows for permissionless development. We dip our toes into selection cryptography, which deals with the selection and use of libraries in cryptographic systems. The chapter includes a section about Bitcoin’s review process, followed by another one on the ways Bitcoin developers get funded. The last section talks about how Bitcoin’s open source culture can look really weird from the outside, and why this perceived weirdness is really a sign of good health.

Most Bitcoin softwares, and especially Bitcoin Core, is open source. This means that the source code of the software is made available to the general public for scrutiny, tinkering, modification, and redistribution. The definition of open source at https://opensource.org/osd includes, among others, the following important points:

Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

— The Open Source Definition
Open Source Initiative website

```The MIT License (MIT)

Copyright (c) 2009-2022 The Bitcoin Core developers

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.```

As noted in Section 2.1, it’s important for users to be able to verify that the Bitcoin software they run “works as advertised”. To do that, they must have unrestricted access to the source code of the software they wish to verify.

In the upcoming sections we dive into some other interesting aspects of open source software in Bitcoin.

### 7.1. Software maintenance

Bitcoin Core’s source code is maintained in a Git repository hosted on GitHub. Anyone can clone that very repository without asking for any permission, and then inspect, build, or make changes to it locally. This means that there are many thousands of copies of the repository spread throughout the globe. These are all copies of the same repository, so what makes this specific GitHub Bitcoin Core repository so special? Technically it’s not special at all, but socially it has become the focal point of Bitcoin development.

Bitcoin and security expert Jameson Lopp explains this very well in a blog post titled “Who Controls Bitcoin Core?”:

Bitcoin Core is a focal point for development of the Bitcoin protocol rather than a point of command and control. If it ceased to exist for any reason, a new focal point would emerge — the technical communications platform upon which it’s based (currently the GitHub repository) is a matter of convenience rather than one of definition / project integrity. In fact, we have already seen Bitcoin’s focal point for development change platforms and even names!

— Jameson Lopp
Who Controls Bitcoin Core? (2018)

He goes on to explain how Bitcoin Core’s software is maintained and secured against malicious code changes. The general takeaway from this full article is summarized at its very end:

No one controls Bitcoin.

No one controls the focal point for Bitcoin development.

— Jameson Lopp
Who Controls Bitcoin Core? (2018)

Bitcoin Core developer Eric Lombrozo talks further about the development process in his Medium post titled “The Bitcoin Core Merge Process”.

Anyone can fork the code base repository and make arbitrary changes to their own repository. They can build a client from their own repository and run that instead if they want. They can also make binary builds for other people to run.

If someone wants to merge a change they’ve made in their own repository into Bitcoin Core, they can submit a pull request. Once submitted, anyone can review the changes and comment on them regardless of whether or not they have commit access to Bitcoin Core itself.

— Eric Lombrozo on Medium.com
The Bitcoin Core Merge Process (2017)

It should be noted that pull requests can take a very long time before being merged to the repository by maintainers, and that’s usually due to a lack of review, which is often due to a lack of reviewers.

Lombrozo also talks about the process that surrounds consensus changes, but that’s a bit beyond the scope of this chapter. See Chapter 5 for more information on how the Bitcoin protocol gets upgraded.

### 7.2. Permissionless development

We’ve established that anyone can write code for Bitcoin Core without asking for any permission, but not necessarily have it merged to the main Git repository. This affects any modification, from changing color schemes of the graphical user interface, to the way peer-to-peer messages are formatted, and even consensus rules, i.e. the set of rules that define a valid blockchain.

Probably equally important is that users are free to develop systems on top of Bitcoin, without asking for any permission. We’ve seen countless successful software projects that were built on top of Bitcoin, such as:

Lightning Network

A payment network that allows for fast payment of very small amounts. It requires very few on-chain Bitcoin transactions. Various inter-operable implementations exist, such as Core Lightning, LND, Eclair, and Lightning Dev Kit.

CoinJoin

Multiple parties collaborate to combine their payments into a single transaction to make address clustering harder. Various implementations exist.

Sidechains

This system can lock a coin on Bitcoin’s blockchain in order to unlock it on some other blockchain. This allows for bitcoins to be moved to some other blockchain, namely a sidechain, so as to use the features available on that sidechain. Examples include Blockstream’s Elements.

OpenTimestamps

It allows you to timestamp a document on Bitcoin’s blockchain in a private way. You can then use that timestamp to prove that a document must have existed prior to a certain time.

Without permissionless development, many of these projects would not have been possible. As stated in Section 1.3, if developers had to ask for permission to build protocols on top of Bitcoin, only the protocols allowed by the central developer granting committee would be developed.

It is common for systems like the ones listed above to be themselves licensed as open source software, which in turn allows for people to contribute, re-use, or review their code without asking for any permission. Open source has become the gold standard of Bitcoin software licensing.

### 7.3. Pseudonymous development

Not having to ask for permission to develop Bitcoin software brings an interesting and important option to the table: you can write and publish code, in Bitcoin Core or any other open source project, without revealing your identity.

Many developers choose this option by operating under a pseudonym and trying to keep it detached from their true identity. The reasons for doing this can vary from developer to developer. One pseudonymous user is ZmnSCPxj. Among other projects, he contributes to Bitcoin Core and Core Lightning, one of several implementations of Lightning Network. He writes on his web page:

I am ZmnSCPxj, a randomly-generated Internet person. My pronouns are he/him/his.

I understand that humans instinctively desire to know my identity. However, I think my identity is largely immaterial, and prefer to be judged by my work.

If you are wondering whether to donate or not, and wondering what my cost of living or my income is, please understand that properly speaking, you should donate to me based on the utility you find my articles and my work on Bitcoin and the Lightning Network.

— ZmnSCPxj on his GitHub page

In his case, the reason for using a pseudonym is to be judged on his merits and not on who the person or persons behind the pseudonym is or are. Interestingly, he revealed in an article on CoinDesk that the pseudonym was created for a different reason.

My initial reason [for using a pseudonym] was simply that I was concerned [about] making a massive mistake; thus ZmnSCPxj was originally intended to be a disposable pseudonym that could be abandoned in such a case. However it seems to have garnered a mostly positive reputation, so I have retained it

— Many Bitcoin Developers Are Choosing to Use Pseudonyms – For Good Reason on CoinDesk (2021)

Using a pseudonym indeed allows you to speak more freely without putting your personal reputation at risk should you say something stupid or make some big mistake. As it turned out, his pseudonym got very reputable and in 2019 he even got a development grant, which is in itself a testament to Bitcoin’s permissionless nature.

Arguably, the most well-known pseudonym in Bitcoin is Satoshi Nakamoto. It’s unclear why he chose to be pseudonymous, but with hindsight it was probably a good decision for multiple reasons:

• As many people speculate that Nakamoto owns a lot of bitcoin, it’s imperative for his financial and personal safety to keep his identity unknown.

• Since his identity is unknown, there is no possibility of prosecuting anyone, which gives various government authorities a hard time.

• There is no authoritative person to look up to, making Bitcoin more meritocratic and resilient against blackmailing.

Notice that these points don’t just hold true for Satoshi Nakamoto, but for anyone working in Bitcoin or holding significant amounts of the currency, to varying degrees.

### 7.4. Selection cryptography

Open source developers often make use of open source libraries developed by other people. This is a natural and awesome part of any healthy ecosystem. But Bitcoin software deals with real money and, in light of this, developers need to be extra careful when choosing which third party libraries it should depend on.

In a philosophical talk about cryptography (you may find the video here), Gregory Maxwell wants to redefine the term “cryptography” which he believes to be too narrow. He explains that fundamentally information wants to be free, and makes his definition of cryptography based on that:

Cryptography is the art and science we use to fight the fundamental nature of information, to bend it to our political and moral will, and to direct it to human ends against all chance and efforts to oppose it.

— Gregory Maxwell
Bitcoin Selection Cryptography (2015)

He then introduces the term selection cryptography, referred to as the art of selecting cryptographic tools, and explains why it is an important part of cryptography. It revolves around how to select cryptographic libraries, tools, and practices, or as he says “the cryptosystem of picking cryptosystems”.

Using concrete examples, he shows how selection cryptography can easily go horribly wrong, and also proposes a list of questions you could ask yourself when practicing it. Below is a distilled version of that list:

1. Is the software intended for your purposes?

2. Are the cryptographic considerations being taken seriously?

3. The review process…​ is there one?

4. What is the experience of the authors?

5. Is the software documented?

6. Is the software portable?

7. Is the software tested?

8. Does the software adopt best practices?

While this is not the ultimate guide to success, it can be very helpful to go through these points when doing selection cryptography.

Due to the issues mentioned above by Maxwell, Bitcoin Core tries really hard to minimize its exposure to third party libraries. Of course, you can’t eradicate all external dependencies, otherwise you’d have to write everything by yourself, from font rendering to implementation of system calls.

### 7.5. Review

This section is named “Review”, rather than “Code review”, because Bitcoin’s security relies heavily on review at multiple levels, not just source code. Moreover, different ideas require review at different levels: a consensus rule change would require a deeper review at more levels compared to a color scheme change or a typo fix.

On its way to final adoption, an idea usually flows through several phases of discussion and review. Some of these phases are listed below:

1. An idea is posted on the Bitcoin-dev mailing list

2. The idea is formalized into a Bitcoin Improvement Proposal (BIP)

3. The BIP is implemented in a pull request (PR) to Bitcoin Core

4. Deployment mechanisms are discussed

5. Some competing deployment mechanisms are implemented in pull requests to Bitcoin Core

6. Pull requests are merged to the master branch

7. Users choose whether to use the software or not

At each of these phases people with different points of view and backgrounds review the available information, be it the source code, a BIP, or just a loosely described idea. The phases are usually not performed in any strict top-down manner, indeed multiple phases can happen simultaneously, and sometimes you go back and forth between them. Different people may also provide feedback during different phases.

One of the most prolific code reviewers on Bitcoin Core is Jon Atack. He wrote a blog post about how to review pull requests in Bitcoin Core. He emphasizes that a good code reviewer focuses on how to best add value.

As a newcomer, the goal is to try to add value, with friendliness and humility, while learning as much as possible.

A good approach is to make it not about you, but rather "How can I best serve?"

— Jon Atack
How to Review Pull Requests in Bitcoin Core (2020)

He highlights the fact that review is a truly limiting factor in Bitcoin Core. Lots of good ideas get stuck in a limbo where no review occurs, pending. Notice that reviewing is not only beneficial to Bitcoin, but also a great way to learn about the software while providing value to it, at the same time. Atack’s rule of thumb is to review 5-15 PRs before making any PR of your own. Again, your focus should be on how to best serve the community, not on how to get your own code merged. On top of this, he stresses the importance of doing review at the right level: is this the time for nits and typos, or does the developer need more of a conceptually-oriented review?

A useful first question when beginning a review can be, "What is most needed here at this time?" Answering this question requires experience and accumulated context, but it is a useful question in deciding how you can add the most value in the least time.

— Jon Atack
How to Review Pull Requests in Bitcoin Core (2020)

The second half of the post consists of some useful hands-on technical guidance on how to actually do the reviewing, and provides links to important documentation for further reading.

Bitcoin Core developer and code reviewer Gloria Zhao has written an article containing questions she usually asks herself during a review. She also states what she considers to be a good review.

I personally think a good review is one where I’ve asked myself a lot of pointed questions about the PR and been satisfied with the answers to them.
…​[snip]…​
Naturally, I start with conceptual questions, then approach-related questions, and then implementation questions. Generally, I personally think it’s useless to leave C++ syntax-related comments on a draft PR, and would feel rude going back to "does this make sense" after the author has addressed 20+ of my code organization suggestions.

— Gloria Zhao
Common PR Review Questions on GitHub (2022)

Her idea that a good review should focus on what’s most needed at a specific point in time aligns well with Jon Atack’s advice. She proposes a list of questions that you may ask yourself at various levels of the review process, but stresses that this list is not in any way exhaustive nor a straight-out recipe. The list is illustrated with real-life examples from GitHub.

### 7.6. Funding

Lots of people work with Bitcoin open source development, either for Bitcoin Core or for other projects. Many do it in their spare time without getting any compensation, but some developers are also getting paid to do it.

Companies, individuals, and organizations who have an interest in Bitcoin’s continued success can donate funds to developers, either directly or through organizations that in turn distribute the funds to individual developers. The website polylunar.com has compiled a list of grants given out by a broad range of individuals, organizations, and companies. There are also a number of Bitcoin-focused companies that hire skilled developers to let them work full-time on Bitcoin.

### 7.7. Culture shock

People sometimes get the impression that there’s a lot of infighting and endless heated debates among Bitcoin developers, and that they are incapable of making decisions.

For example, the Taproot deployment mechanism was discussed over a long period of time during which two “camps” formed. One wanted to “fail” the upgrade if miners hadn’t overwhelmingly voted for the new rules after a certain moment, while the other wanted to enforce the rules after that moment no matter what. Michael Folkson summarizes the arguments from the two camps in an email to the Bitcoin-dev mailing list.

The debate went on seemingly forever, and it was really hard to see any consensus on this forming any time soon. This got people frustrated and as a result the heat intensified. Gregory Maxwell (as user nullc) worried on Reddit that the lengthy discussions would make the upgrade less safe.

At this juncture, additional waiting isn’t adding more review and certainty. Instead, additional delay is sapping inertia and potentially increasing risk somewhat as people start forgetting details, delaying work on downstream usage (like wallet support), and not investing as much additional review effort as they would be investing if they felt confident about the activation timeframe.

— Gregory Maxwell on Reddit
Is Taproot development moving too fast or too slow?

Eventually, this dispute got resolved thanks to a new proposal by David Harding and Russel O’Connor called Speedy Trial, which entailed a comparatively shorter signaling period for miners to lock in activation of Taproot, or fail fast. If they activated it during that window of time, then Taproot would be deployed approximately 6 months later. This upgrade is covered in more detail in Chapter 5.

Someone who’s not used to Bitcoin’s development process would probably think that these heated debates look awfully bad and even toxic. There are at least two factors that make them look bad, in some people’s eyes:

• Compared to closed source companies, all debates happen in the open, unedited. A software company like Google would never let its employees debate proposed features in the open, indeed it would at most publish a statement about the company’s stance on the subject. This makes companies look more harmonic compared to Bitcoin.

• Since Bitcoin is permissionless, anyone is allowed to voice their opinions. This is fundamentally different from a closed source company that has a handful of people with an opinion, usually like-minded people. The plethora of opinions expressed within Bitcoin is simply staggering compared to, for example, PayPal.

Most Bitcoin developers would argue that this openness brings about a good and healthy environment, and even that it is necessary for producing the best outcome.

As hinted in the Adversarial thinking chapter, the second bullet above can be very beneficial but comes with a downside. An attacker could use stalling tactics, like the ones outlined in the Simple Sabotage Field Manual, to distort the decision making and development process.

Another thing worth mentioning is that, as noted in Section 7.4, since Bitcoin is money and Bitcoin Core secures unfathomable amounts of money, security in this context is not taken lightly. This is why seasoned Bitcoin Core developers might appear very hard-headed, which attitude is usually warranted. Indeed, a feature with a weak rationale behind it is not going to be accepted. The same would happen if it broke the reproducible builds, added new dependencies, or if the code didn’t follow Bitcoin’s best practices.

New (and old) developers can get frustrated by this. But, as is customary in open source software, you can always fork the repository, merge whatever you want to your own fork, and build and run your own binary.

## 8. Scaling

In this chapter, we explore how Bitcoin does and does not scale. We start by looking at how people have reasoned about scaling in the past. Then, the bulk of this chapter explains various approaches to scaling Bitcoin, specifically vertical, horizontal, inward, and layered scaling. Each description is followed by considerations over whether the approach interferes with Bitcoin’s value proposition.

In the Bitcoin space, different people ascribe different definitions to the word “scale”. Some conceive it as the increase of the blockchain transaction capacity, others believe it equals to using the blockchain more efficiently, and others see it as the development of systems on top of Bitcoin.

In the context of Bitcoin, and for this book’s purposes, we define scaling as increasing Bitcoin’s usage capacity without compromising its censorship resistance. This definition encompasses several kinds of changes, for example:

• Making transaction inputs use fewer bytes

• Improving signature verification performance

• Making the peer-to-peer network use less bandwidth

• Transaction batching

• Layered architecture

We’ll soon dive into different approaches to scaling, but let’s start with a brief overview of Bitcoin’s history within the context of scaling.

### 8.1. History

Scaling has been a focal point of discussion since the genesis of Bitcoin. The very first sentence of the very first email in response to Satoshi’s announcement of the Bitcoin whitepaper on the Cryptography mailing list was indeed about scaling:

Satoshi Nakamoto wrote:
> I’ve been working on a new electronic cash system that’s fully
> peer-to-peer, with no trusted third party.
>
> The paper is available at:
> http://www.bitcoin.org/bitcoin.pdf

We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.

— James A. Donald and Satoshi Nakamoto
Cryptography mailing list (2008)

The conversation in itself might not be very interesting nor accurate, but it shows that scaling has been a concern from the very beginning.

Discussions over scaling reached their peak interest around 2015-2017, when there were many different ideas circulating about whether and how to increase the maximum block size limit. That was a rather uninteresting discussion about changing a parameter in the source code, a change that didn’t fundamentally solve anything but pushed the problem of scaling further into the future, building technical debt.

In 2015, a conference called Scaling Bitcoin was held in Montreal, with a follow-up conference six months later in Hong Kong and thereafter in a number of other locations around the world. The focus was precisely on how to address scaling. Many Bitcoin developers and other enthusiasts gathered at these conferences to discuss various scaling issues and proposals. Most of these discussions didn’t revolve around block size increases but on more long-term solutions.

After the Hong Kong conference in December 2015, Gregory Maxwell summarized his view on many of the issues that had been debated, starting off with some general scaling philosophy.

With the available technology, there are fundamental trade-offs between scale and decentralization. If the system is too costly people will be forced to trust third parties rather than independently enforcing the system’s rules. If the Bitcoin blockchain’s resource usage, relative to the available technology, is too great, Bitcoin loses its competitive advantages compared to legacy systems because validation will be too costly (pricing out many users), forcing trust back into the system. If capacity is too low and our methods of transacting too inefficient, access to the chain for dispute resolution will be too costly, again pushing trust back into the system.

— Gregory Maxwell
Capacity increases for the Bitcoin system (2015)

He speaks about the trade-off between throughput and decentralization. If you allow for bigger blocks, you will push some people off the network because they won’t have the resources to validate the blocks anymore. But on the other hand, if access to block space becomes more expensive, fewer people will be able to afford using it as a dispute resolution mechanism. In both cases, users are pushed towards trusted services.

He continues by summarizing the many approaches to scaling presented at the conference. Among them are more computationally efficient signature verifications, segregated witness including a block size limit change, a more space-efficient block propagation mechanism, and building protocols on top of Bitcoin in layers. Many of these approaches have since been implemented.

### 8.2. Scaling approaches

As hinted above, scaling Bitcoin doesn’t necessarily have to be about increasing the block size limit or other limits. We now go through some general approaches to scaling, some of which don’t suffer from the throughput-decentralization trade-off mentioned in the previous section.

#### 8.2.1. Vertical scaling

Vertical scaling is the process of increasing the computing resources of the machines processing data. In the context of Bitcoin, these latter would be the full nodes, namely the machines that validate the blockchain on behalf of their users.

The most commonly discussed technique for vertical scaling in Bitcoin is the increase in the block size limit. This would require some full nodes to upgrade their hardware to keep up with the increasing computational demands. The downside is that it happens at the cost of centralization, as was discussed in the previous section and more in depth in Section 1.2.

Besides the negative effects on full node decentralization, vertical scaling might also negatively impact Bitcoin’s mining decentralization and security in less obvious ways. Let’s have a look at how miners “should” operate. Say a miner mines a block at height 7 and publishes that block on the Bitcoin network. It will take some time for this block to reach broad acceptance, which is mainly due to two factors:

• Transfer of the block between peers takes time due to bandwidth limitations.

• Validation of the block takes time.

While block 7 is being propagated through the network, many miners are still mining on top of block 6 because they haven’t received and validated block 7 yet. During this time, if any of these miners finds a new block at height 7, there will be two competing blocks at that height. There can only be one block at height 7 (or any other height), which means one of the two candidates must become stale.

In short, stale blocks happen because it takes time for each block to propagate, and the longer propagation takes, the higher the probability of stale blocks.

Suppose that the block size limit is lifted and that the average block size increases substantially. Blocks would then propagate slower across the network due to bandwidth limitations and verification time. An increase in propagation time will also increase the chances of stale blocks.

Miners don’t like to have their blocks staled because they’ll lose their block reward, so they will do whatever they can to avoid this scenario. The measures they can take include:

• Postponing the validation of an incoming block, also known as validationless mining. Miners can just check the block header’s proof-of-work and mine on top of it, while in the meantime they download the full block and validate it.

• Connecting to a mining pool with greater bandwidth and connectivity.

Validationless mining further undermines full node decentralization, as the miner defers trusting incoming blocks, at least temporarily. It also hurts security to some degree because a portion of the network’s computing power is potentially building on an invalid blockchain, instead of building on the strongest and valid chain.

The second bullet point has a negative effect on miner decentralization, because usually the pools with the best network connectivity and bandwidth are also the largest and thus most centralized.

#### 8.2.2. Horizontal scaling

Horizontal scaling refers to techniques that divide the workload across multiple machines. While this is a prevalent scaling approach among popular websites and databases, it’s not easily done in Bitcoin.

Many people refer to this Bitcoin scaling approach as sharding. Basically, it consists in letting each full node verify just a portion of the blockchain. Peter Todd has put a lot of thought into the concept of sharding. He wrote a blog post explaining sharding in general terms, and also presenting his own idea called treechains. The article is a difficult read, but Todd makes some points that are quite digestible.

In sharded systems the “full node defense” doesn’t work, at least directly. The whole point is that not everyone has all the data, so you have to decide what happens when it’s not available.

— Peter Todd
Why Scaling Bitcoin With Sharding Is Very Hard (2015)

Then he presents various ideas on how to tackle sharding, or horizontal scaling. Towards the end of the post he concludes:

$cd btcphilosophy``` and then build using any of the two methods below #### B.1.1. Using `asciidoctor` Use this option if you just want to casually build the book and read the end result locally. It requires only `asciidoctor` to be present on your computer. `$ asciidoctor -v btcphilosophy.adoc`

The `-v` flag is recommended and instructs asciidoctor to be verbose, which means it will show invalid references and other issues. The above command will result in a file `btcphilosophy.html` in your current directory that you can view in any browser, for example:

`$brave-browser btcphilosophy.html` The source material is collected and maintained as a separate book under the `sources` folder. To build it: `$ asciidoctor -v sources/sources.adoc`

This will result in a file `sources/sources.html` that you can open in a web browser in the same way as the main book.

#### B.1.2. Using Gnu `make`

If you have access to the `make` command on a linux machine you can build using

`$make` This will create a `build` directory and build both the main book (lands in `build/btcphilosophy.html`) and the sources book (lands in `build/sources/sources.html`). If you have ImageMagick installed, `make` will reduce the size of some images for faster download over the web. Otherwise it’ll write a warning message saying that the images will not be resized. This method of building is usually preferred as it keeps the source tree separate from ascriidoctor output files, and it will reduce the size of pictures to make it more appropriate for serving the book on the web. #### B.1.3. Build a PDF If you have `asciidoctor-pdf` installed, you can create a PDF that gives a better looking result than first generating html and then “Print To PDF” from that. Create the PDF by issuing `asciidoctor-pdf` manually, or by using `make pdf`. To issue the command manually: `$ asciidoctor-pdf btcphilosophy.adoc`

The result will be written to `btcphilosophy.pdf`. To use `make`:

`\$ make pdf`

The result will be written to `build/btcphilosophy.pdf`.