[Course] Bitcoin Theory
This course covers the design of Bitcoin as described in the white paper, and looks at how the economic incentives drive the development of the network and build the hyper dense connectivity at its centre. The introductory course is a detailed overview of the Bitcoin white paper with second level courses diving deeper into the theory and layers of design.
View Course
[eBook] What is Bitcoin?
Though Bitcoin is most commonly known as a monetary system, at its core you will discover a data management system with features and benefits that set it apart from all others.
Download free eBook
[eBook] What is Blockchain?
We explain blockchain in terms of the data systems you are familiar with, its basic architecture, why it's called a blockchain and where Bitcoin fits in.
Download free eBook
[eBook] The BSV Blockchain as Infrastructure for the Data Economy
Learn how the BSV Blockchain helps your business and family to harness the data economy in a profitable and sustainable way.
Download free eBook
[eBook] The BSV Blockchain for Enterprise Blockchain
This eBook explains how the BSV Blockchain has returned to the original Bitcoin protocol to deliver a global, enterprise-level blockchain while others have failed.
Download free eBookBitcoin Theory Course Content
How and why we got to 3 Bitcoin node implementations
On January 3, 2009, Satoshi Nakamoto mined the first block, known as the Genesis Block, marking the beginning of the Bitcoin blockchain. In this 13 year period, BTC has undergone numerous technical adaptations.
Read MoreCh1: The Bitcoin white paper’s abstract
Unlike in the legacy banking model, where for two parties to transact, both parties must employ the services of a trusted third party (e.g. a bank), in Bitcoin, money is exchanged peer-to-peer using the Bitcoin protocol.
Transactions can involve effectively unlimited numbers of peers thanks to the flexibility of the protocol which is limited only by the economics of constructing and verifying each transaction rather than arbitrary parameters.
Wallets allow users to create transactions that sign ownership records of digital coins and assign them to new owners. The records of these exchanges make up the history of Bitcoin transactions, sometimes referred to as a ledger.
Ch2: The Bitcoin white paper’s introduction
At the time the white paper was published, internet commerce was a growing element of the economy with the rise of businesses such as eBay and Amazon proving that the internet could offer people business opportunities.
The issue was that all transactions are routed through legacy payment systems to pay for goods or services via the internet and rely on trusted third parties to manage the payment process. Most of these services tend to be credit card processors, banks, or payment processors such as PayPal.
These systems work well for payments over an amount of several dollars, but when we look at smaller payments we see how the fees incurred by these third parties hinder profits for the business owner.
This is a significant burden on users and presents a barrier limiting the capabilities of services to implement systems using micropayments for $1 or less. By comparison, Bitcoin payments are received instantly and can be considered settled within just a few seconds, removing the lag that most payment systems insert in the process of commerce.
Ch3: The Bitcoin white paper - Transactions
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double-spending.
After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent.
The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
Ch4: The Bitcoin white paper - Timestamp Server
A Bitcoin block consists of an ordered set of transactions which each validly spend existing unspent transaction outputs (UTXO) into new transaction outputs. The network considers each transaction to be a separate item or event, and builds the blocks as such, using the hashed transaction message as an input into the block’s own hash function.
When a node finds a valid block, each transaction is published as part of that block, and through the hash of the transaction message can be provenly shown to have existed at the time the block was found. Blocks are broadcast across the whole Bitcoin network and either accepted or rejected by the rest of the nodes in the competition. These broadcast events can be considered akin to the publishing of a notice on a publicly available bulletin board or website.
Ch5: The Bitcoin white paper - Proof-of-Work
To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash, rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.
The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.
For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work.
As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
Ch6: The Bitcoin white paper - Network
Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first.
In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
These listed steps are the way by which nodes running on the network compete to secure the contents of the ledger by storing it in blocks. The steps are broken down as follows:
Ch7: The Bitcoin white paper - Bitcoin’s incentives
By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for Bitcoin nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them.
The steady addition of a constant amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. The incentive can also be funded with transaction fees.
Ch8: The Bitcoin white paper - Reclaiming disk space
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree, with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.
A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
Ch9: The Bitcoin white paper - Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
