Skip to content

Instantly share code, notes, and snippets.

@jgarzik

jgarzik/bitcoin-packaging-challenges.md

Last active December 20, 2015 03:39
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jgarzik/6065679 to your computer and use it in GitHub Desktop.
Save jgarzik/6065679 to your computer and use it in GitHub Desktop.
Download ZIP
Challenges of packaging Bitcoin software
Raw
bitcoin-packaging-challenges.md

DRAFT IN PROGESS - DO NOT CIRCULATE

Technical note

The Challenges of Packaging Bitcoin Software

Introduction

Bitcoin technology is complex. Under the hood of the decentralized virtual currency lies a novel form of decentralized, distributed database. It is critical for users, system adminstrators and packaging engineers to understand bitcoin's database consistency model, which is radically different from familiar database consistency models (MySQL, Berkeley DB, Amazon Dynamo, or Google's GPS-based doohickey).

Beyond the database arena, bitcoin's security model relies on some non-obvious assumptions that directly contradict certain existing Linux distribution security practices.

Database consistency model

Bitcoin's "account ledger" is a database of unspent transaction outputs ("UTXO"). Bitcoins available to spend. As bitcoin is a distributed system, the UTXO database is a distributed database. As bitcoin is decentralized, this is necessarily a self-regulating, decentralized database.

Every distributed database in today's "cloud" era has a slightly different consistency model. Most server-based, traditional SQL databases feature strong consistency. By contrast, cloud databases such as Amazon Dynamo offer weak or eventual consistency.

Bitcoin can be thought of as a form of eventual consistency. Bitcoin must solve a famous computer science problem, that of distributed consensus:

A fundamental problem in distributed computing is to achieve overall system reliability in the presence of a number of faulty processes. This often requires processes to agree on some data value that is needed during computation.

Bitcoin's challenge is to do that... for money. Bitcoin must be reliable enough to maintain its monetary value, which is a challenge of monumental proportions.

Zero trust. Validate everything.

Bitcoin achieves consensus and avoids double spending through a combination of several techniques. Read the paper for full details. Technical, economic and game theory measures are all employed to encourage network participants to achieve consensus.

Each peer on the bitcoin network trusts no one. That is, each peer validates the entire past history of bitcoin transactions, to build and maintain the UTXO database. Data is replicated in its entirety to each peer, simlar to a D1HT.

Validation of the bitcoin dataset uses standard cryptographic algorithms and database libraries: SHA256, Elliptic curve keys, Berkeley DB, Level DB, and others.

Forks: Consensus and Network Partitions

Describe what a fork is etc.

Make a mistake, lose $1 billion

The consequences of bitcoin consensus failure are very high, comparable to avionics or medical device software. As of this writing, over $1 billion of value depends on bitcoin software being able to reliably achieve consensus over the worldwide Internet. This is the digital equivalent of Fort Knox: consensus must be achieved, or bitcoin has no value.

Technical recommendations

  • Do not replace embedded libs with system libs

DRAFT IN PROGESS - DO NOT CIRCULATE

@maqifrnswa
Copy link

Technical recommendations:

  • Security and bug fixes will be found in new releases and will not necessarily be backported. Do not release packages that can not be updated by totally replacing the package (e.g., long term stable releases that only allow small security patches, there may not be an easy or clean patch if it is based on code from future versions).

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