Bitcoin goals, defined by the whitepaper

Engineers weigh different design choices on their merits and choose the solution that best matches the requirements.

The goals of the bitcoin project are outlined in the bitcoin whitepaper.


The goal of being trustless is stated several times in the whitepaper, and can be summarized as:

 Online payments can be sent directly between two parties without relying on a trusted third party.

Here’s the direct quotes from the whitepaper about the goal of trustlessness.

allow online payments to be sent directly from one party to another without going through a financial institution

an electronic payment system … allowing any two willing parties to transact directly with each other without the need for a trusted third party

a system for electronic transactions without relying on trust


Irreversibility is a key property of cash and bitcoin aims to achieve transactions that cannot be reversed. This is closely related to the goal of being trustless.

 Payments are non-reversible.

There are a couple of quotes from the whitepaper supporting this goal. They are direct responses to the disadvantages of trusted systems. Bitcoin should not suffer from the inherent weaknesses of the trust based model, ie

completely non-reversible transactions [should be possible]

ability to make non-reversible payments for non-reversible services


Bitcoin is open for use by all, regardless of the intent or outcome of that use. An effect of being trustless, bitcoin should not be vulnerable to censorship or exclusion.

 Transactions should fill the needs of transfer regardless of value or purpose.

This is stated in the bitcoin whitepaper abstract, as a direct response to the disadvantages of trusted systems. Bitcoin should not suffer from the inherent weaknesses of the trust based model, ie

[avoid] limiting the minimum practical transaction size and cutting off the possibility for small casual transactions

[avoid being] wary of their customers, hassling them for more information than they would otherwise need


Bitcoin should grow and remain resilient as it does so. The system should automatically reinforce participation that contributes to the survival of the system.

 Participation in line with the goals of bitcoin should yield greater utility than participation against the goals.

This is explicitly stated in the whitepaper.

[attackers should find it] more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth


There’s a need to delineate goals from the network properties and implementation. Whilst these aren’t goals themselves, they’re definitely part of ‘what is bitcoin’. Here are the properties and implementations stated in the whitepaper:


These goals can be used to set constraints around the bitcoin network, which define the range of possible changes.

Of course, there is always the possibility of changing the goals themselves, but that is not the responsibility of the engineer.


Now read this

Qubes 3.2 After One Month

Having spent nearly a month with Qubes, this is the record of my observations. Summary I love the way the system works and plan to keep it. However, performance, especially graphics performance, is the main cause for doubt about keeping... Continue →