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:
- a solution to the double-spending problem using a peer-to-peer network
- the main benefits are lost if a trusted third party is still required to prevent double-spending
- a record that cannot be changed without redoing the proof-of-work
- based on cryptographic proof instead of trust
- transactions that are computationally impractical to reverse
- nodes can leave and rejoin the network at will
- [security exists if] honest nodes collectively control more CPU power than any cooperating group of attacker nodes
- Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
- Nodes work all at once with little coordination
- [nodes] do not need to be identified
- no central authority to issue [coins into circulation]
- [nodes] vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them
- provides strong control of ownership
- protect sellers from fraud
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.