mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-15 20:49:21 +00:00
1012 lines
76 KiB
Plaintext
1012 lines
76 KiB
Plaintext
Dump of material that needs to be placed later
|
|
|
|
.The transaction outputs sum up to less than the input, leaving the fee
|
|
----
|
|
Alice's transaction to pay for Bob's coffee:
|
|
|
|
Input 0.1000 BTC
|
|
minus Output to Bob 0.0150 BTC
|
|
minus Output to Alice (change) 0.0845 BTC
|
|
|
|
equals Transaction fee 0.0005 BTC
|
|
----
|
|
|
|
.Transaction Chains and Mining
|
|
****
|
|
As you examine the chain of transactions you may ask: "If every transaction refers to value in a previous transaction, where does the value come from originally?". All bitcoins are originally _mined_ (see <<mining>>). Each block contains a special transaction which is the first transaction in the block. This is called the _generation_ transaction and it generates bitcoin out of a special input, which is called the _coinbase_ and is reward for creating a new block. In simple terms, miners get the privilege of a magic transaction that create bitcoins from thin-air and pay those bitcoins to themselves. If you were to look at the chain of transaction for a bitcoin payment you have received, you can track the inputs to a previous transaction's output. Go back far enough and you will find the block where the bitcoins you hold today were once mined.
|
|
****
|
|
|
|
If the wallet application does not maintain a copy of unspent transaction outputs, it can query the bitcoin network to retrieve this information, using a variety of APIs available by different providers, or by asking a full-index node using the bitcoin JSON RPC API. Below we see an example of a RESTful API request, constructed as a HTTP GET command to a specific URL. This URL will return all the unspent transaction outputs for an address, giving any application the information it needs to construct transaction inputs for spending. We use the simple command-line HTTP client _cURL_ to retrieve the response:
|
|
|
|
.Lookup all the unspent outputs for address 1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
|
|
----
|
|
$ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
|
|
|
|
{
|
|
|
|
"unspent_outputs":[
|
|
|
|
{
|
|
"tx_hash":"186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd734d2804fe65fa35779",
|
|
"tx_index":104810202,
|
|
"tx_output_n": 0,
|
|
"script":"76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
|
|
"value": 10000000,
|
|
"value_hex": "00989680",
|
|
"confirmations":0
|
|
}
|
|
|
|
]
|
|
}
|
|
----
|
|
|
|
The response above shows that the bitcoin network knows of one unspent output (one that has not been redeemed yet) under the ownership of Alice's address _+1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK+_. The response includes the reference to the transaction in which this unspent output is contained (the payment from Joe) and it's value in Satoshis, at 10 million, equivalent to 0.10 bitcoin. With this information, Alice's wallet application can construct a transaction to transfer that value to new owner addresses.
|
|
|
|
|
|
|
|
=== Transaction Data Structure
|
|
|
|
A transaction, in bitcoin terminology, also refers to the signed data structure that contains a series of inputs and outputs transferring value, as encoded in the blockchain or propagating on the bitcoin network. In the blockchain, a transaction is stored as a variable-lenght data structure, that contains an array of _transaction inputs_ and an array of _transaction outputs_.
|
|
|
|
.A transaction data structure, as stored in the blockchain
|
|
[options="header"]
|
|
|=======
|
|
|Part|Size|Description
|
|
|Version| 4 bytes | The transaction type version (default and only type value is 1)
|
|
|Number of Inputs | VarInt | How many inputs are listed below
|
|
|Inputs | List of Tx_In | One or more inputs, specifying where the value will come from
|
|
|Number of Outputs | VarInt | How many outputs are listed below
|
|
|Outputs | List of Tx_Out | One or more outputs, specifying where to "send" the value
|
|
|=======
|
|
|
|
From the perspective of Alice and Bob's transaction for the cup of coffee, the input would be Alice's coins from previous transactions and the output would be 0.015 BTC (or 1.5m satoshi) that would be "sent" to Bob's bitcoin address for payment of the coffee. Bob could then spend this bitcoin by creating transactions whose inputs refer to this transaction
|
|
s output. Each transaction's outputs become possible inputs for future transactions. What changes is who controls the keys that unlock them. For that we have to delve in a bit deeper into the data structure of the inputs and outputs themselves.
|
|
|
|
The input always refers to a previous transaction. In the case of Alice's coffee purchase, her wallet software would find a previous transaction that has a similar value, to minimize the need for generating change.
|
|
|
|
.Alice's transaction input
|
|
[options="header"]
|
|
|=======
|
|
|Part|Value|Description
|
|
|Previous Tx Hash| 643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 | a hash used to identify a previous transaction
|
|
|Previous Tx Index| 0 | The first output of that transaction is referred to as index number 0
|
|
|Script Signature | 30450...6b241501 | A signature from Alice's key to unlock this value
|
|
|=======
|
|
|
|
In the input above, Alice sources the funds to pay for the coffee. In this case, all the funds come from a single output from a previous transaction. It is possible to construct transactions that source value from dozens of inputs, aggregating the value, as we will see Bob's wallet do to add up all the small payments into a larger payment. A transaction can also have hundreds of outputs, so the _Tx Index_ is used to identify which of the previous transaction's outputs will be "consumed" in this new transaction. In this case, Alice will be using the first transaction output, index number zero.
|
|
|
|
You may notice that there is no value field in the input. That is because the *entire* value of the referenced output is consumed. You cannot use only part of an output, you must use the entire value. All the value from all the inputs listed in a transaction is aggregated and then disbursed to the various outputs, according to the value defined in those outputs. In attempting to pay Bob for coffee, Alice must create a transaction for the exact amount, even though she may not have "exact change" in the form of previous transactions that perfectly match. Alice will therefore have to either aggregate many smaller inputs (previous unspent outputs) to reach the price of the coffee, or use a larger input and then make some change back to her wallet. This is all done automatically by the wallet software, so Alice just sees the exact amount transacted, but behind the scenes there may be a flurry of inputs being aggregated and change returned.
|
|
|
|
[TIP]
|
|
====
|
|
Inputs don't have a value field. That is because the outputs of a previous transaction can either be spent or unspent as a whole. You cannot use part of an output, you must use all of it. If you only need part of the value of a previous output, you must spend all of it and generate "change", by creating an new output for the excess value back to your own wallet.
|
|
====
|
|
|
|
|
|
.Alice's transaction output
|
|
[options="header"]
|
|
|=======
|
|
|Part|Value|Description
|
|
|Value| 1,500,000 | The value in satoshi to transfer to this output
|
|
|Script| OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG | A script for spending this output
|
|
|=======
|
|
|
|
The second part of the transaction, is where Alice effectively pays Bob for the coffee. This is achieved by creating an output _that only Bob can spend_. In bitcoin, the script used to "lock" an output to a specific bitcoin address is +OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+, with +<public key hash>+ replaced by the public key of the recipient, in this case Bob's public key.
|
|
|
|
While this script looks rather complicated and confusing, it will be explained in great detail below (see <<script>>). This exact script is used in 99.99% of bitcoin transactions, as it expresses the simple goal of _"payable to whoever can generate a signature with the private key of this bitcoin address"_. With this output, Alice establishes a value of 0.015BTC "payable to Bob". Once this transaction is propagated on the network, included in a block and confirmed, Bob will be able to spend this output by constructing a transaction of his own.
|
|
|
|
|
|
|
|
[[payment-request-URL]]
|
|
.The payment request QR code above encodes the following URL, defined in BIP0021
|
|
----
|
|
bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA?amount=0.015&label=Bob%27s%20Cafe&message=Purchase%20at%20Bob%27s%20Cafe
|
|
|
|
Components of the URL
|
|
A bitcoin address: 1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA
|
|
The payment amount: amount=0.015
|
|
A label for the recipient address: label=Bob%27s%20Cafe
|
|
A description for the payement: message=Purchase%20at%20Bob%27s%20Cafe
|
|
----
|
|
|
|
|
|
|
|
* External Risks
|
|
|
|
All world currencies today are controlled by sovereign nation states. This control has significant political and economic benefits and is, of course, zealously protected. As a result, attempts to create competing and independent digital currencies, have quickly come under legal, or sometimes extra-legal, attack. Without a central organization, clearinghouse or controlling authority, bitcoin is not easy to attack. It is resilient to interference because control of the network and security of the currency is distributed as much as possible.
|
|
|
|
////Again, this is good info, but I don't see how it fits into the History of Cryptocurrencies. I might include this in as introductory material in a section on security. - AM////
|
|
|
|
[[ch00_intro_what_is_bitcoin]]
|
|
== Introduction
|
|
|
|
////Introduction should be Ch01 as preface is Ch00 - AM ////
|
|
|
|
=== What is Bitcoin?
|
|
((("bitcoin")))
|
|
Bitcoin is digital money, a currency for and of the Internet. Bitcoin can be used to buy products or services online or in-person, just like cash or a credit card. Bitcoin can be transmitted as fast as an email from any person to any other person just by installing the software. Bitcoin is de-centralized: There is no central entity, not a bank or governing body that controls bitcoin. It operates by consensus, according to simple mathematical rules that are in the software for all to see.
|
|
|
|
Behind the scenes, bitcoin is a network, a protocol, a standard and a currency. For now think of it simply as digital money that can be sent, received and stored by anyone, worldwide simply by downloading compatible software and joining a network.
|
|
|
|
Bitcoin is the culmination of decades of research in cryptography and distributed systems and represents four key innovations brought together in a unique and powerful combination. Bitcoin consists of a de-centralized peer-to-peer network, a public transaction ledger, a de-centralized mathematical and deterministic currency issuance, a de-centralized transaction verification system and a set of powerful APIs. All of these are "bitcoin", and each of these aspects of bitcoin will be examined in this book.
|
|
|
|
More than all of these parts, bitcoin is a digital economy platform, just like the Internet is a digital communications platform. With bitcoin, it is possible to build entire new financial systems, transaction types and economies on top of a purely digital, instantaneous and frictionless platform, an Internet for money.
|
|
|
|
|
|
=== History of bitcoin
|
|
|
|
.A brief history of money
|
|
****
|
|
Money is a means of transferring or storing wealth. It exists in many abstract forms, least abstract (food) to highly abstract (personal cheque). Over time, money has become increasingly abstract.
|
|
|
|
Most forms of money fit some of the following criteria:
|
|
* Lightweight and portable
|
|
* Hard to counterfeight
|
|
* Scarce in the local environment (doesn't grow on trees)
|
|
* Fungible (each unit is indistinguishable and interchangeable with another, a penny is a penny)
|
|
|
|
((("precious metals")))
|
|
Digital money appeals to many people because it tends to combine some of the characteristics of precious metals (fungible, scarce, store of value) with the characteristics of paper money instruments (lightweight, hard to copy). In the past, currencies represented a compromise of sorts between the various desired characteristics of money. Bitcoin appeals to many as it is seen to be "no compromise" money.
|
|
****
|
|
|
|
=== History of Cryptographic-Currencies
|
|
((("crypto-currency")))
|
|
|
|
Cryptographic currencies depend on cryptography to control the ownership of a piece of digital data. Using cryptographic digital signatures, a user can sign a digital asset or transaction and securely prove the ownership of that asset.
|
|
|
|
In the late 1980s, when cryptography started becoming more broadly available and understood, many researchers began trying to use cryptography to build digital currencies. These early digital currency projects issued digital money, usually backed by a national currency or precious metal such as gold.
|
|
|
|
While these earlier digital currencies worked, they had several fatal flaws. Firstly, early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Secondly, these central clearinghouses and the organizations issuing the digital currency were highly centralized organizations, usually corporations. Unfortunately, in most cases these nascent digital currencies were targetted by worried governments and eventually litigated to death.
|
|
|
|
Bitcoin's major breakthrough is the removal of any central authority or clearinghouse. Bitcoin is decentralized by design and does not have a central issuer or clearinghouse. It is the first fully decentralized digital currency. To achieve this amazing feat, bitcoin has replace the need for a central clearinghouse with a form of distributed _consensus_ based on participants proving they are contributing to the network security via a _proof-of-work_ algorithm.
|
|
|
|
////You break from the history of cryptocurrency into Bitcoin's major breakthrough. With this headind you'd expect to read about the evolution of cryptocurrency from early iterations to Bitcoin's beginning in 2009. If you're not going to cover this, I might change the header or move this info. I would also avoid sweeping phrases like "amazing feat." - AM////
|
|
|
|
|
|
The result of this deliberate decentralization is that bitcoin has removed two major areas of risk for digital currencies:
|
|
|
|
* Third Party Risk - Counterparty Risk
|
|
|
|
When a transaction occurs in a traditional financial payment network there are at least three parties to the transaction: the buyer, seller, and counteparty clearing house. This introduces a source of risk in the system - counterparty risk. Buyers and seller must not only trust each other, but also trust the central clearinghouse. With national currencies the central clearinghouse is the central bank and is therefore inextricably connected to the political process. Trust in the counterparty (central bank) is simply an extension of trust in the government and democratic process. Where digital currencies struggled to create the clearinghouse and imbue it with trust, bitcoin completely removes the need for counterparty trust by removing the counterparty.
|
|
|
|
=== Stories
|
|
|
|
It is easiest to experience bitcoin from the perspective of a few specific stories that we will explore in detail throughout the book.
|
|
|
|
Each story represents a specific real use of bitcoin in different contexts.
|
|
|
|
|
|
==== Alice buys a cup of coffee from Bob's Cafe
|
|
|
|
Alice wants to buy a cup of coffee using bitcoin. She visits Bob's Cafe, a coffee shop that accepts bitcoin payments, as advertised by a sign declaring _"Bitcoin Accepted Here"_ in the window. At the counter, the prices may be listed in a local currency like Euros or Dollars. At the register, Bob would ring up a coffee, displaying
|
|
|
|
|
|
----
|
|
Total:
|
|
$1.50 USD
|
|
0.015 BTC
|
|
----
|
|
|
|
Or Bob might say _"That's one-dollar-fifty, or fifteen milibits"_.
|
|
|
|
Alice would use a smartphone to scan the barcode on display and send the payment. Her smartphone would show a payment of +0.0150 BTC+ to +Bob's Cafe+ and she would select +Send+ to authorize the payment. Within a few seconds (about the same time as a credit card authorization), Bob would see the transaction on the register, completing the transaction. Alice has purchased a cup of coffee for 15 millibits (or 0.015 bitcoin)
|
|
|
|
[TIP]
|
|
====
|
|
Bitcoin can be used in a few pioneering coffee shops, as described above, but you might have to search for one.
|
|
====
|
|
|
|
|
|
==== A currency
|
|
((("bitcoin")))
|
|
Bitcoin is a currency, the operates much like any "foreign" currency. The main difference is that it is not issued by a national government. Bitcoin currency units are called "bitcoins". Unlike traditional currencies, bitcoins are divisible to much smaller units. The smallest unit is the _satoshi_, one hundred-millionth of a bitcoin (1/100,000,000). Bitcoin can be exchanged for other currencies at specialized currency exchanges that support crypto-currencies like bitcoin. There, a customer can exchange US dollars ($) or Euros (€) for bitcoin, at the prevailing market exchange rate
|
|
|
|
|
|
////I think we need to work on organization here. I don't understand the transition between "Stories" and this section. What is the segue? - AM ////
|
|
|
|
Symbols: B⃦, Ƀ, ฿
|
|
|
|
Currency Code: BTC (unofficial), XBT (possible ISO standard)
|
|
((("bitcoin")))
|
|
((("millibitcoin")))
|
|
((("millibit", see="millibitcoin")))
|
|
((("microbitcoin")))
|
|
((("mike", see="microbitcoin")))
|
|
((("satoshi (currency unit)")))
|
|
[[table_bitcoinunits]]
|
|
.Table of bitcoin units from bitcoin wiki (https://en.bitcoin.it/wiki/Units)
|
|
[options="header"]
|
|
|=======
|
|
| Unit Name | Notation | Value
|
|
| bitcoin | BTC or B⃦ | 1 BTC
|
|
| millibitcoin or "millibit" | mBTC or mB⃦ | 0.001 BTC or 1/1000th
|
|
| microbitcoin or "mike" | μBTC or μB⃦| 0.000001 BTC or 1/1m
|
|
| satoshi | satoshi | 0.00000001 BTC or 1/100m
|
|
|=======
|
|
|
|
|
|
|
|
==== A network and protocol
|
|
((("peer-to-peer")))
|
|
((("P2P", see="peer-to-peer")))
|
|
Bitcoin operates on top of a peer-to-peer network, also called "bitcoin". The bitcoin network is used to propagate transactions, new blocks and alert messages. The network operates using a relatively simple network protocol for peer discovery and blockchain replication.
|
|
|
|
////These read like an expansion on your glossary/repetitive. - AM ////
|
|
|
|
One interesting feature of bitcoin is that the issuance of the currency decreases automatically over time, halving every four years, reaching an absolute maximum of 21 million bitcoins issued sometime around the year 2140.
|
|
|
|
////Should this be a text box instead of its own paragraph? - AM ////
|
|
|
|
[[chart_bitcoin_decreasing_issuance]]
|
|
Chart of decreasing issuance over time
|
|
|
|
==== Transactions
|
|
|
|
People can pay for goods and services using bitcoin as the currency. mg
|
|
|
|
Bitcoin transactions, which transfer value from one bitcoin address to another, are recorded in a distributed ledger, called the _blockchain_. In simple terms, think of the ledger as a book with lines like this:
|
|
|
|
----
|
|
...
|
|
- Address 27 gave 2 bitcoin to address 81
|
|
- Address 132 gave 1.05 bitcoin to address 22
|
|
- 25 bitcoin were mined to address 76
|
|
- Address 13 gave 0.5 bitcoin to address 52
|
|
- Address 52 gave 0.015 bitcoin to address 166
|
|
...
|
|
----
|
|
|
|
The ledger is a record of all bitcoin transactions and can be independently verified by every node.
|
|
|
|
==== The blockchain
|
|
((("blockchain")))
|
|
Bitcoin's core innovation is the _blockchain_, a distributed, timestamped ledger. The ledger consists of a cryptographically verified chain of _blocks_, each of which contains transactions, new coins and a signature (hash) of the previous block. Each full bitcoin node in the network will keep a complete local replica of the blockchain, and independently verify all transactions and balances from that replica.
|
|
|
|
[[blockchain_diagram]]
|
|
.Blockchain: A chain of blocks
|
|
image::images/blockchain.png["A chain of blocks"]
|
|
|
|
==== Mining for blocks
|
|
((("mining")))
|
|
Bitcoin's security is underpinned by computation. The blockchain is formed by solving a problem, called the _proof-of-work_ (PoW) that requires a predictable computational effort, one that takes approximately 10 minutes for the entire network of bitcoin nodes to solve. The process is called _mining_, since it has diminishing returns, just like mining for precious metals. It works a bit like a global lottery, where every bitcoin miner attempts to find a solution to a cryptographic equation. The first miner to find a solution, broadcasts it on the peer-to-peer bitcoin network for others to verify and include in the blockchain. For any transaction to be included in the global blockchain, it must be verified and included inside a new block. Each block includes the fingerprint of the previous block int he chain and any new transactions that have occured in the intervening 10 minutes.
|
|
|
|
When a bitcoin miner discovers a new solution to the proof of work algorithm, they create a new block which includes newly minted bitcoin in a transaction that pays to the miner's own bitcoin address. Bitcoin miners earn the newly minted bitcoin as a reward by creating a transaction to pay themselves. They can do this only if they discover a solution to the proof-of-work problem, thus providing an incentive to participate in mining and thereby to computationally secure the transactions.
|
|
|
|
Essentially, the bitcoin currency units are issued through mining, just like a central bank issues new money by printing bank notes. The amount of newly created bitcoin in each block decreases every four years. It started at 50 bitcoin per block in 2008 and halved to 25 bitcoin per block in 2012. It will halve again to 12.5 bitcoin per block in 2016. Based on this formula, bitcoin mining rewards decrease exponentially until approximately 2140 when all 21 million bitcoin have been issued.
|
|
|
|
//// Is this repetitive? Haven't you covered block decreasing every four years already? - AM /////
|
|
|
|
Bitcoin miners also earn fees from transactions. Every transaction may include a transaction fee, in the form of a surplus of bitcoin between the transaction's inputs and outputs. The bitcoin miner gets to "keep the change" on the transactions.
|
|
|
|
At the time of writing this, the fees usually represent 1% or less of a bitcoin miner's income, the vast majority coming from the newly minted bitcoins. However, as the reward decreases over time, a greater proportion of bitcoin mining earnings will come from fees, until after 2140 all bitcoin miner earnings will be in the form of transaction fees.
|
|
|
|
|
|
==== A transaction language
|
|
((("Script")))
|
|
((("transaction script")))
|
|
A simple bitcoin transaction transfers value from one bitcoin address to another. However, there is much more to bitcoin transactions than that. Each transaction is a signed script that is evaluated using a stack-based interpreter. The language of transactions is Forth-like and not Turing-complete as it does not include looping constructs.
|
|
|
|
A transaction script can make a bitcoin payment payable to the owner of a bitcoin address, to multiple bitcoin addresses, to anyone who solves a riddle, to anyone who guesses a number or to infinitely more complex requirements.
|
|
|
|
The transaction script language is extremely powerful and can be used to express very complex and novel transactions. It is examined in more detail in <<complex_transactions>>.
|
|
|
|
|
|
==== An Application Programming Interface (API)
|
|
((("JSON-RPC API")))
|
|
((("API", see="JSON-RPC API")))
|
|
|
|
The reference bitcoin software implementation, known as the _Satoshi Client_ and with the application name +bitcoin-qt+ or +bitcoind+, offers a client-level API. The API is available as a JSON/RPC interface and offers programmatic access to bitcoin wallets, th blockchain and the bitcoin network.
|
|
|
|
=== Getting Bitcoin
|
|
((("bitcoind")))
|
|
((("bitcoin-qt")))
|
|
((("bitcoin client")))
|
|
There are many different implementations of bitcoin, from the front-end user interface to various libraries, servers and bitcoin network nodes.
|
|
|
|
The reference implementation of bitcoin, which combines a full bitcoin network node, a wallet and a user interface is known as the _Satoshi Client_, or also as its executable name +bitcoind+ on Unix-like systems and +bitcoin-qt+ for the graphical user interface component. The Satoshi client is maintained by a network of volunteers as an open source project hosted on Github https://github.com/bitcoin/bitcoin.
|
|
|
|
////So does this match the header of "Getting Bitcoin." What is the reader supposed to do with this information? - AM ////
|
|
|
|
==== Full node client or lightweight client?
|
|
((("full node")))
|
|
((("lightweight client")))
|
|
|
|
A full node client is one that stores a local copy of the entire blockchain (the distributed transaction ledger), from the first block (the _Genesis Block_) to the most current block. The blockchain is usually stored in a database, to make indexing and retrieval easier. It is a multi-gigabyte file, at least 8GB at this time. As a result, a full-node client may take several days and quite a bit of disk space to become fully "synchronized" with the network, meaning it has downloaded a full copy of the blockchain up to the most recent block.
|
|
|
|
By comparison, a lightweight client does not store a full copy of the blockchain. Instead, it relies on selected trusted servers which can answer queries about the blockchain. As a result, a lightweight client can bootstrap instantly and start processing transactions. However, a lightweight client is always reliant on an external trusted source of data on the blockchain, whereas a full node client can independently validate any transaction without trusted third parties or the counterparty risks they introduce.
|
|
|
|
==== Desktop, mobile, web or hybrid wallet?
|
|
((("web wallet")))
|
|
((("mobile wallet")))
|
|
((("desktop wallet")))
|
|
|
|
Bitcoin clients exist in many forms and for many platforms. The examples in this book will use the reference client as well as several other desktop, mobile and web examples. For practical bitcoin use you may want to try a desktop, mobile and web wallet, or a web/mobile hybrid.
|
|
|
|
////I would not put the below in Tip format if it is something the reader needs to do to make use of the book. - AM ////
|
|
|
|
[TIP]
|
|
============================================================================
|
|
For the purposes of following the examples in this book, we recommend you download and install several bitcoin clients, to compare their capabilities and try out the examples. You must at least download the reference client +bitcoin+, as well as a lightweight client such as Electrum, or Multibit.
|
|
============================================================================
|
|
|
|
==== Obtaining the bitcoin software
|
|
|
|
===== Reference Client (bitcoind, bitcoin-qt)
|
|
|
|
Versions for Windows, Mac, Linux and source code can be found at http://bitcoin.org/en/download
|
|
|
|
////Does this explain how the reader goes about getting up and running? - AM ////
|
|
|
|
When you first run the bitcoin-qt application, it will start downloading the full blockchain, several gigabytes of data. It may take several days to fully synchronize the complete blockchain. During that time, the client will display "out of sync" next to balances and show "Synchronizing" in the footer.
|
|
|
|
[[bitcoin-qt-firstload]]
|
|
.Bitcoin-Qt - The Graphical User Interface, during the blockchain initialization
|
|
image::images/bitcoin-qt-firstload.png["bitcoin-qt first run"]
|
|
|
|
|
|
//// This is confusing. I would explain in one section what the reader should do, whether for downloading the lightweight client or bitcoin-qt application. - AM ////
|
|
[TIP]
|
|
============================================================================
|
|
For more immediate use of the bitcoin software, try downloading a lightweight client too, one that does not have a full-node copy of the blockchain.
|
|
============================================================================
|
|
|
|
===== Mobile client
|
|
|
|
On Android, you can find many bitcoin clients by searching for "bitcoin wallet" in the official application market. The most notable are:
|
|
|
|
////Why are they the most notable? Why choose these over others? - AM ////
|
|
|
|
* Andreas Shildbach's Android Bitcoin Wallet https://play.google.com/store/apps/details?id=de.schildbach.wallet
|
|
* Mycelium light-weight node https://play.google.com/store/apps/details?id=com.mycelium.wallet$$[]
|
|
* Blockchain.info hybrid web/mobile wallet https://play.google.com/store/apps/details?id=piuk.blockchain.android
|
|
|
|
Due to restrictions by Apple, there are no wallet applications for iOS. However, you can use web wallets in your iOS browser.
|
|
|
|
////Links for web wallets? - AM ////
|
|
|
|
===== Web wallets
|
|
|
|
Web wallets are bitcoin wallets that are offered as a service by various online providers. These web wallets may be held by the online service, in which case the security of the funds depends entirely on that online service provider. This is very similar to a traditional banking environment where a third party has control and maintains security over your funds. However, unlike traditional banking these companies are rarely regulated. Therefore, web wallets should be used with caution.
|
|
|
|
Web wallets are extremely convenient for new users and a great way to introduce someone to bitcoin. However, they should not be used to store large amounts of value without taking security measures, most importantly two-factor authentication. Web wallets are vulnerable to hacks and also to remote compromise via trojans or key-loggers on your own desktop computer. Many users have lost bitcoin because their account was accessed from an insecure and compromised computer, which subsequently activated an unauthorized withdrawal.
|
|
|
|
////Links for web wallets? Notable ones? - AM ////
|
|
|
|
[TIP]
|
|
====
|
|
Always use two-factor authentication on online wallets. The risk of compromise by key-logger or compromized desktop is very high. Additionally, do not store all your bitcoin online or in a single wallet, instead spread the risk a bit.
|
|
====
|
|
////Haven't you already pointed this tip out in the paragraphs before? - AM ////
|
|
|
|
|
|
==== Public key cryptography and crypto-currency
|
|
((("public key")))
|
|
Public-key cryptography, or assymetric cryptography, is a key part of a crypto-currency. Surprisingly, the cryptographic keys are not actually stored inside the bitcoin blockchain or the network. Instead, the blockchain only records transactions with digital signatures (hashes) of keys. The keys themselves are completely independent and can be generated and managed by the end users. This enables many of the interesting properties of bitcoin, including de-centralized trust and control.
|
|
|
|
In a nutshell, public-key cryptography is like a digital padlock, which can only be opened by the owner of a secret key. The owner of that key can hand out as many copies of the padlock as they want, and others can use it to "lock" bitcoins inside transactions recorded on the blockchain. Only the owner of the key can then unlock and "redeem" these transactions, as only they can open the digital padlock.
|
|
|
|
|
|
==== Peer-to-Peer networks
|
|
((("peer-to-peer")))
|
|
Bitcoin is more than just a currency, it is also the payment network that carries all of the transactions of that currency. Well, almost all, as we will see in examining "off-blockchain" transactions later in this book.
|
|
|
|
The bitcoin network is a peer-to-peer network, which is formed by all the bitcoin clients that are running a full-node client. At any moment, the bitcoin network can range in size anywhere from a tens of thousands to hundreds of thousands of nodes. Only a tiny subset of those is required to operate, but good network propagation and distribution ensures resillience and survivability of the overall bitcoin network.
|
|
|
|
You can see a graphical representation of the nodes seen on the bitcoin network by visiting a popular chart on blockchain.info https://blockchain.info/nodes-globe
|
|
|
|
In the bitcoin peer-to-peer network, the nodes are much more sophisticated than most p2p networks. All nodes can validate the basic information inside a block for themselves and confirm the transactions. A full-node client can independently confirm each and every bitcoin in every transaction, in an unbroken chain all the way back to it's genesis in a newly minted block. The network therefore plays a subordinate role. It propagates transactions, but those transactions are independently verified by the nodes. The network is not trusted per-se, as each node does not depend on any third-party for trust. Instead, the network facilitates the propagation of blocks so that nodes that are mining can create new blocks and all nodes can verify them.
|
|
|
|
The bitcoin network essentially carries two types of data: unconfirmed transactions and mined blocks. The bitcoin network is used to propagate transactions between bitcoin users, ensuring that they are included in the blockchain when the next new block is mined. The networks gets the transactions to the miners and propagates newly mined blocks to all the clients.
|
|
|
|
A new bitcoin client can join the network and request any block, reconstructing the blockchain from the first (Genesis) block, all the way to the most recently mined block. Since each client also contains a static digital copy of the first block embedded in the source code, it can independently verify the entire blockchain. For example, a new client would request block with height "1", and verify that it is correct and contains the correct signature for block "0", the genesis block. Now, the client has bootstrapped the blockchain, independently verifying block "1", and now has a blockchain of height "1". From here, the client can request a block with height "2" from the network. If that can be validated as a valid block that can be added, then the blockchain is confirmed to height "2" etc. After a day or more, several hundred thousand blocks later, the network node can catch up and find that it has the same height as the majority of the network. Since the node has independently verified all of the blocks, it can confirm each transaction and bitcoin ever spent as valid without reference to any external authority. The only block trusted is the genesis block embedded within, the rest of the trust is derived experientially and independently.
|
|
|
|
////Should this all be covered in the Introduction or could some of this be moved to a later chapter? - AM ////
|
|
|
|
=== Finite monetary supply
|
|
|
|
Bitcoins are "minted" during the creation of each block at a fixed and diminishing rate. Each block, generated on average every 10 imnutes, contains a _reward_ that consists of entirely new bitcoins. The reward was 50BTC for the first four years of operation of the network. Every four years the reward is decreased by 50%, resulting in a dimishing rate of issuance over time. In 2012, the reward was decreased to 25BTC and it will decrease again to 12.5BTC in 2016. By approximately 2140, the last fragments of a bitcoin will be mined, for a total of 21 million bitcoins.
|
|
|
|
The algorithm that constrains bitcoin issuance to a geometrically decreasing curve, was modelled after the diminishing returns of mining for precious metals like gold, which are more and more difficult (costly) to extract over time.
|
|
|
|
The finite and diminishing issuance creates a fixed monetary supply that resists inflation. Unlike a fiat currency which can be printed in infinite numbers by a central bank, bitcoin can never be inflated by printing.
|
|
|
|
////These blocks of info read like info dumps. We need to work on organization and making this more fluid for the reader. - AM ////
|
|
|
|
==== Monetary supply
|
|
|
|
Bitcoin's monetary supply is defined as the number of coins in circulation (minted). Like any other currency, this measure of monetary supply is called M0, which represents the narrowest measure of the money supply. Just like any other currency, bitcoin can also have a _fractional reserve banking_ which means that an organization can trade bitcoins "off blockchain" which are not part of the M0 monetary measure, but of the broader monetary supply measures M1-M3.
|
|
|
|
While the total bitcoins in circulation will not exceed 21m, that monetary base can support a much broader economy through fractional reserve banking and expansion of the available credit.
|
|
|
|
=== Divisibility and deflation
|
|
|
|
The most important and debated consequence of a fixed and diminishing monetary issuance is that the currency will tend to be inherently _deflationary_. Deflation is the phenomenon of appreciation of value due to a mismatch in supply and demand that drives up the value (and exchange rate) of a currency. The opposite of inflation, price deflation means that your money has more purchasing power over time.
|
|
|
|
Many economists argue that a deflationary economy is a disaster that should be avoided at all costs. That is because in a period of rapid deflation, the incentives for regular people are to hoard the money and not spend it, hoping that prices will fall. Such a phenomenon unfolded during Japan's "Lost Decade", when a complete collapse of demand pushed the currency into a deflationary spiral.
|
|
|
|
Bitcoin experts argue that deflation is not bad *per se*. Rather, we associate deflation with a collapse in demand because that is the only example of deflation we have to study. In a fiat currency with the possibility of unlimited printing, it is very difficult to enter a deflationary spiral unless there is a complete collapse in demand and an unwillingness to print money. Deflation in bitcoin is not caused by a collapse in demand, but by predictably constrained supply.
|
|
|
|
In practice, it has become evident that the hoarding instinct caused by a deflationary currency can be overcome by discounting from vendors, until the discount overcomes the hoarding instinct of the buyer. Since the seller is also motivated to hoard, the discount becomes the equilibrium price at which the two hoarding instincts are matched. With discounts of 30% on the bitcoin price, most bitcoin retailers are not experiencing difficulty overcoming the hoarding instinct and generating revenue. It remains to be seen whether the deflationary aspect of the currency is really a problem when it is not driven by rapid economic retraction.
|
|
|
|
==== Why would I use bitcoin
|
|
|
|
////Add text here - AM ////
|
|
|
|
===== As a merchant
|
|
|
|
Bitcoin's transaction fees are relatively flat and extremely low, compared to traditional payment networks. The current fee implementation is based on the size of a transaction's storage entry in the blockchain in bytes, with most transactions simply accepting the minimum fee of 0.5 millibits, or approximately 5 US cents at the time of writing, much lower than any other payment system.
|
|
|
|
Unlike traditional payment systems, bitcoin offers irreversible payments. Once a transaction is confirmed in the blockchain, the bitcoins are locked with the merchant keys and _cannot_ be reversed by anyone. This is especially important for merchants who operate online or shipping-based businesses, where a reversed charge on shipped merchandise is a significant and recurring problem.
|
|
|
|
===== As a consumer
|
|
|
|
Bitcoin is a tremendously useful currency. It offers consumers the ability to operate their own bank account, which is global in scope and entirely controlled by the user. Consumers can use their bitcoin anywhere in the world, instantly and with very low fees, without revealing their identity or providing pages and pages of personal information just to buy a product. A bitcoin user can also transmit bitcoin to a friend or family member, instantly and anywhere in the world without the need for bank accounts, expensive wire transfers or the permission of their government.
|
|
|
|
===== As a developer, integrator
|
|
|
|
Bitcoin is a developer's paradise. Where traditional banking and payment systems depend on exclusion as the means of securing the systems, bitcoin uses computation as the basis for its trust model. As a result, the network, protocol, transaction language and APIs are completely open and anyone can interact with the entire bitcoin system at any level. There is a wealth of progrmmatic interfaces at every layer, allowing developers and integrators to mash, code, hack and interface with bitcoin's internals.
|
|
|
|
===== As an entrepreneur
|
|
|
|
TBD
|
|
|
|
//// unfinished - AM /////
|
|
|
|
===== As an investor
|
|
|
|
Bitcoin is a strange asset class. It's not exactly a commodity, a currency, a stock or a fund. It is a bit of all of those and more, an asset class unto itself. Furthermore, there are other crypto-currencies and they can be traded for each other. Crypto currencies are a whole new world of asset classes that underpin independent and low-friction online economies.
|
|
|
|
////A lot of this reads like information that needs to be part of a different/its own chapter. The introduction should be a brief _introductory_ peak at the topic for the reader and get them up and running with the tools they will need in later chapters. There doesn't seem to be a fluidity to the topics here and headings could be moved around without making a difference. I'm interested in your introduction of the "Stories" idea (may need to change this to case study, or Bitcoin in Real Life, or something) but it seemed oddly isolated from the rest of the chapter and I didn't get a sense of how we would be coming back to it throughout the book. -AM ////
|
|
|
|
|
|
[[ch01_how_does_bitcoin_work]]
|
|
== How Does Bitcoin Work?
|
|
|
|
=== Bitcoin currency and units
|
|
|
|
Internally, all values are stored in _satoshi_, the base unit of the bitcoin currency, equal to 100th of a millionth of a bitcoin latexmath:[\( 1 satoshi = 1/100,000,000 bitcoin\)]. For example, Alice's transaction transferring 0.015 bitcoin to Bob for a cup of coffee, will be encoded in the blockchain with a value of one and a half million (1,500,000) satoshi.
|
|
|
|
[TIP]
|
|
====
|
|
All value references in the book will indicate satoshi or bitcoin units as appropriate. Code segments showing encoded value should be assumed to be satoshi unless otherwise specified
|
|
====
|
|
|
|
=== Bitcoin addresses and public key crypto
|
|
|
|
Bitcoin uses Elliptic Curve public key cryptography for its default algorithm for signing transactions.
|
|
|
|
==== Public Key Cryptography
|
|
((("public key", "private key")))
|
|
Public key, or assymetric cryptography, is a type of cryptography that uses a pair of digital keys. A user has a private and a public key. The public key is derived from the private key with a mathematical function that is difficult to reverse.
|
|
|
|
[[pubcrypto_colors]]
|
|
.Public Key Cryptography: Irreversible Function as Color Mixing
|
|
image::images/pubcrypto-colors.png["Public Key Cryptography: Irreversible Function as Color Mixing"]
|
|
|
|
As an example, think of mixing a shade of yellow with a shade of blue. Mixing the two colors is simple. However, figuring out exactly which two shades went into the final mix is not so easy, unless you have one of the two shades. If you have one of the colors you can easily filter it out and get the other. Whereas mixing colors is easy, "un-mixing" them is hard. The mathematical equivalent most often used in cryptography is the Discrete Logarith Problem link$$https://en.wikipedia.org/wiki/Discrete_logarithm_problem#Cryptography$$[Discrete Logarithm Problem in Cryptography]
|
|
|
|
To use public key cryptography, Alice will ask Bob for his public key. Then, Alice can encrypt messages with Bob's public key, knowing that only Bob can read those messages, since only Bob has the equivalent private key.
|
|
|
|
[TIP]
|
|
====
|
|
In most implementations, the private and public keys are stored together as a _key pair_, for convenience. However, it is trivial to re-produce the public key if one has the private key, so storing only the private key is also possible.
|
|
====
|
|
|
|
==== Elliptic Curve Cryptography
|
|
((("elliptic curve cryptography", "ECC")))
|
|
Elliptic Curve Cryptography is a type of assymetric or public-key cryptography based on the discrete logarithm problem as expressed by addition and multiplication on the points of an elliptic curve.
|
|
|
|
Starting with a private key in the form of a randomly generator number +k+, we multiply it with a predetermined point on the curve called the _generator point_ to produce another point somewhere else on the curve, which is the corresponding public key.
|
|
|
|
[latexmath]
|
|
++++
|
|
\begin{equation}
|
|
{K = k G}
|
|
\end{equation}
|
|
++++
|
|
|
|
[[key_derivation]]
|
|
where +k+ is the private key, +G+ is a fixed point on the curve called the _generator point_, ((("generator point"))) and +K+ is the resulting public key, another point on the curve.
|
|
|
|
Elliptic curve multiplication can be visualized geometrically as drawing a line connecting two points on the curve (G and kG) to produce a third point (K). The third point is the public key.
|
|
|
|
[[ecc_addition]]
|
|
.Elliptic Curve Cryptography: Visualizing the addition operator on the points of an elliptic curve
|
|
image::images/ecc-addition.png["Addition operator on points of an elliptic curve"]
|
|
|
|
Bitcoin specifically uses the +secp256k1+ elliptic curve:
|
|
((("secp256k1")))
|
|
[latexmath]
|
|
++++
|
|
\begin{equation}
|
|
{y^2 = (x^3 + 7)} \text{over} \mathbb{F}_p
|
|
\end{equation}
|
|
++++
|
|
or
|
|
|
|
[latexmath]
|
|
++++
|
|
\begin{equation}
|
|
{y^2 \mod p = (x^3 + 7) \mod p}
|
|
\end{equation}
|
|
++++
|
|
|
|
where +p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F+, a very large prime.
|
|
|
|
The +mod p+ indicates that this curve is over a finite field of prime order +p+, also written as latexmath:[\(\mathbb{F}_p\)]. The curve looks like a pattern of dots scattered in two dimensions, which makes it difficult to visualize. However, the math is identical as that of an elliptic curve over the real numbers shown above.
|
|
|
|
[[ecc-over-F37-math]]
|
|
.Elliptic Curve Cryptography: Visualizing the addition operator on the points of an elliptic curve over F(p)
|
|
image::images/ecc-over-F37-math.png["Addition operator on points of an elliptic curve over F(p)"]
|
|
|
|
|
|
==== Generating bitcoin keys
|
|
|
|
There are many ways to generate keys for use in bitcoin. The simplest is to pick a large random number and turn it into a key pair (See <<key_derivation>>). A random key can generated with very simple hardware or even manually with pen, paper and dice. The disadvantage of random keys is that if you generate many of them you must keep copies of all of them. Another method for making keys is _deterministic key generation_. Here you generate each new key as a function of the previous key, linking them in a sequence. As long as you can re-create that sequence, you only need the first key to generate them all. In this section we will examine the different methods for key generation.
|
|
|
|
===== Type-0 or non-deterministic (random) keys
|
|
|
|
The first and most important step in generating keys is to find a secure source of entropy, or randomness. The private key is a 256-bit number, which must be selected at random. Creating a bitcoin key is essentially the same as "Pick a number between 1 and 2^256^". The exact method you use to pick that number does not matter, as long as it is not predictable or repeatable. Bitcoin software will use the underlying operating system's random number generators to produce 256-bits of entropy. Usually, the OS random number generator is initialized by a human source of randomness, which is why you may be asked to wiggle your mouse around for a few seconds. For the trully paranoid, nothing beats dice, pencil and paper.
|
|
|
|
|
|
[[Type0_keygen]]
|
|
.Private key generation: From random mouse movements to a 256-bit number used as the private key
|
|
image::images/Type-0 keygen.png["Private key generation"]
|
|
|
|
|
|
[TIP]
|
|
====
|
|
The bitcoin private key is just a number. A public key can be generated from any private key. Therefore, a public key can be generated from any number, up to 256-bits long. You can pick your keys randomly using a method as simple as dice, pencil and paper.
|
|
====
|
|
|
|
Once a private key has been generated, the public key equivalent can be derived from it using the elliptic curve multiplication function. Many software implementations of bitcoin use the OpenSSL library, specifically the https://www.openssl.org/docs/crypto/ec.html[Elliptic Curve library].
|
|
|
|
Here's an example from the reference implementation, generating a public key from an existing private key
|
|
|
|
[[ecc_mult]]
|
|
.Reference Client: Using OpenSSL's EC_POINT_mul to generate the public key from a private key https://github.com/bitcoin/bitcoin/blob/0.8.4/src/key.cpp#L31[bitcoin/src/key.cpp : 31]
|
|
====
|
|
[source, c++]
|
|
----
|
|
|
|
// Generate a private key from just the secret parameter
|
|
int EC_KEY_regenerate_key(EC_KEY *eckey, BIGNUM *priv_key)
|
|
{
|
|
|
|
[...initializtion code ommitted ...]
|
|
|
|
if (!EC_POINT_mul(group, pub_key, priv_key, NULL, NULL, ctx)) <1>
|
|
goto err;
|
|
|
|
EC_KEY_set_private_key(eckey,priv_key);
|
|
EC_KEY_set_public_key(eckey,pub_key);
|
|
|
|
[...]
|
|
----
|
|
<1> Multiplying the priv_key by the generator point of the elliptic curve group, produces the pub_key
|
|
====
|
|
|
|
[TIP]
|
|
====
|
|
The size of bitcoin's private key, 2^256^ is a truly unfathomable number. It is equal to approximately 10^77^ in decimal. The visible universe contains approximately 10^80^ atoms.
|
|
====
|
|
|
|
This most basic form of key generation, generates what are known as _Type-0_ or _Non-Deterministic_ (ie. random) keys. When a sequence of keys is generated for a single user's wallet, each key is randomly generated when needed
|
|
|
|
[[Type0_chain]]
|
|
.Type-0 or Non-Deterministic Keys are randomly generated as needed
|
|
image::images/type0_chain.png["Key generation"]
|
|
|
|
===== Type-1 deterministic (non-random) key chains
|
|
|
|
[[Type1_chain]]
|
|
.Type-1 Deterministic Keys are generated from a phrase and index number
|
|
image::images/type1_chain.png["Key generation"]
|
|
|
|
===== Type-2 chained deterministic keys
|
|
|
|
[[Type2_chain]]
|
|
.Type-2 Chained Deterministic Keys are generated from a binary seed and index number
|
|
image::images/type2_chain.png["Key generation"]
|
|
|
|
===== Type-2 hierarchical deterministic keys
|
|
|
|
[[Type2_tree]]
|
|
.Type-2 Hierarchical Deterministic Keys are derived from a master seed using a tree structure
|
|
image::images/BIP32-derivation.png["Key generation"]
|
|
|
|
=== Transactions
|
|
|
|
In simple terms, a transaction tells the network that the owner of a number bitcoins has authorized the transfer of some of those bitcoins to another owner. The new owner can now spend these bitcoins by creating another transaction that authorizes transfer to another owner, and so on, in a chain of ownership.
|
|
|
|
[TIP]
|
|
====
|
|
_Transactions_ move value from _transaction inputs_ to _transaction outputs_. An input is where the coins (value) is coming from, either a previous transaction's output or a miner's reward. An output "sends" value to a new owner by locking it with their key.
|
|
====
|
|
|
|
The transaction contains proof of ownership for each amount of bitcoin whose value is transfered, in the form of a digital signature from the owner, that can be independently validated by anyone. In bitcoin terms, "spending" is signing the value of a previous transaction for which you have the keys, over to a new owner.
|
|
|
|
At this point you may begin to wonder: "If every transaction refers to value in a previous transaction, where does the value come from originally?". All bitcoins are originally _mined_ (see <<mining>>). Each block contains a special transaction which is the first transaction in the block. This is called the _generation_ transaction and it generates bitcoin out of a special input, which is called the _coinbase_ and is reward for creating a new block. In simple terms, miners get the privilege of a magic transaction that create bitcoins from thin-air and pay those bitcoins to themselves. If you were to look at the chain of transaction for a bitcoin payment you have received, you can track the inputs to a previous transaction's output. Go back far enough and you will find the block where the bitcoins you hold today were once mined.
|
|
|
|
A transaction, in bitcoin terminology, also refers to the signed data structure that contains a series of inputs and outputs transferring value, as encoded in the blockchain or propagating on the bitcoin network. In the blockchain, a transaction is stored as a variable-lenght data structure, that contains an array of _transaction inputs_ and an array of _transaction outputs_.
|
|
|
|
.A transaction data structure, as stored in the blockchain
|
|
[options="header"]
|
|
|=======
|
|
|Part|Size|Description
|
|
|Version| 4 bytes | The transaction type version (default and only type value is 1)
|
|
|Number of Inputs | VarInt | How many inputs are listed below
|
|
|Inputs | List of Tx_In | One or more inputs, specifying where the value will come from
|
|
|Number of Outputs | VarInt | How many outputs are listed below
|
|
|Outputs | List of Tx_Out | One or more outputs, specifying where to "send" the value
|
|
|=======
|
|
|
|
From the perspective of Alice and Bob's transaction for the cup of coffee, the input would be Alice's coins from previous transactions and the output would be 0.015 BTC (or 1.5m satoshi) that would be "sent" to Bob's bitcoin address for payment of the coffee. Bob could then spend this bitcoin by creating transactions whose inputs refer to this transaction
|
|
s output. Each transaction's outputs become possible inputs for future transactions. What changes is who controls the keys that unlock them. For that we have to delve in a bit deeper into the data structure of the inputs and outputs themselves.
|
|
|
|
The input always refers to a previous transaction. In the case of Alice's coffee purchase, he wallet software would find a previous transaction that has a similar value, to minimize the need for generating change. Let's assume that Alice had previously been paid 0.02BTC by someone else. Her wallet will use that previous transaction to pay Bob for the coffee.
|
|
|
|
|
|
.Alice's transaction input
|
|
[options="header"]
|
|
|=======
|
|
|Part|Value|Description
|
|
|Previous Tx Hash| 643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 | a hash used to identify a previous transaction
|
|
|Previous Tx Index| 0 | The first output of that transaction is 0
|
|
|Script Signature | 30450...6b241501 | A signature from Alice's key to unlock this value
|
|
|=======
|
|
|
|
In the input above, Alice sources the funds to pay for the coffee. In this case, all the funds come from a single output from a previous transaction. It is possible to construct transactions that source value from thousands of inputs, aggregating the value. A transaction can also have thousands of outputs, so the _Tx Index_ is used to identify which of the previous transaction's outputs will be "consumed" in this new transaction. In this case, Alice will be using the first transaction output.
|
|
|
|
You may notice that there is no value field in the input. That is because the *entire* value of the referenced output is consumed. You cannot use only part of an output, you must use the entire value. All the value from all the inputs listed in a transaction is aggregated and then disbursed to the various outputs, according to the value defined in those outputs. In attempting to pay Bob for coffee, Alice must create a transaction for the exact amount, even though she may not have "exact change" in the form of previous transactions that perfectly match. Alice will therefore have to either aggregate many smaller inputs (previous unspent outputs) to reach the price of the coffee, or use a larger input and then make some change back to her wallet. This is all done automatically by the wallet software, so Alice just sees the exact amount transacted, but behind the scenes there may be a flurry of inputs being aggregated and change returned.
|
|
|
|
For simplicity, Alice was lucky enough to have a perfectly matching previous transaction, so her wallet only needs one input for this coffee transaction.
|
|
|
|
[TIP]
|
|
====
|
|
Inputs don't have a value field. That is because the outputs of a previous transaction can either be spent or unspent as a whole. You cannot use part of an output, you must use all of it. If you only need part of the value of a previous output, you must spend all of it and generate "change", by creating an new output for the excess value back to your own wallet.
|
|
====
|
|
|
|
|
|
.Alice's transaction output
|
|
[options="header"]
|
|
|=======
|
|
|Part|Value|Description
|
|
|Value| 1,500,000 | The value in satoshi to transfer to this output
|
|
|Script| OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG | A script for spending this output
|
|
|=======
|
|
|
|
The second part of the transaction, is where Alice effectively pays Bob for the coffee. This is achieved by creating an output _that only Bob can spend_. In bitcoin, the script used to "lock" an output to a specific bitcoin address is +OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+, with +<public key hash>+ replaced by the public key of the recipient, in this case Bob's public key.
|
|
|
|
While this script looks rather complicated and confusing, it will be explained in great detail below (see <<script>>). This exact script is used in 99.99% of bitcoin transactions, as it expresses the simple goal of _"payable to whoever can generate a signature with the private key of this bitcoin address"_. With this output, Alice establishes a value of 0.015BTC "payable to Bob". Once this transaction is propagated on the network, included in a block and confirmed, Bob will be able to spend this output by constructing a transaction of his own.
|
|
|
|
[[script]]
|
|
==== Transaction Script
|
|
|
|
One of bitcoin's most powerful features is the ability to define the beneficiary of a transaction with a transaction scripting language that allows for very complex transactions and future enhancements. The bitcoin script language is Forth-like which means that it is a stack-based language. A stack is a logical construct that can be visualized as a stack of books. You can add one to the top, you can take one off the top. In a stack based language, values are added to a stack and then mathematical operations are applied to the items on that stack.
|
|
|
|
Here's a simple example, using a stack-language as a calculator. The script is evaluated from left to right. Numbers are added to the stack and operators manipulate them.
|
|
|
|
|
|
.Example of a calculator using a stack-based language
|
|
[options="header"]
|
|
|=======
|
|
| Stack| Script | Description
|
|
| empty | latexmath:[\(2 3 + 4 *\)] | Start
|
|
| 2 |latexmath:[\(3 + 4 *\)] | Number added to stack
|
|
| latexmath:[\(\begin{matrix}3\\2\end{matrix}\)]|latexmath:[\(+ 4 *\)] | Another number added to stack
|
|
| 5 |latexmath:[\(4 *\)] | Addition operator replaces top-two items with result
|
|
| latexmath:[\(\begin{matrix}4\\5\end{matrix}\)]|latexmath:[\(*\)]| Another number added to stack
|
|
| 20 | empty | Multiplication operator replaces top-two items with result
|
|
|=======
|
|
|
|
When the script starts, the number 2 is pushed onto the stack. In the second step, the number 3 is pushed on top of the stack. In the third step, the script reaches the oprator "+", which removes the two top values from the stack and replaces them with their sum. As we reach the fifth step, the stack contains the result of the previous calculations and the number 4 is added on top. Finally, the multiplier operator in the sixth step will remove the two topmost values and multiply them, putting the result on the top of the stack.
|
|
|
|
In bitcoin, the transaction script language has more complex operators than addition and multiplication, but otherwise operates in exactly the same way as the simple calculator example above. Examining the transaction above we see that Bob has an unspent output that is locked with the script +OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+. Bob must provide a _script signature_ or _scriptSig_ to unlock this output and spend it.
|
|
|
|
When a transaction is being validated, each of its inputs will be validated in turn to confirm that they are unspent and that they script signatures provided unlock these inputs. Each node in the bitcoin network can independently validate any transaction by combining the script signature and script and evaluating them using the stack processing language. If the end result evaluates as +TRUE+, then the transaction is valid.
|
|
|
|
|
|
Script signature: +<sig> <pubkey>+
|
|
|
|
Script: +OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+
|
|
|
|
|
|
.Evaluating a transaction input by combining the script signature and script
|
|
[options="header"]
|
|
|=======
|
|
| Stack| Script | Description
|
|
| empty | +<sig> <pubkey> OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+ | Start
|
|
| +<sig>+ | +<pubkey> OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+ | Push +<sig>+
|
|
| +<sig> <pubkey>+ | +OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+ | Push +<pubkey>+
|
|
| +<sig> <pubkey> <pubkey>+ | +OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG+ | Duplicate last item
|
|
| +<sig> <pubkey> <pubkey hash>+ | +<public key hash> OP_EQUALVERIFY OP_CHECKSIG+ | Hash last item
|
|
| +<sig> <pubkey> <pubkey hash> <public key hash>+ | +OP_EQUALVERIFY OP_CHECKSIG+ | Push +<public key hash>+
|
|
| +<sig> <pubkey>+ | +OP_CHECKSIG+ | Verify they are equal or stop (fail)
|
|
| +True+ | empty | Verify signature matches public key
|
|
|=======
|
|
|
|
|
|
The stack process above will first make a copy of the supplied public key and compare it's hash to the public key hash that was used to lock the previous output. If those match, the signature is verified by against the public key. This proves that the owner of the public key created this signature, therefore is authorised to spend the output.
|
|
|
|
=== The Blockchain
|
|
|
|
==== The Genesis Block
|
|
((("genesis block")))
|
|
|
|
The very first block mined, by Satoshi Nakamoto on Sat, 03 Jan 2009, is included in the source code of any "full node" client, as the basis for validating the entire blockchain.
|
|
((("blockchain")))
|
|
|
|
[TIP]
|
|
====
|
|
See the genesis block with blockexplorer:
|
|
https://blockexplorer.com/b/0
|
|
====
|
|
|
|
|
|
[[genesis_block_cpp]]
|
|
.The Genesis Block, statically encoded in the source code of the reference client https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L120[bitcoin/src/chainparams.cpp:line 120]
|
|
====
|
|
[source, c++]
|
|
----
|
|
const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"; <1>
|
|
CTransaction txNew;
|
|
txNew.vin.resize(1);
|
|
txNew.vout.resize(1);
|
|
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
|
|
txNew.vout[0].nValue = 50 * COIN; <2>
|
|
txNew.vout[0].scriptPubKey = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;
|
|
genesis.vtx.push_back(txNew);
|
|
genesis.hashPrevBlock = 0;
|
|
genesis.hashMerkleRoot = genesis.BuildMerkleTree();
|
|
genesis.nVersion = 1;
|
|
genesis.nTime = 1231006505; <3>
|
|
genesis.nBits = 0x1d00ffff;
|
|
genesis.nNonce = 2083236893;
|
|
|
|
----
|
|
<1> Message encoded into the transaction to provide date "anchoring" to a newspaper headline
|
|
<2> Reward of 50 bitcoins for mining the first block
|
|
<3> Unix time equivalent to - Sat, 03 Jan 2009 18:15:05 UTC
|
|
====
|
|
|
|
[[mining]]
|
|
=== Bitcoin Proof-of-Work (Mining)
|
|
((("Mining", "Proof of Work", "SHA256", "hashing power", "difficulty", "nonce")))
|
|
Bitcoin is secured through computation and consensus. For a new block of transactions to be added to the network, someone must first find a solution to a specific mathematical problem called the _proof of work_. Bitcoin's proof-of-work algorithm is based on the Secure Hash Algorithm (SHA-256) and consists of trying to generate a block whose hash is less than a specific number. Let's see how this works in practice.
|
|
|
|
A hashing algorithm is a cryptographic function that takes an arbitrary length input (a text message or binary file), and produce a fixed-size output called the _hash_ or _digest_. It is trivial to verify the hash of any input, but it is computationally infeasible to predict or select an input to produce a desired hash. It's a one-way function, so it can easily work one way but is impossible to reverse.
|
|
|
|
[[figure_sha256_logical]]
|
|
.The Secure Hash Algorithm (SHA-256)
|
|
image::images/sha256-logical.png["SHA256"]
|
|
|
|
With SHA-256, the output is always 256 bits long, regardless of the size of the input. In the example below, we will use the Python interpreter to calculate the SHA256 hash of the phrase "I am Satoshi Nakamoto".
|
|
|
|
[[sha256_example1]]
|
|
.SHA256 Example
|
|
++++
|
|
<screen>
|
|
$ python
|
|
Python 2.7.1
|
|
>>> <userinput>import hashlib</userinput>
|
|
>>> <userinput>print hashlib.sha256("I am Satoshi Nakamoto").hexdigest()</userinput>
|
|
5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e
|
|
</screen>
|
|
++++
|
|
|
|
|
|
The example shows that if we calculate the hash of the phrase +"I am Satoshi Nakamoto"+, it will produce +5d7c7ba21cbbcd75d14800b100252d5b428e5b1213d27c385bc141ca6b47989e+. This 256-bit number is the _hash_ or _digest_ of the phrase and depends on every part of the phrase. Adding a single letter, punctuation mark or any character will produce a different hash.
|
|
|
|
Now, if we vary the phrase, we will expect to see completely different hashes. Let's try that by adding a number to the end of our phrase, using this simple Python script
|
|
|
|
[[sha256_example_generator]]
|
|
.SHA256 A script for generating many hashes by iterating on a nonce
|
|
====
|
|
[source, python]
|
|
----
|
|
include::code/hash_example.py[]
|
|
----
|
|
====
|
|
|
|
Running this will produce the hashes of several phrases, made different by adding a unique number, called a _nonce_ at the end of the text. By incrementing the nonce, we can get different hadhes.
|
|
((("nonce")))
|
|
[[sha256_example_generator_output]]
|
|
.SHA256 Output of a script for generating many hashes by iterating on a nonce
|
|
====
|
|
++++
|
|
<screen>
|
|
$ <userinput>python hash_example.py</userinput>
|
|
I am Satoshi Nakamoto0 => a80a81401765c8eddee25df36728d732acb6d135bcdee6c2f87a3784279cfaed
|
|
I am Satoshi Nakamoto1 => f7bc9a6304a4647bb41241a677b5345fe3cd30db882c8281cf24fbb7645b6240
|
|
I am Satoshi Nakamoto2 => ea758a8134b115298a1583ffb80ae62939a2d086273ef5a7b14fbfe7fb8a799e
|
|
I am Satoshi Nakamoto3 => bfa9779618ff072c903d773de30c99bd6e2fd70bb8f2cbb929400e0976a5c6f4
|
|
I am Satoshi Nakamoto4 => bce8564de9a83c18c31944a66bde992ff1a77513f888e91c185bd08ab9c831d5
|
|
I am Satoshi Nakamoto5 => eb362c3cf3479be0a97a20163589038e4dbead49f915e96e8f983f99efa3ef0a
|
|
I am Satoshi Nakamoto6 => 4a2fd48e3be420d0d28e202360cfbaba410beddeebb8ec07a669cd8928a8ba0e
|
|
I am Satoshi Nakamoto7 => 790b5a1349a5f2b909bf74d0d166b17a333c7fd80c0f0eeabf29c4564ada8351
|
|
I am Satoshi Nakamoto8 => 702c45e5b15aa54b625d68dd947f1597b1fa571d00ac6c3dedfa499f425e7369
|
|
I am Satoshi Nakamoto9 => 7007cf7dd40f5e933cd89fff5b791ff0614d9c6017fbe831d63d392583564f74
|
|
I am Satoshi Nakamoto10 => c2f38c81992f4614206a21537bd634af717896430ff1de6fc1ee44a949737705
|
|
I am Satoshi Nakamoto11 => 7045da6ed8a914690f087690e1e8d662cf9e56f76b445d9dc99c68354c83c102
|
|
I am Satoshi Nakamoto12 => 60f01db30c1a0d4cbce2b4b22e88b9b93f58f10555a8f0f4f5da97c3926981c0
|
|
I am Satoshi Nakamoto13 => 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5
|
|
I am Satoshi Nakamoto14 => 27ead1ca85da66981fd9da01a8c6816f54cfa0d4834e68a3e2a5477e865164c4
|
|
I am Satoshi Nakamoto15 => 394809fb809c5f83ce97ab554a2812cd901d3b164ae93492d5718e15006b1db2
|
|
I am Satoshi Nakamoto16 => 8fa4992219df33f50834465d30474298a7d5ec7c7418e642ba6eae6a7b3785b7
|
|
I am Satoshi Nakamoto17 => dca9b8b4f8d8e1521fa4eaa46f4f0cdf9ae0e6939477e1c6d89442b121b8a58e
|
|
I am Satoshi Nakamoto18 => 9989a401b2a3a318b01e9ca9a22b0f39d82e48bb51e0d324aaa44ecaba836252
|
|
I am Satoshi Nakamoto19 => cda56022ecb5b67b2bc93a2d764e75fc6ec6e6e79ff6c39e21d03b45aa5b303a
|
|
</screen>
|
|
++++
|
|
====
|
|
|
|
Each phrase produces a completely different hash result. They seem completely random, but you can re-produce the exact results in this example on any computer with Python and see the same exact hashes.
|
|
|
|
To make a challenge out of this algorithm, let's set an arbitrary target: find a phrase starting with "I am Satoshi Nakamoto" which produces a hash that starts with a zero. In numerical terms, that means finding a hash value that is less than +0x1000000000000000000000000000000000000000000000000000000000000000+. Fortunately, this isn't so difficult! If you notice above, we can see that the phrase "I am Satoshi Nakamoto13" produces the hash 0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5, which fits our criteria. It only took 13 attempts to find it.
|
|
|
|
Bitcoin's proof-of-work is very similar to the problem above. First, a miner will generate a new block, containing:
|
|
((("block")))
|
|
* Transactions waiting to be included in a block
|
|
* The hash from the previous block
|
|
* A _nonce_
|
|
|
|
The only part a miner can modify is the nonce. Now, the miner will calculate the hash of this block's header and see if it is smaller than the current _target difficulty_. The miner will likely have to try many nonces before finding one that results in a low enough hash.
|
|
|
|
A very simplified proof-of-work algorithm is implemented in Python here:
|
|
((("proof of work")))
|
|
[[pow_example1]]
|
|
.Simplified Proof-Of-Work Implementation
|
|
====
|
|
[source, python]
|
|
----
|
|
include::code/proof-of-work-example.py[]
|
|
----
|
|
====
|
|
|
|
Running the code above, you can set the desired difficulty (in bits, how many of the leading bits must be zero) and see how long it takes for your computer to find a solution. In the following examples, you can see how it works on an average laptop:
|
|
|
|
[[pow_example_outputs]]
|
|
.Running the proof-of-work example for various difficulties
|
|
====
|
|
++++
|
|
<screen>
|
|
$ <userinput>python proof-of-work-example.py</userinput>
|
|
Difficulty: 1 (0 bits)
|
|
|
|
[...]
|
|
|
|
Difficulty: 8 (3 bits)
|
|
Starting search...
|
|
Success with nonce 9
|
|
Hash is 1c1c105e65b47142f028a8f93ddf3dabb9260491bc64474738133ce5256cb3c1
|
|
Elapsed Time: 0.0004 seconds
|
|
Hashing Power: 25065 hashes per second
|
|
Difficulty: 16 (4 bits)
|
|
Starting search...
|
|
Success with nonce 25
|
|
Hash is 0f7becfd3bcd1a82e06663c97176add89e7cae0268de46f94e7e11bc3863e148
|
|
Elapsed Time: 0.0005 seconds
|
|
Hashing Power: 52507 hashes per second
|
|
Difficulty: 32 (5 bits)
|
|
Starting search...
|
|
Success with nonce 36
|
|
Hash is 029ae6e5004302a120630adcbb808452346ab1cf0b94c5189ba8bac1d47e7903
|
|
Elapsed Time: 0.0006 seconds
|
|
Hashing Power: 58164 hashes per second
|
|
|
|
[...]
|
|
|
|
Difficulty: 4194304 (22 bits)
|
|
Starting search...
|
|
Success with nonce 1759164
|
|
Hash is 0000008bb8f0e731f0496b8e530da984e85fb3cd2bd81882fe8ba3610b6cefc3
|
|
Elapsed Time: 13.3201 seconds
|
|
Hashing Power: 132068 hashes per second
|
|
Difficulty: 8388608 (23 bits)
|
|
Starting search...
|
|
Success with nonce 14214729
|
|
Hash is 000001408cf12dbd20fcba6372a223e098d58786c6ff93488a9f74f5df4df0a3
|
|
Elapsed Time: 110.1507 seconds
|
|
Hashing Power: 129048 hashes per second
|
|
Difficulty: 16777216 (24 bits)
|
|
Starting search...
|
|
Success with nonce 24586379
|
|
Hash is 0000002c3d6b370fccd699708d1b7cb4a94388595171366b944d68b2acce8b95
|
|
Elapsed Time: 195.2991 seconds
|
|
Hashing Power: 125890 hashes per second
|
|
|
|
[...]
|
|
|
|
Difficulty: 67108864 (26 bits)
|
|
Starting search...
|
|
Success with nonce 84561291
|
|
Hash is 0000001f0ea21e676b6dde5ad429b9d131a9f2b000802ab2f169cbca22b1e21a
|
|
Elapsed Time: 665.0949 seconds
|
|
Hashing Power: 127141 hashes per second
|
|
|
|
</screen>
|
|
++++
|
|
====
|
|
|
|
As you can see, increasing the difficulty by 1 bit causes an exponential increase in the time it takes to find a solution. If you think of the entire 256-bit number space, each time you constrain one more bit to zero, you decrease the search space by half. In the example above, it takes 84 million hash attempts to find a nonce that produces a hash with 26 leading bits as zero. Even at a speed of more than 120 thousand hashes per second, it still requires ten minutes on a consumer laptop to find this solution.
|
|
|
|
At the time of writing this, the network is attempting to find a block whose header hash is less than +000000000000004c296e6376db3a241271f43fd3f5de7ba18986e517a243baa7+. As you can see, there are a lot of zeroes at the beginning of that hash, meaning that the acceptable range of hashes is much smaller, hence more difficult to find a valid hash. It will take on average more 150 quadrillion hash calculations per second for the network to discover the next block. That seems like an impossible task, but fortunately the network is bringing 500 TH/sec of processing power to bear, which will be able to find a block in about 10 minutes on average.
|
|
|
|
==== Diificulty Adjustment
|
|
|
|
Bitcoin is tuned to generate blocks approximately every 10 minutes. This is achieved by automatically adjusting the target difficulty to account for increases and decreases in the available computing power on the network. This process occurs automatically and on every node independently. Each node recalculates the expected difficulty every 2106 blocks, based on the time it took to hash the previous 2106 blocks. In simple terms: If the network is finding blocks faster than every 10 minutes, the difficulty increases. If block discovery is slower than expected, the difficulty will decrease.
|
|
|
|
[TIP]
|
|
====
|
|
The difficulty of finding a bitcoin block is approximately '10 minutes of processing' for the entire network, based on the time it took to find the previous 2106 blocks, adjusted every 2106 blocks. If you know the processing power of the network in hashes per second, you can calculate how many hashes per 10 minutes, which is how many on avergae to find a block, ie. the current difficulty.
|
|
====
|
|
|
|
=== Transaction Fees
|
|
|
|
Transaction fees are implicit in bitcoin transactions. Each transaction contains some _inputs_ which carry the value from previous transactions and some _outputs_ which represent new value given to recipients. The sum of the output value is always less than or equal to the sum of the input values. The difference, if any, is the transaction fee. Each block has a generating transaction (the first one) which assigns the reward to the miner. The transaction fees, represented by the sum of all excess input values from all transactions in the block, is added to the reward in the generating transaction and also claimed by the miner. In 2013, transaction fees represent only a small fraction of the block reward, but over time as the reward halves, transaction fees become a bigger part of the total. After all bitcoins mined, the only reward to miners will be in the form of transaction fees.
|
|
|
|
Transaction fees determine how soon a transaction is included in a newly mined block. Miners create new blocks by bundling transactions that are not yet verified, usually selecting the highest-fee-per-kilobyte transactions first. This simple selection algorithm ensures that transactions with higher-than-average fees are included first. The transaction fee is essentially a way of rewarding fast processing of transactions. A transaction without a fee might be included in a block on a best-effort basis, but is not guarranteed to be included.
|
|
|
|
Transaction fees are set in the client that creates a transaction. Most clients include a minimum fee, set as a constant in the client application. The minimum fee accepted by most miners is 0.0005 bitcoin, or 0.5 millibits.
|
|
|
|
|
|
=== Currency exchange
|
|
|
|
[[complex_transactions]]
|
|
=== Complex transactions
|
|
|
|
The transaction script language is extremely versatile and is a big part of what makes bitcoin flexible and open to innovation. The vast majority of transactions include a very simple script that transfers control of some bitcoin value from one set of keys (buyer) to another set of keys (seller), the equivalent of "Alice pays Bob 15 millibits".
|
|
|
|
Far more complex transactions can be encoded in the script language, representing more complex redemption criteria. Instead of requiring a digital signature to spend the transaction (ie. Bob's signature in the above example), we can create transactions that require multiple signatures, time delays, or even solutions to mathematical puzzles.
|
|
|
|
|
|
|
|
|
|
=== Peer-to-peer protocol
|
|
=== Transaction pool
|
|
=== Double-spend protection
|
|
|
|
=== Finite monetary supply
|
|
|
|
There will never be more than 21 million bitcoins. The bitcoin currency is designed to have a strictly limited monetary supply. In the first four years of bitcoin's existence, more than 50% of the total coins have already been created. The rest will be mined in an exponentially decreasing rate, until 2140 after which time no more bitcoins will be created.
|
|
|
|
A limited monetary supply has very important economic implications for a currency. Limited supply makes bitcoin *a deflationary currency*.
|
|
|
|
=== Reward reduction
|
|
|
|
Bitcoins are created, or "minted", by miners. Each block, the lucky miner who found a solution, receives newly created bitcoins as a reward. The reward rate started at 50 bitcoins per block in 2009 and is automatically halved every 840,000 blockes, or approximately every 4 years if blocks are created on average every 10 minutes.
|
|
|
|
The first halving occured in November of 2012, at which point the reward was automatically reduced from 50BTC to 25BTC. In 2016, the reward will drop to 12.5 BTC and so-on. With the reward cut in half every 4 years, by approximatelly 2140 all 21 million bitcoins will be mined. After that, no more bitcoins will ever be created.
|
|
|
|
Miners make money through the reward and the transaction fees that are included in each block. At the moment, the fees are negligible and the reward is the primary motivation for mining. Over time, the transaction fees will become a larger and larger part of the miner incentives, until there is no reward in new block. Then, miners will earn money only from transaction fees.
|
|
|
|
.Bitcoin issuance gets slower over time, as it approaches the maximum 21 million bitcoins to be issued.
|
|
image::images/740px-Total_bitcoins_over_time_graph.png["Bitcoins issued as mining rewards, over time"]
|
|
|
|
=== Divisibility and deflation
|
|
|
|
|
|
|
|
=== Full node client
|
|
=== Overlay networks (Stratum)
|
|
=== Light-weight clients
|
|
=== Offline processing
|
|
=== Hardware clients
|
|
=== Brain wallets
|
|
=== Paper wallets
|
|
|
|
|
|
[[ch03_consumers]]
|
|
== Using bitcoin as a consumer
|
|
|
|
This chapter introduces bitcoin from the perspective of a consumer. The goal is to show a user how to adopt bitcoin as a working currency for daily transactions, savings and money transfer. This chapter is illustrated at a graphical and workflow level and does not contain code or command-line.
|
|
|
|
=== Transactions
|
|
=== Anonymity and address "taint"
|
|
=== Recycling addresses
|
|
=== Identity Verification
|
|
=== Transaction non-reversal
|
|
=== Vanity addresses
|
|
|