Bitcoin Development Philosophy (eBook)

Kalle Rosenbaum, Linnéa Rosembaum (Autoren)

eBook Download: EPUB

2024 | 1. Auflage
150 Seiten
Konsensus Network (Verlag)
978-9916-723-60-9 (ISBN)

Infos

Bitcoin Development Philosophy is a comprehensive guide aimed at developers who have a foundational understanding of Bitcoin concepts and processes such as Proof-of-Work, block building, and the transaction life cycle. This book delves into the intricacies of Bitcoin's design trade-offs and philosophy, offering insights and context that help developers absorb over a decade of development lessons and debates. The book is organized into several chapters, each focusing on pivotal topics within Bitcoin, such as decentralization, trustlessness, privacy, finite supply, and scaling, among others. Every chapter is enriched with links and QR codes leading to recommended articles or videos, written by seasoned Bitcoin developers. It not only provides practical insights but also encourages independent exploration and critical thinking about contradictory ideas prevalent in the Bitcoin community.

Kalle Rosenbaum, the main author, is a seasoned software developer with extensive experience in Bitcoin-related development since 2015. He is the author of Grokking Bitcoin and has been a pivotal figure in educating developers about Bitcoin. Linnéa Rosenbaum, the co-author, holds a Ph.D. in Electronic Systems and has a rich background in firmware and software development. She is the Swedish translator of The Little Bitcoin Book and co-translator of The Bitcoin Standard, contributing significantly to the dissemination of knowledge about Bitcoin in Sweden. Their combined expertise and passion for Bitcoin have been instrumental in creating a guide that is insightful, comprehensive, and enlightening.

Textauszug

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.

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 (see also Adversarial thinking):

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.

— 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.

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 (see 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...

Produkt-Details

• Erscheint lt. Verlag: 30.5.2024
• Verlagsort: Tallinn
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik ► Netzwerke
• Schlagworte: BIP • Bitcoin • blocksize • Computers • Development • improvement proposal • Process • Science • Software • war
• ISBN-10: 9916-723-60-5 / 9916723605
• ISBN-13: 978-9916-723-60-9 / 9789916723609