mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
Merge branch 'am_review' into develop
This commit is contained in:
Andreas M. Antonopoulos
commit
4b894c232c
132
appdx-sx.asciidoc
Normal file
132
appdx-sx.asciidoc
Normal file
@ -0,0 +1,132 @@
|
|||||||
|
[[sx_cmds]]
|
||||||
|
== Appendix: Available commands with sx tools
|
||||||
|
|
||||||
|
----
|
||||||
|
The sx commands are:
|
||||||
|
|
||||||
|
DEPRECATED
|
||||||
|
ELECTRUM STYLE DETERMINISTIC KEYS AND ADDRESSES
|
||||||
|
genaddr Generate a Bitcoin address deterministically from a wallet
|
||||||
|
seed or master public key.
|
||||||
|
genpriv Generate a private key deterministically from a seed.
|
||||||
|
genpub Generate a public key deterministically from a wallet
|
||||||
|
seed or master public key.
|
||||||
|
mpk Extract a master public key from a deterministic wallet seed.
|
||||||
|
newseed Create a new deterministic wallet seed.
|
||||||
|
|
||||||
|
EXPERIMENTAL
|
||||||
|
APPS
|
||||||
|
wallet Experimental command line wallet.
|
||||||
|
|
||||||
|
OFFLINE BLOCKCHAIN
|
||||||
|
HEADERS
|
||||||
|
showblkhead Show the details of a block header.
|
||||||
|
|
||||||
|
OFFLINE KEYS AND ADDRESSES
|
||||||
|
BASIC
|
||||||
|
addr See Bitcoin address of a public or private key.
|
||||||
|
embed-addr Generate an address used for embedding record of data into the blockchain
|
||||||
|
get-pubkey Get the pubkey of an address if available
|
||||||
|
newkey Create a new private key.
|
||||||
|
pubkey See the public part of a private key.
|
||||||
|
validaddr Validate an address.
|
||||||
|
BRAIN STORAGE
|
||||||
|
brainwallet Make 256 bit bitcoin private key from an arbitrary passphrase.
|
||||||
|
mnemonic Make 12 word mnemonic out of 128 bit electrum or bip32 seed.
|
||||||
|
HD / BIP32
|
||||||
|
hd-priv Create an private HD key from another HD private key.
|
||||||
|
hd-pub Create an HD public key from another HD private or public key.
|
||||||
|
hd-seed Create a random new HD key.
|
||||||
|
hd-to-address Convert an HD public or private key to a Bitcoin address.
|
||||||
|
hd-to-wif Convert an HD private key to a WIF private key.
|
||||||
|
MULTISIG ADDRESSES
|
||||||
|
scripthash Create BIP 16 script hash address from raw script hex.
|
||||||
|
STEALTH
|
||||||
|
stealth-addr See a stealth address from given input.
|
||||||
|
stealth-initiate Initiate a new stealth payment.
|
||||||
|
stealth-newkey Generate new stealth keys and an address.
|
||||||
|
stealth-show-addr Show details for a stealth address.
|
||||||
|
stealth-uncover Uncover a stealth address.
|
||||||
|
stealth-uncover-secret Uncover a stealth secret.
|
||||||
|
|
||||||
|
OFFLINE TRANSACTIONS
|
||||||
|
SCRIPTING
|
||||||
|
mktx Create an unsigned tx.
|
||||||
|
rawscript Create the raw hex representation from a script.
|
||||||
|
set-input Set a transaction input.
|
||||||
|
showscript Show the details of a raw script.
|
||||||
|
showtx Show the details of a transaction.
|
||||||
|
sign-input Sign a transaction input.
|
||||||
|
unwrap Validates checksum and recovers version byte and original data from hexstring.
|
||||||
|
validsig Validate a transaction input's signature.
|
||||||
|
wrap Adds version byte and checksum to hexstring.
|
||||||
|
|
||||||
|
ONLINE (BITCOIN P2P)
|
||||||
|
BLOCKCHAIN UPDATES
|
||||||
|
sendtx-node Send transaction to a single node.
|
||||||
|
sendtx-p2p Send tx to bitcoin network.
|
||||||
|
|
||||||
|
ONLINE (BLOCKCHAIN.INFO)
|
||||||
|
BLOCKCHAIN QUERIES (blockchain.info)
|
||||||
|
bci-fetch-last-height Fetch the last block height using blockchain.info.
|
||||||
|
bci-history Get list of output points, values, and their spends
|
||||||
|
from blockchain.info
|
||||||
|
BLOCKCHAIN UPDATES
|
||||||
|
sendtx-bci Send tx to blockchain.info/pushtx.
|
||||||
|
|
||||||
|
ONLINE (BLOCKEXPLORER.COM)
|
||||||
|
BLOCKCHAIN QUERIES (blockexplorer.com)
|
||||||
|
blke-fetch-transaction Fetches a transaction from blockexplorer.com
|
||||||
|
|
||||||
|
ONLINE (OBELISK)
|
||||||
|
BLOCKCHAIN QUERIES
|
||||||
|
balance Show balance of a Bitcoin address in satoshis.
|
||||||
|
fetch-block-header Fetch raw block header.
|
||||||
|
fetch-last-height Fetch the last block height.
|
||||||
|
fetch-stealth Fetch a stealth information using a network connection to
|
||||||
|
make requests against the obelisk load balancer backend.
|
||||||
|
fetch-transaction Fetch a raw transaction using a network connection to
|
||||||
|
make requests against the obelisk load balancer backend.
|
||||||
|
fetch-transaction-index Fetch block height and index in block of transaction.
|
||||||
|
get-utxo Get enough unspent transaction outputs from a given set of
|
||||||
|
addresses to pay a given number of satoshis
|
||||||
|
history Get list of output points, values, and their spends for an
|
||||||
|
address. grep can filter for just unspent outputs which can
|
||||||
|
be fed into mktx.
|
||||||
|
validtx Validate a transaction.
|
||||||
|
BLOCKCHAIN UPDATES
|
||||||
|
sendtx-obelisk Send tx to obelisk server.
|
||||||
|
BLOCKCHAIN WATCHING
|
||||||
|
monitor Monitor an address.
|
||||||
|
watchtx Watch transactions from the network searching for a certain hash.
|
||||||
|
OBELISK ADMIN
|
||||||
|
initchain Initialize a new blockchain.
|
||||||
|
|
||||||
|
UTILITY
|
||||||
|
EC MATH
|
||||||
|
ec-add-modp Calculate the result of INTEGER + INTEGER.
|
||||||
|
ec-multiply Multiply an integer and a point together.
|
||||||
|
ec-tweak-add Calculate the result of POINT + INTEGER * G.
|
||||||
|
FORMAT (BASE 58)
|
||||||
|
base58-decode Convert from base58 to hex
|
||||||
|
base58-encode Convert from hex to base58
|
||||||
|
FORMAT (BASE58CHECK)
|
||||||
|
base58check-decode Convert from base58check to hex
|
||||||
|
base58check-encode Convert from hex to base58check
|
||||||
|
decode-addr Decode a address from base58check form to internal RIPEMD representation
|
||||||
|
encode-addr Encode an address from internal RIPEMD representation to base58check form
|
||||||
|
FORMAT (WIF)
|
||||||
|
secret-to-wif Convert a secret exponent value to Wallet Import Format
|
||||||
|
wif-to-secret Convert a Wallet Import Format to secret exponent value.
|
||||||
|
HASHES
|
||||||
|
ripemd-hash RIPEMD hash data from STDIN.
|
||||||
|
sha256 Perform SHA256 hash of data.
|
||||||
|
MISC
|
||||||
|
qrcode Generate Bitcoin QR codes offline.
|
||||||
|
SATOSHI MATH
|
||||||
|
btc Convert Satoshis into Bitcoins.
|
||||||
|
satoshi Convert Bitcoins into Satoshis.
|
||||||
|
|
||||||
|
See 'sx help COMMAND' for more information on a specific command.
|
||||||
|
|
||||||
|
----
|
||||||
@ -17,7 +17,8 @@ Behind the scenes, bitcoin is also the name of the protocol, a network and a dis
|
|||||||
|
|
||||||
In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software and using bitcoin for simple transactions. In following chapters we'll start unwrapping the layers of technology that make bitcoin possible and examine the inner workings of the bitcoin network and protocol.
|
In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software and using bitcoin for simple transactions. In following chapters we'll start unwrapping the layers of technology that make bitcoin possible and examine the inner workings of the bitcoin network and protocol.
|
||||||
|
|
||||||
=== Before Bitcoin
|
.Digital Currencies Before Bitcoin
|
||||||
|
****
|
||||||
|
|
||||||
The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Two fundamental questions for anyone accepting digital money are:
|
The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Two fundamental questions for anyone accepting digital money are:
|
||||||
|
|
||||||
@ -37,6 +38,8 @@ Bitcoin represents the culmination of decades of research in cryptography and di
|
|||||||
* A de-centralized mathematical and deterministic currency issuance (distributed mining), and;
|
* A de-centralized mathematical and deterministic currency issuance (distributed mining), and;
|
||||||
* A de-centralized transaction verification system (transaction script).
|
* A de-centralized transaction verification system (transaction script).
|
||||||
|
|
||||||
|
****
|
||||||
|
|
||||||
=== History of Bitcoin
|
=== History of Bitcoin
|
||||||
|
|
||||||
Bitcoin was invented in 2008 by Satoshi Nakamoto with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System". Satoshi Nakamoto combined several prior inventions such as b-money and HashCash to create a completely de-centralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. The key innovation was to use a distributed computation system (called a "Proof-Of-Work" algorithm) to conduct a global "election" every 10 minutes, allowing the de-centralized network to arrive at _consensus_ about the state of transactions. This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse.
|
Bitcoin was invented in 2008 by Satoshi Nakamoto with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System". Satoshi Nakamoto combined several prior inventions such as b-money and HashCash to create a completely de-centralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. The key innovation was to use a distributed computation system (called a "Proof-Of-Work" algorithm) to conduct a global "election" every 10 minutes, allowing the de-centralized network to arrive at _consensus_ about the state of transactions. This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse.
|
||||||
@ -91,7 +94,7 @@ Web Client:: Web-clients are accessed through a web browser and store the user's
|
|||||||
|
|
||||||
.Mobile Bitcoin
|
.Mobile Bitcoin
|
||||||
****
|
****
|
||||||
Mobile clients for smartphones, such as those based on the Android system, can either operate as full clients, light clients or web clients. Some mobile clients are synchronized with a web or desktop client, providing a multi-platform wallet across multiple devices but with a common source of funds. See <<mobile_bitcoin>>
|
Mobile clients for smartphones, such as those based on the Android system, can either operate as full clients, light clients or web clients. Some mobile clients are synchronized with a web or desktop client, providing a multi-platform wallet across multiple devices but with a common source of funds.
|
||||||
****
|
****
|
||||||
|
|
||||||
The choice of bitcoin client depends on how much control the user wants over funds. A full client will offer the highest level of control and independence for the user, but in turn puts the burden of backups and security on the user. On the other end of the range of choices, a web client is the easiest to set up and use, but the tradeoff with a web client is that counterparty risk is introduced because security and control is shared by the user and the owner of the web service. If a web-wallet service is compromised, as many have been, the users can lose all their funds. Conversely, if a user has a full client without adequate backups, they may lose their funds through a computer mishap.
|
The choice of bitcoin client depends on how much control the user wants over funds. A full client will offer the highest level of control and independence for the user, but in turn puts the burden of backups and security on the user. On the other end of the range of choices, a web client is the easiest to set up and use, but the tradeoff with a web client is that counterparty risk is introduced because security and control is shared by the user and the owner of the web service. If a web-wallet service is compromised, as many have been, the users can lose all their funds. Conversely, if a user has a full client without adequate backups, they may lose their funds through a computer mishap.
|
||||||
@ -152,9 +155,10 @@ There are three other methods for getting bitcoins as a new user:
|
|||||||
|
|
||||||
Alice was introduced to bitcoin by a friend and so she has an easy way of getting her first bitcoin while she waits for her account on a California currency market to be verified and activated.
|
Alice was introduced to bitcoin by a friend and so she has an easy way of getting her first bitcoin while she waits for her account on a California currency market to be verified and activated.
|
||||||
|
|
||||||
==== Sending and receiving bitcoins
|
[[sending_receiving]]
|
||||||
|
==== Sending and receiving bitcoins
|
||||||
|
|
||||||
Alice has created her bitcoin wallet and she is now ready to receive funds. Her wallet application randomly generated a bitcoin address together with its corresponding key (an elliptic curve private key, described in more detail in <<private keys>>). At this point, her bitcoin address is not known to the bitcoin network or "registered" with any part of the bitcoin system. Her bitcoin address is simply a number that corresponds to a key that she can use to control access to the funds. There is no account or association between that address and an account. Until the moment this address is referenced as the recipient of value in a transaction posted on the bitcoin ledger (the blockchain), it is simply part of the vast number of possible addresses that are "valid" in bitcoin. Once it has been associated with a transaction, it becomes part of the known addresses in the network and Alice can check its balance on the public ledger.
|
Alice has created her bitcoin wallet and she is now ready to receive funds. Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) together with its corresponding bitcoin address. At this point, her bitcoin address is not known to the bitcoin network or "registered" with any part of the bitcoin system. Her bitcoin address is simply a number that corresponds to a key that she can use to control access to the funds. There is no account or association between that address and an account. Until the moment this address is referenced as the recipient of value in a transaction posted on the bitcoin ledger (the blockchain), it is simply part of the vast number of possible addresses that are "valid" in bitcoin. Once it has been associated with a transaction, it becomes part of the known addresses in the network and Alice can check its balance on the public ledger.
|
||||||
|
|
||||||
Alice meets her friend Joe who introduced her to bitcoin at a local restaurant so they can exchange some US dollars and put some bitcoins into her account. She has brought a printout of her address and the QR code as displayed in her bitcoin wallet. There is nothing sensitive, from a security perspective, about the bitcoin address. It can be posted anywhere without risking the security of her account.
|
Alice meets her friend Joe who introduced her to bitcoin at a local restaurant so they can exchange some US dollars and put some bitcoins into her account. She has brought a printout of her address and the QR code as displayed in her bitcoin wallet. There is nothing sensitive, from a security perspective, about the bitcoin address. It can be posted anywhere without risking the security of her account.
|
||||||
|
|
||||||
|
|||||||
@ -19,15 +19,16 @@ Each of these has a search function that can take an address, transaction hash o
|
|||||||
|
|
||||||
==== Bitcoin Overview
|
==== Bitcoin Overview
|
||||||
|
|
||||||
In the overview diagram below, we see that the bitcoin system consists of users with wallets containing keys, transactions which are propagated across the network and miners who produce (through competitive computation) the consensus blockchain, the authoritative ledger of all transactions. In this chapter, we will trace a single transaction as it travels across the network and examine the interactions between each part of the bitcoin system, at a high level. Subsequent chapters will delve deeper into the technology behind wallets, mining and merchant systems.
|
In the overview diagram below, we see that the bitcoin system consists of users with wallets containing keys, transactions which are propagated across the network and miners who produce (through competitive computation) the consensus blockchain, the authoritative ledger of all transactions. In this chapter, we will trace a single transaction as it travels across the network and examine the interactions between each part of the bitcoin system, at a high level. Subsequent chapters will delve into the technology behind wallets, mining and merchant systems.
|
||||||
|
|
||||||
[[bitcoin-overview]]
|
[[bitcoin-overview]]
|
||||||
.Bitcoin Overview
|
.Bitcoin Overview
|
||||||
image::images/Bitcoin_Overview.png["Bitcoin Overview"]
|
image::images/Bitcoin_Overview.png["Bitcoin Overview"]
|
||||||
|
|
||||||
|
[[cup_of_coffee]]
|
||||||
==== Buying a cup of coffee
|
==== Buying a cup of coffee
|
||||||
|
|
||||||
Alice, introduced in the previous chapter, is a new user who has just acquired her first bitcoin. In <<getting_first_bitcoin>>, Alice met with her friend Joe to exchange some cash for bitcoin. The transaction created by Joe, funded Alice's wallet with 0.10 BTC. Now Alice will make her first retail transaction, buying a cup of coffee at Bob's coffee shop in Palo Alto, California. Bob's coffee shop recently started accepting bitcoin payments, by adding a bitcoin option to his point-of-sale system (see <<bitcoin_for_merchants>> for information on using bitcoin for merchants/retail). The prices at Bob's Cafe are listed in the local currency (US dollars) but at the register, customers have the option of paying in either dollars or bitcoin. Alice places her order for a cup of coffee and Bob enters the transaction at the register. The point-of-sale system will convert the total price from US dollars to bitcoins at the prevailing market rate and display the prices in both currencies, as well as showing a QR code containing a _payment request_ for this transaction:
|
Alice, introduced in the previous chapter, is a new user who has just acquired her first bitcoin. In <<getting_first_bitcoin>>, Alice met with her friend Joe to exchange some cash for bitcoin. The transaction created by Joe, funded Alice's wallet with 0.10 BTC. Now Alice will make her first retail transaction, buying a cup of coffee at Bob's coffee shop in Palo Alto, California. Bob's coffee shop recently started accepting bitcoin payments, by adding a bitcoin option to his point-of-sale system. The prices at Bob's Cafe are listed in the local currency (US dollars) but at the register, customers have the option of paying in either dollars or bitcoin. Alice places her order for a cup of coffee and Bob enters the transaction at the register. The point-of-sale system will convert the total price from US dollars to bitcoins at the prevailing market rate and display the prices in both currencies, as well as showing a QR code containing a _payment request_ for this transaction:
|
||||||
|
|
||||||
.Displayed on Bob's cash register
|
.Displayed on Bob's cash register
|
||||||
----
|
----
|
||||||
@ -59,7 +60,7 @@ A description for the payment: "Purchase at Bob's Cafe"
|
|||||||
|
|
||||||
[TIP]
|
[TIP]
|
||||||
====
|
====
|
||||||
Unlike a QR code that simply contains a destination bitcoin address, a "payment request" is a QR encoded URL that contains a destination address, a payment amount and a generic description such as "Bob's Cafe". This allows a bitcoin wallet application to pre-fill the information used to send the payment while showing a human-readable description to the user. See <<payment request URL>>, for more details. You can scan the QR code above with a bitcoin wallet application to see what Alice would see.
|
Unlike a QR code that simply contains a destination bitcoin address, a "payment request" is a QR encoded URL that contains a destination address, a payment amount and a generic description such as "Bob's Cafe". This allows a bitcoin wallet application to pre-fill the information used to send the payment while showing a human-readable description to the user. You can scan the QR code above with a bitcoin wallet application to see what Alice would see.
|
||||||
====
|
====
|
||||||
|
|
||||||
Bob says "That's one-dollar-fifty, or fifteen milliBits".
|
Bob says "That's one-dollar-fifty, or fifteen milliBits".
|
||||||
@ -70,7 +71,7 @@ In the following sections we will examine this transaction in more detail, see h
|
|||||||
|
|
||||||
[NOTE]
|
[NOTE]
|
||||||
====
|
====
|
||||||
The bitcoin network can transact in fractional values, e.g. from millibitcoins (1/1000th of a bitcoin) down to 1/100,000,000th of a bitcoin, which is known as a Satoshi. Throughout this book we’ll use the term “bitcoins” to refer to any quantity of bitcoin currency, from the smallest unit (1 Satoshi) to the total number (21,000,000) of all bitcoins that will ever be mined.
|
The bitcoin network can transact in fractional values, e.g. from milli-bitcoins (1/1000th of a bitcoin) down to 1/100,000,000th of a bitcoin, which is known as a Satoshi. Throughout this book we’ll use the term “bitcoins” to refer to any quantity of bitcoin currency, from the smallest unit (1 Satoshi) to the total number (21,000,000) of all bitcoins that will ever be mined.
|
||||||
====
|
====
|
||||||
|
|
||||||
|
|
||||||
@ -125,14 +126,17 @@ Alice's wallet application contains all the logic for selecting appropriate inpu
|
|||||||
|
|
||||||
==== Getting the right inputs
|
==== Getting the right inputs
|
||||||
|
|
||||||
Alice's wallet application will first have to find inputs that can pay for the amount she wants to send to Bob. Most wallet applications keep a small database of "unspent transaction outputs" that are locked (encumbered) with the wallet's own keys. Therefore, Alice's wallet would contain a copy of the transaction output from Joe's transaction which was created in exchange for cash (see <<getting bitcoin>>). A bitcoin wallet application that runs as a full-index client actually contains a copy of every unspent output from every transaction in the blockchain. This allows a wallet to construct transaction inputs as well as to quickly verify incoming transactions as having correct inputs. However, since a full-index client takes up a lot of disk space, most user wallets run "lightweight" clients that track only the user's own unspent outputs.
|
Alice's wallet application will first have to find inputs that can pay for the amount she wants to send to Bob. Most wallet applications keep a small database of "unspent transaction outputs" that are locked (encumbered) with the wallet's own keys. Therefore, Alice's wallet would contain a copy of the transaction output from Joe's transaction which was created in exchange for cash (see <<getting_first_bitcoin>>). A bitcoin wallet application that runs as a full-index client actually contains a copy of every unspent output from every transaction in the blockchain. This allows a wallet to construct transaction inputs as well as to quickly verify incoming transactions as having correct inputs. However, since a full-index client takes up a lot of disk space, most user wallets run "lightweight" clients that track only the user's own unspent outputs.
|
||||||
|
|
||||||
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 an 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:
|
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 an 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:
|
||||||
|
|
||||||
.Look up all the unspent outputs for Alice's bitcoin address
|
.Look up all the unspent outputs for Alice's bitcoin address
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
|
$ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
|
----
|
||||||
{
|
{
|
||||||
|
|
||||||
"unspent_outputs":[
|
"unspent_outputs":[
|
||||||
@ -151,7 +155,7 @@ $ curl https://blockchain.info/unspent?active=1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK
|
|||||||
}
|
}
|
||||||
----
|
----
|
||||||
|
|
||||||
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 its 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.
|
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 its 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.
|
||||||
|
|
||||||
[TIP]
|
[TIP]
|
||||||
====
|
====
|
||||||
@ -242,7 +246,7 @@ image::images/Blockchain_height_and_depth.png["Alice's transaction included in a
|
|||||||
|
|
||||||
=== Spending the transaction
|
=== Spending the transaction
|
||||||
|
|
||||||
Now that Alice's transaction has been embedded in the blockchain as part of a block, it is part of the distributed ledger of bitcoin and visible to all bitcoin applications. Each bitcoin client can independently verify the transaction as valid and spendable. Full-index clients can track the source of the funds from the moment the bitcoins were first generated in a block, incrementally from transaction to transaction, until they reach Bob's address. Lightweight clients can do a Simplified Payment Verification (See SPV:<<spv>>) by confirming that the transaction is in the blockchain and has several blocks mined after it, thus providing assurance that the network accepts it as valid.
|
Now that Alice's transaction has been embedded in the blockchain as part of a block, it is part of the distributed ledger of bitcoin and visible to all bitcoin applications. Each bitcoin client can independently verify the transaction as valid and spendable. Full-index clients can track the source of the funds from the moment the bitcoins were first generated in a block, incrementally from transaction to transaction, until they reach Bob's address. Lightweight clients can do a Simplified Payment Verification (See <<spv_nodes>>) by confirming that the transaction is in the blockchain and has several blocks mined after it, thus providing assurance that the network accepts it as valid.
|
||||||
|
|
||||||
Bob can now spend the output from this and other transactions, by creating his own transactions that reference these outputs as their inputs and assign them new ownership. For example, Bob can pay a contractor or supplier by transferring value from Alice's coffee cup payment to these new owners. Most likely, Bob's bitcoin software will aggregate many small payments into a larger payment, perhaps concentrating all the day's bitcoin revenue into a single transaction. This would move the various payments into a single address, utilized as the store's general "checking" account. For a diagram of an aggregating transaction, see <<transaction-aggregating>>.
|
Bob can now spend the output from this and other transactions, by creating his own transactions that reference these outputs as their inputs and assign them new ownership. For example, Bob can pay a contractor or supplier by transferring value from Alice's coffee cup payment to these new owners. Most likely, Bob's bitcoin software will aggregate many small payments into a larger payment, perhaps concentrating all the day's bitcoin revenue into a single transaction. This would move the various payments into a single address, utilized as the store's general "checking" account. For a diagram of an aggregating transaction, see <<transaction-aggregating>>.
|
||||||
|
|
||||||
|
|||||||
441
ch03.asciidoc
441
ch03.asciidoc
@ -1,9 +1,9 @@
|
|||||||
[[ch03_bitcoin_client]]
|
[[ch03_bitcoin_client]]
|
||||||
== The Bitcoin Client
|
== The Bitcoin Client
|
||||||
|
|
||||||
=== Bitcoin Core - The Reference Implementation, aka Satoshi Client
|
=== Bitcoin Core - The reference implementation
|
||||||
|
|
||||||
You can download the Reference Client, also known as _Bitcoin Core_ from bitcoin.org. The reference client implements all aspects of the bitcoin system, including wallets, a transaction verification engine with a full copy of the entire transaction ledger (blockchain) and a full network node in the peer-to-peer bitcoin network.
|
You can download the Reference Client _Bitcoin Core_, also known as the "Satoshi client", from bitcoin.org. The reference client implements all aspects of the bitcoin system, including wallets, a transaction verification engine with a full copy of the entire transaction ledger (blockchain) and a full network node in the peer-to-peer bitcoin network.
|
||||||
|
|
||||||
Go to http://bitcoin.org/en/choose-your-wallet and select "Bitcoin Core" to download the reference client. Depending on your operating system, you will download an executable installer. For Windows, this is either a ZIP archive or an EXE executable. For Mac OS it is a DMG disk image. Linux versions include a PPA package for Ubuntu or a TAR.GZ archive.
|
Go to http://bitcoin.org/en/choose-your-wallet and select "Bitcoin Core" to download the reference client. Depending on your operating system, you will download an executable installer. For Windows, this is either a ZIP archive or an EXE executable. For Mac OS it is a DMG disk image. Linux versions include a PPA package for Ubuntu or a TAR.GZ archive.
|
||||||
|
|
||||||
@ -11,7 +11,7 @@ Go to http://bitcoin.org/en/choose-your-wallet and select "Bitcoin Core" to down
|
|||||||
.Bitcoin - Choose A Bitcoin Client
|
.Bitcoin - Choose A Bitcoin Client
|
||||||
image::images/bitcoin-choose-client.png["bitcoin choose client"]
|
image::images/bitcoin-choose-client.png["bitcoin choose client"]
|
||||||
|
|
||||||
==== Bitcoin Core - Running the client for the first time
|
==== Running Bitcoin Core for the first time
|
||||||
|
|
||||||
If you download an installable package, such as an EXE, DMG or PPA, you can install it the same way as any application on your operating system. For Windows, run the EXE and follow the step-by-step instructions. For Mac OS, launch the DMG and drag the Bitcoin-QT icon into your Applications folder. For Ubuntu, double-click on the PPA in your File Explorer and it will open the package manager to install the package. Once you have completed installation you should have a new application "Bitcoin-Qt" in your application list. Double-click on the icon to start the bitcoin client.
|
If you download an installable package, such as an EXE, DMG or PPA, you can install it the same way as any application on your operating system. For Windows, run the EXE and follow the step-by-step instructions. For Mac OS, launch the DMG and drag the Bitcoin-QT icon into your Applications folder. For Ubuntu, double-click on the PPA in your File Explorer and it will open the package manager to install the package. Once you have completed installation you should have a new application "Bitcoin-Qt" in your application list. Double-click on the icon to start the bitcoin client.
|
||||||
|
|
||||||
@ -27,10 +27,11 @@ Bitcoin Core keeps a full copy of the transaction ledger (blockchain), with ever
|
|||||||
image::images/bitcoin-qt-firstload.png["bitcoin-qt first run"]
|
image::images/bitcoin-qt-firstload.png["bitcoin-qt first run"]
|
||||||
|
|
||||||
|
|
||||||
==== Bitcoin Core - Compiling the client from the source code
|
==== Compiling Bitcoin Core from the source code
|
||||||
|
|
||||||
For developers, there is also the option to download the full source code as a ZIP archive or by cloning the authoritative source repository from Github. Go to https://github.com/bitcoin/bitcoin and select "Download ZIP" from the sidebar. Alternatively, use the git command line to create a local copy of the source code on your system. In the example below, we are cloning the source code from a unix-like command-line, in Linux or Mac OS:
|
For developers, there is also the option to download the full source code as a ZIP archive or by cloning the authoritative source repository from Github. Go to https://github.com/bitcoin/bitcoin and select "Download ZIP" from the sidebar. Alternatively, use the git command line to create a local copy of the source code on your system. In the example below, we are cloning the source code from a unix-like command-line, in Linux or Mac OS:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ git clone https://github.com/bitcoin/bitcoin.git
|
$ git clone https://github.com/bitcoin/bitcoin.git
|
||||||
Cloning into 'bitcoin'...
|
Cloning into 'bitcoin'...
|
||||||
@ -49,12 +50,14 @@ The instructions and resulting output may vary from version to version. Follow t
|
|||||||
|
|
||||||
When the git cloning operation has completed, you will have a complete local copy of the source code repository in the directory _bitcoin_. Change to this directory by typing +cd bitcoin+ at the prompt:
|
When the git cloning operation has completed, you will have a complete local copy of the source code repository in the directory _bitcoin_. Change to this directory by typing +cd bitcoin+ at the prompt:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ cd bitcoin
|
$ cd bitcoin
|
||||||
----
|
----
|
||||||
|
|
||||||
By default, the local copy will be synchronized with the most recent code, which may be an unstable or "beta" version of bitcoin. Before compiling the code, we want to select a specific version by checking out a release _tag_. This will synchronize the local copy with a specific snapshot of the code repository identified by a keyword tag. Tags are used by the developers to mark specific releases of the code by version number. First, to find the available tags, we use the +git tag+ command:
|
By default, the local copy will be synchronized with the most recent code, which may be an unstable or "beta" version of bitcoin. Before compiling the code, we want to select a specific version by checking out a release _tag_. This will synchronize the local copy with a specific snapshot of the code repository identified by a keyword tag. Tags are used by the developers to mark specific releases of the code by version number. First, to find the available tags, we use the +git tag+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ git tag
|
$ git tag
|
||||||
v0.1.5
|
v0.1.5
|
||||||
@ -75,6 +78,7 @@ v0.9.0rc1
|
|||||||
|
|
||||||
The list of tags shows all the released versions of bitcoin. By convention, _release candidates_, which are intended for testing, have the suffix "rc". Stable releases that can be run on production systems have no suffix. From the list above, we select the highest version release, which at this time is v0.9.0rc1. To synchronize the local code with this version, we use the +git checkout+ command:
|
The list of tags shows all the released versions of bitcoin. By convention, _release candidates_, which are intended for testing, have the suffix "rc". Stable releases that can be run on production systems have no suffix. From the list above, we select the highest version release, which at this time is v0.9.0rc1. To synchronize the local code with this version, we use the +git checkout+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ git checkout v0.9.0rc1
|
$ git checkout v0.9.0rc1
|
||||||
Note: checking out 'v0.9.0rc1'.
|
Note: checking out 'v0.9.0rc1'.
|
||||||
@ -90,9 +94,10 @@ Carefully review the build pre-requisites which are in the first part of the bui
|
|||||||
|
|
||||||
[TIP]
|
[TIP]
|
||||||
====
|
====
|
||||||
The bitcoind build process was changed to use the autogen/configure/make system starting with version 0.9. Older versions use a simple Makefile and work slightly differently from the example below. Follow the instructions for the version you want to compile. The autogen/configure/make introduced in 0.9 is likely to be the build system used for all future versions of the code and is the system demonstrated in the examples below.
|
The Bitcoin Core build process was changed to use the autogen/configure/make system starting with version 0.9. Older versions use a simple Makefile and work slightly differently from the example below. Follow the instructions for the version you want to compile. The autogen/configure/make introduced in 0.9 is likely to be the build system used for all future versions of the code and is the system demonstrated in the examples below.
|
||||||
====
|
====
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ ./autogen.sh
|
$ ./autogen.sh
|
||||||
configure.ac:12: installing `src/build-aux/config.guess'
|
configure.ac:12: installing `src/build-aux/config.guess'
|
||||||
@ -105,6 +110,7 @@ $
|
|||||||
|
|
||||||
The +autogen.sh+ script creates a set of automatic configuration scripts that will interrogate your system to discover the correct settings and ensure you have all the necessary libraries to compile the code. The most important of these is the +configure+ script that offers a number of different options to customize the build process. Type +./configure --help+ to see the various options:
|
The +autogen.sh+ script creates a set of automatic configuration scripts that will interrogate your system to discover the correct settings and ensure you have all the necessary libraries to compile the code. The most important of these is the +configure+ script that offers a number of different options to customize the build process. Type +./configure --help+ to see the various options:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ ./configure --help
|
$ ./configure --help
|
||||||
|
|
||||||
@ -142,6 +148,7 @@ $
|
|||||||
|
|
||||||
The +configure+ script allows you to enable or disable certain features of bitcoind through the use of the +--enable-FEATURE+ and +--disable-FEATURE+ flags, where +FEATURE+ is replaced by the feature name, as listed in the help output above. In this chapter, we will build the bitcoind client with all the default features. We won't be using the configuration flags, but you should review them to understand what optional features are part of the client. Next, we run the +configure+ script to automatically discover all the necessary libraries and create a customized build script for our system:
|
The +configure+ script allows you to enable or disable certain features of bitcoind through the use of the +--enable-FEATURE+ and +--disable-FEATURE+ flags, where +FEATURE+ is replaced by the feature name, as listed in the help output above. In this chapter, we will build the bitcoind client with all the default features. We won't be using the configuration flags, but you should review them to understand what optional features are part of the client. Next, we run the +configure+ script to automatically discover all the necessary libraries and create a customized build script for our system:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ ./configure
|
$ ./configure
|
||||||
checking build system type... x86_64-unknown-linux-gnu
|
checking build system type... x86_64-unknown-linux-gnu
|
||||||
@ -172,6 +179,7 @@ $
|
|||||||
|
|
||||||
If all goes well, the +configure+ command will end by creating the customized build scripts that will allow us to compile bitcoind. If there are any missing libraries or errors, the +configure+ command will terminate with an error instead of creating the build scripts as shown above. If an error occurs, it is most likely a missing or incompatible library. Review the build documentation again and make sure you install the missing pre-requisites. Then run +configure+ again and see if that fixes the error. Next, we will compile the source code, a process that can take up to an hour to complete. During the compilation process you should see output every few seconds or every few minutes, or an error if something goes wrong. The compilation process can be resumed at any time if interrupted. Type +make+ to start compiling:
|
If all goes well, the +configure+ command will end by creating the customized build scripts that will allow us to compile bitcoind. If there are any missing libraries or errors, the +configure+ command will terminate with an error instead of creating the build scripts as shown above. If an error occurs, it is most likely a missing or incompatible library. Review the build documentation again and make sure you install the missing pre-requisites. Then run +configure+ again and see if that fixes the error. Next, we will compile the source code, a process that can take up to an hour to complete. During the compilation process you should see output every few seconds or every few minutes, or an error if something goes wrong. The compilation process can be resumed at any time if interrupted. Type +make+ to start compiling:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ make
|
$ make
|
||||||
Making all in src
|
Making all in src
|
||||||
@ -203,6 +211,7 @@ $
|
|||||||
|
|
||||||
If all goes well, bitcoind is now compiled. The final step is to install the bitcoind executable into the system path using the +make+ command:
|
If all goes well, bitcoind is now compiled. The final step is to install the bitcoind executable into the system path using the +make+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sudo make install
|
$ sudo make install
|
||||||
Making install in src
|
Making install in src
|
||||||
@ -216,15 +225,20 @@ make install-am
|
|||||||
$
|
$
|
||||||
----
|
----
|
||||||
|
|
||||||
We can confirm that bitcoin is correctly installed, as follows:
|
We can confirm that bitcoin is correctly installed, by asking the system for the path of the two executables, as follows:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ which bitcoind
|
$ which bitcoind
|
||||||
/usr/local/bin/bitcoind
|
/usr/local/bin/bitcoind
|
||||||
|
|
||||||
|
$ which bitcoin-cli
|
||||||
|
/usr/local/bin/bitcoin-cli
|
||||||
----
|
----
|
||||||
|
|
||||||
The default installation of bitcoind puts it in +/usr/local/bin+. When we first run bitcoind it will remind us to create a configuration file with a strong password for the JSON-RPC interface. We run it by typing +bitcoind+ into the terminal:
|
The default installation of bitcoind puts it in +/usr/local/bin+. When we first run bitcoind it will remind us to create a configuration file with a strong password for the JSON-RPC interface. We run it by typing +bitcoind+ into the terminal:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind
|
$ bitcoind
|
||||||
Error: To use the "-server" option, you must set a rpcpassword in the configuration file:
|
Error: To use the "-server" option, you must set a rpcpassword in the configuration file:
|
||||||
@ -241,19 +255,50 @@ for example: alertnotify=echo %s | mail -s "Bitcoin Alert" admin@foo.com
|
|||||||
|
|
||||||
Edit the configuration file in your preferred editor and set the parameters, replacing the password with a strong password as recommended by bitcoind. Do *not* use the password shown below. Create a file inside the +.bitcoin+ directory so that it is named +.bitcoin/bitcoin.conf+ and enter a username and password:
|
Edit the configuration file in your preferred editor and set the parameters, replacing the password with a strong password as recommended by bitcoind. Do *not* use the password shown below. Create a file inside the +.bitcoin+ directory so that it is named +.bitcoin/bitcoin.conf+ and enter a username and password:
|
||||||
|
|
||||||
|
[source,ini]
|
||||||
----
|
----
|
||||||
rpcuser=bitcoinrpc
|
rpcuser=bitcoinrpc
|
||||||
rpcpassword=2XA4DuKNCbtZXsBQRRNDEwEY2nM6M4H9Tx5dFjoAVVbK
|
rpcpassword=2XA4DuKNCbtZXsBQRRNDEwEY2nM6M4H9Tx5dFjoAVVbK
|
||||||
----
|
----
|
||||||
|
|
||||||
=== Using bitcoind from the command line
|
While you're editing this configuration file, you may want to set a few other options, such as +txindex+ (See <<txindex>>). For a full listing of the available options type +bitcoind --help+.
|
||||||
|
|
||||||
The reference client bitcoind offers a number of commands that can be run from the command line. These are the same commands as those offered via the JSON-RPC API, so the command line allows us to experiment interactively with the capabilities that are also available programmatically. To start, we can invoke the +help+ command to see a list of the available bitcoin commands:
|
Now, run the Bitcoin Core client. The first time you run it, it will rebuild the bitcoin blockchain by downloading all the blocks. This is a multi-gigabyte file and will take on average 2 days to download in full. You can shorten the blockchain initialization time by downloading a partial copy of the blockchain using a bittorrent client from +http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/+.
|
||||||
|
|
||||||
|
Run bitcoind in the background with the option +-daemon+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoind -daemon
|
||||||
|
|
||||||
|
Bitcoin version v0.9.0rc1-beta (2014-01-31 09:30:15 +0100)
|
||||||
|
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
|
||||||
|
Default data directory /home/bitcoin/.bitcoin
|
||||||
|
Using data directory /bitcoin/
|
||||||
|
Using at most 4 connections (1024 file descriptors available)
|
||||||
|
init message: Verifying wallet...
|
||||||
|
dbenv.open LogDir=/bitcoin/database ErrorFile=/bitcoin/db.log
|
||||||
|
Bound to [::]:8333
|
||||||
|
Bound to 0.0.0.0:8333
|
||||||
|
init message: Loading block index...
|
||||||
|
Opening LevelDB in /bitcoin/blocks/index
|
||||||
|
Opened LevelDB successfully
|
||||||
|
Opening LevelDB in /bitcoin/chainstate
|
||||||
|
Opened LevelDB successfully
|
||||||
|
|
||||||
|
[... more startup messages ...]
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
=== Using Bitcoin Core's JSON-RPC API from the command line
|
||||||
|
|
||||||
|
The Bitcoin Core client implements a JSON-RPC interface that can also be accessed using the command line helper +bitcoin-cli+. The command line allows us to experiment interactively with the capabilities that are also available programmatically via the API. To start, we can invoke the +help+ command to see a list of the available bitcoin commands:
|
||||||
|
|
||||||
[[bitcoind_commands]]
|
[[bitcoind_commands]]
|
||||||
.Bitcoind command list
|
.Bitcoin Core RPC commands
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
|
$ bitcoin-cli help
|
||||||
addmultisigaddress nrequired ["key",...] ( "account" )
|
addmultisigaddress nrequired ["key",...] ( "account" )
|
||||||
addnode "node" "add|remove|onetry"
|
addnode "node" "add|remove|onetry"
|
||||||
backupwallet "destination"
|
backupwallet "destination"
|
||||||
@ -263,7 +308,6 @@ decoderawtransaction "hexstring"
|
|||||||
decodescript "hex"
|
decodescript "hex"
|
||||||
dumpprivkey "bitcoinaddress"
|
dumpprivkey "bitcoinaddress"
|
||||||
dumpwallet "filename"
|
dumpwallet "filename"
|
||||||
encryptwallet "passphrase"
|
|
||||||
getaccount "bitcoinaddress"
|
getaccount "bitcoinaddress"
|
||||||
getaccountaddress "account"
|
getaccountaddress "account"
|
||||||
getaddednodeinfo dns ( "node" )
|
getaddednodeinfo dns ( "node" )
|
||||||
@ -271,6 +315,7 @@ getaddressesbyaccount "account"
|
|||||||
getbalance ( "account" minconf )
|
getbalance ( "account" minconf )
|
||||||
getbestblockhash
|
getbestblockhash
|
||||||
getblock "hash" ( verbose )
|
getblock "hash" ( verbose )
|
||||||
|
getblockchaininfo
|
||||||
getblockcount
|
getblockcount
|
||||||
getblockhash index
|
getblockhash index
|
||||||
getblocktemplate ( "jsonrequestobject" )
|
getblocktemplate ( "jsonrequestobject" )
|
||||||
@ -282,6 +327,7 @@ getinfo
|
|||||||
getmininginfo
|
getmininginfo
|
||||||
getnettotals
|
getnettotals
|
||||||
getnetworkhashps ( blocks height )
|
getnetworkhashps ( blocks height )
|
||||||
|
getnetworkinfo
|
||||||
getnewaddress ( "account" )
|
getnewaddress ( "account" )
|
||||||
getpeerinfo
|
getpeerinfo
|
||||||
getrawchangeaddress
|
getrawchangeaddress
|
||||||
@ -293,6 +339,7 @@ gettransaction "txid"
|
|||||||
gettxout "txid" n ( includemempool )
|
gettxout "txid" n ( includemempool )
|
||||||
gettxoutsetinfo
|
gettxoutsetinfo
|
||||||
getunconfirmedbalance
|
getunconfirmedbalance
|
||||||
|
getwalletinfo
|
||||||
getwork ( "data" )
|
getwork ( "data" )
|
||||||
help ( "command" )
|
help ( "command" )
|
||||||
importprivkey "bitcoinprivkey" ( "label" rescan )
|
importprivkey "bitcoinprivkey" ( "label" rescan )
|
||||||
@ -323,43 +370,24 @@ submitblock "hexdata" ( "jsonparametersobject" )
|
|||||||
validateaddress "bitcoinaddress"
|
validateaddress "bitcoinaddress"
|
||||||
verifychain ( checklevel numblocks )
|
verifychain ( checklevel numblocks )
|
||||||
verifymessage "bitcoinaddress" "signature" "message"
|
verifymessage "bitcoinaddress" "signature" "message"
|
||||||
|
walletlock
|
||||||
|
walletpassphrase "passphrase" timeout
|
||||||
|
walletpassphrasechange "oldpassphrase" "newpassphrase"
|
||||||
----
|
----
|
||||||
|
|
||||||
|
|
||||||
==== Running bitcoind
|
==== Getting information on the Bitcoin Core client status
|
||||||
|
|
||||||
Commands: -daemon, getinfo
|
Commands: getinfo
|
||||||
|
|
||||||
Now, run the bitcoin client. The first time you run it the bitcoin blockchain will be rebuilt. This is a multi-gigabyte file and will take on average 2 days to download in full. You can shorten the blockchain initialization time by downloading a partial copy of the blockchain using bittorrent from +http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/+.
|
Bitcoin's +getinfo+ RPC command shows us basic information about the status of the bitcoin network node, the wallet and the blockchain database. We use bitcoin-cli to run it:
|
||||||
|
|
||||||
Run bitcoind in the background with the option +-daemon+:
|
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind -daemon
|
$ bitcoin-cli getinfo
|
||||||
$
|
|
||||||
Bitcoin version v0.9.0rc1-beta (2014-01-31 09:30:15 +0100)
|
|
||||||
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
|
|
||||||
Default data directory /home/bitcoin/.bitcoin
|
|
||||||
Using data directory /bitcoin/
|
|
||||||
Using at most 4 connections (1024 file descriptors available)
|
|
||||||
init message: Verifying wallet...
|
|
||||||
dbenv.open LogDir=/bitcoin/database ErrorFile=/bitcoin/db.log
|
|
||||||
Bound to [::]:8333
|
|
||||||
Bound to 0.0.0.0:8333
|
|
||||||
init message: Loading block index...
|
|
||||||
Opening LevelDB in /bitcoin/blocks/index
|
|
||||||
Opened LevelDB successfully
|
|
||||||
Opening LevelDB in /bitcoin/chainstate
|
|
||||||
Opened LevelDB successfully
|
|
||||||
|
|
||||||
[... more startup messages ...]
|
|
||||||
|
|
||||||
----
|
----
|
||||||
|
[source,json]
|
||||||
Bitcoin's +getinfo+ command shows us basic information about the status of the bitcoin network node, the wallet and the blockchain database:
|
|
||||||
|
|
||||||
----
|
----
|
||||||
$ bitcoind getinfo
|
|
||||||
{
|
{
|
||||||
"version" : 90000,
|
"version" : 90000,
|
||||||
"protocolversion" : 70002,
|
"protocolversion" : 70002,
|
||||||
@ -387,24 +415,28 @@ It will take some time, perhaps more than a day, for the bitcoind client to "cat
|
|||||||
|
|
||||||
==== Wallet setup and encryption
|
==== Wallet setup and encryption
|
||||||
|
|
||||||
Commands: bitcoind encryptwallet, walletpassphrase
|
Commands: encryptwallet, walletpassphrase
|
||||||
|
|
||||||
Before we proceed with creating keys and other commands, we will first encrypt the wallet with a password. For this example, we use the +encryptwallet+ command with the password "foo". Obviously, replace "foo" with a strong and complex password!
|
Before we proceed with creating keys and other commands, we will first encrypt the wallet with a password. For this example, we use the +encryptwallet+ command with the password "foo". Obviously, replace "foo" with a strong and complex password!
|
||||||
|
|
||||||
----
|
----
|
||||||
$ bitcoind encryptwallet foo
|
$ bitcoin-cli encryptwallet foo
|
||||||
wallet encrypted; Bitcoin server stopping, restart to run with encrypted wallet. The keypool has been flushed, you need to make a new backup.
|
wallet encrypted; Bitcoin server stopping, restart to run with encrypted wallet. The keypool has been flushed, you need to make a new backup.
|
||||||
$
|
$
|
||||||
----
|
----
|
||||||
|
|
||||||
We can verify the wallet has been encrypted by running +getinfo+ again. This time you will notice a new entry +unlocked_until+ that is a counter showing how long the wallet decryption password will be stored in memory, keeping the wallet unlocked. At first this will be set to zero, meaning the wallet is locked:
|
We can verify the wallet has been encrypted by running +getinfo+ again. This time you will notice a new entry +unlocked_until+ that is a counter showing how long the wallet decryption password will be stored in memory, keeping the wallet unlocked. At first this will be set to zero, meaning the wallet is locked:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli getinfo
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind getinfo
|
|
||||||
{
|
{
|
||||||
"version" : 90000,
|
"version" : 90000,
|
||||||
|
|
||||||
[... other information...]
|
#[... other information...]
|
||||||
|
|
||||||
"unlocked_until" : 0,
|
"unlocked_until" : 0,
|
||||||
"errors" : ""
|
"errors" : ""
|
||||||
@ -415,18 +447,22 @@ $
|
|||||||
To unlock the wallet, we issue the +walletpassphrase+ command that takes two parameters, the password and a number of seconds until the wallet is locked again automatically (a time counter):
|
To unlock the wallet, we issue the +walletpassphrase+ command that takes two parameters, the password and a number of seconds until the wallet is locked again automatically (a time counter):
|
||||||
|
|
||||||
----
|
----
|
||||||
$ bitcoind walletpassphrase foo 360
|
$ bitcoin-cli walletpassphrase foo 360
|
||||||
$
|
$
|
||||||
----
|
----
|
||||||
|
|
||||||
Confirm the wallet is unlocked and see the timeout by running +getinfo+ again:
|
Confirm the wallet is unlocked and see the timeout by running +getinfo+ again:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli getinfo
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind getinfo
|
|
||||||
{
|
{
|
||||||
"version" : 90000,
|
"version" : 90000,
|
||||||
|
|
||||||
[... other information ...]
|
#[... other information ...]
|
||||||
|
|
||||||
"unlocked_until" : 1392580909,
|
"unlocked_until" : 1392580909,
|
||||||
"errors" : ""
|
"errors" : ""
|
||||||
@ -439,22 +475,25 @@ Commands: backupwallet, importwallet, dumpwallet
|
|||||||
|
|
||||||
Next, we will practice creating a wallet backup file and then restoring the wallet from the backup file. Use the +backupwallet+ command to backup, providing the file name as the parameter. Here we backup the wallet to the file +wallet.backup+:
|
Next, we will practice creating a wallet backup file and then restoring the wallet from the backup file. Use the +backupwallet+ command to backup, providing the file name as the parameter. Here we backup the wallet to the file +wallet.backup+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind backupwallet wallet.backup
|
$ bitcoin-cli backupwallet wallet.backup
|
||||||
$
|
$
|
||||||
----
|
----
|
||||||
|
|
||||||
Now, to restore the backup file, use the +importwallet+ command. If your wallet is locked, you will need to unlock it first (see +walletpassphrase+ above) in order to import the backup file:
|
Now, to restore the backup file, use the +importwallet+ command. If your wallet is locked, you will need to unlock it first (see +walletpassphrase+ above) in order to import the backup file:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind importwallet wallet.backup
|
$ bitcoin-cli importwallet wallet.backup
|
||||||
$
|
$
|
||||||
----
|
----
|
||||||
|
|
||||||
The +dumpwallet+ command can be used to dump the wallet into a text file that is human-readable:
|
The +dumpwallet+ command can be used to dump the wallet into a text file that is human-readable:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind dumpwallet wallet.txt
|
$ bitcoin-cli dumpwallet wallet.txt
|
||||||
$ more wallet.txt
|
$ more wallet.txt
|
||||||
# Wallet dump created by Bitcoin v0.9.0rc1-beta (2014-01-31 09:30:15 +0100)
|
# Wallet dump created by Bitcoin v0.9.0rc1-beta (2014-01-31 09:30:15 +0100)
|
||||||
# * Created on 2014-02- 8dT20:34:55Z
|
# * Created on 2014-02- 8dT20:34:55Z
|
||||||
@ -474,8 +513,9 @@ Commands: getnewaddress, getreceivedbyaddress, listtransactions, getaddressesbya
|
|||||||
|
|
||||||
The bitcoin reference client maintains a pool of addresses, the size of which is displayed by +keypoolsize+ when you use the command +getinfo+. These addresses are generated automatically and can then be used as public receiving addresses or change addresses. To get one of these addresses, you can use the +getnewaddress+ command:
|
The bitcoin reference client maintains a pool of addresses, the size of which is displayed by +keypoolsize+ when you use the command +getinfo+. These addresses are generated automatically and can then be used as public receiving addresses or change addresses. To get one of these addresses, you can use the +getnewaddress+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getnewaddress
|
$ bitcoin-cli getnewaddress
|
||||||
1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL
|
1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL
|
||||||
----
|
----
|
||||||
|
|
||||||
@ -483,22 +523,28 @@ Now, we can use this address to send a small amount of bitcoin to our bitcoind w
|
|||||||
|
|
||||||
We can now query the bitcoind client for the amount received by this address, and specify how many confirmations are required before an amount is counted in that balance. For this example, we will specify zero confirmations. A few seconds after sending the bitcoin from another wallet, we will see it reflected in the wallet. We use +getreceivedbyaddress+ with the address and the number of confirmations set to zero (0):
|
We can now query the bitcoind client for the amount received by this address, and specify how many confirmations are required before an amount is counted in that balance. For this example, we will specify zero confirmations. A few seconds after sending the bitcoin from another wallet, we will see it reflected in the wallet. We use +getreceivedbyaddress+ with the address and the number of confirmations set to zero (0):
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getreceivedbyaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL 0
|
$ bitcoin-cli getreceivedbyaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL 0
|
||||||
0.05000000
|
0.05000000
|
||||||
----
|
----
|
||||||
|
|
||||||
If we omit the zero from the end of this command, we will only see the amounts that have at least +minconf+ confirmations, where +minconf+ is the setting for the minimum number of confirmations before a transaction is listed in the balance. The +minconf+ setting is specified in the bitcoind configuration file. Since the transaction sending this bitcoin was only sent in the last few seconds, it has still not confirmed and therefore we will see it list a zero balance:
|
If we omit the zero from the end of this command, we will only see the amounts that have at least +minconf+ confirmations, where +minconf+ is the setting for the minimum number of confirmations before a transaction is listed in the balance. The +minconf+ setting is specified in the bitcoind configuration file. Since the transaction sending this bitcoin was only sent in the last few seconds, it has still not confirmed and therefore we will see it list a zero balance:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getreceivedbyaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL
|
$ bitcoin-cli getreceivedbyaddress 1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL
|
||||||
0.00000000
|
0.00000000
|
||||||
----
|
----
|
||||||
|
|
||||||
The transactions received by the entire wallet can also be displayed using the +listtransactions+ command:
|
The transactions received by the entire wallet can also be displayed using the +listtransactions+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli listtransactions
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind listtransactions
|
|
||||||
[
|
[
|
||||||
{
|
{
|
||||||
"account" : "",
|
"account" : "",
|
||||||
@ -516,8 +562,12 @@ $ bitcoind listtransactions
|
|||||||
|
|
||||||
We can list all addresses in the entire wallet using the +getaddressesbyaccount+ command:
|
We can list all addresses in the entire wallet using the +getaddressesbyaccount+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli getaddressesbyaccount ""
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind getaddressesbyaccount ""
|
|
||||||
[
|
[
|
||||||
"1LQoTPYy1TyERbNV4zZbhEmgyfAipC6eqL",
|
"1LQoTPYy1TyERbNV4zZbhEmgyfAipC6eqL",
|
||||||
"17vrg8uwMQUibkvS2ECRX4zpcVJ78iFaZS",
|
"17vrg8uwMQUibkvS2ECRX4zpcVJ78iFaZS",
|
||||||
@ -537,8 +587,9 @@ $ bitcoind getaddressesbyaccount ""
|
|||||||
|
|
||||||
Finally, the command +getbalance+ will show the total balance of the wallet, adding up all transactions confirmed with at least +minconf+ confirmations:
|
Finally, the command +getbalance+ will show the total balance of the wallet, adding up all transactions confirmed with at least +minconf+ confirmations:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getbalance
|
$ bitcoin-cli getbalance
|
||||||
0.05000000
|
0.05000000
|
||||||
----
|
----
|
||||||
|
|
||||||
@ -553,8 +604,12 @@ Commands: gettransaction, getrawtransaction, decoderawtransaction
|
|||||||
|
|
||||||
We'll now explore the incoming transaction that was listed above using the +gettransaction+ command. We can retrieve a transaction by its transaction hash, shown at +txid+, above with the +gettransaction+ command:
|
We'll now explore the incoming transaction that was listed above using the +gettransaction+ command. We can retrieve a transaction by its transaction hash, shown at +txid+, above with the +gettransaction+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
|
||||||
{
|
{
|
||||||
"amount" : 0.05000000,
|
"amount" : 0.05000000,
|
||||||
"confirmations" : 0,
|
"confirmations" : 0,
|
||||||
@ -579,15 +634,20 @@ Transaction IDs are not authoritative until a transaction has been confirmed. Ab
|
|||||||
|
|
||||||
The transaction form shown above with the command +gettransaction+ is the simplified form. To retrieve the full transaction code and decode it we will use two commands, +getrawtransaction+ and +decoderawtransaction+. First, +getrawtransaction+ takes the _transaction hash (txid)_ as a parameter and returns the full transaction as a "raw" hex string, exactly as it exists on the bitcoin network:
|
The transaction form shown above with the command +gettransaction+ is the simplified form. To retrieve the full transaction code and decode it we will use two commands, +getrawtransaction+ and +decoderawtransaction+. First, +getrawtransaction+ takes the _transaction hash (txid)_ as a parameter and returns the full transaction as a "raw" hex string, exactly as it exists on the bitcoin network:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getrawtransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
$ bitcoin-cli getrawtransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
||||||
0100000001d717279515f88e2f56ce4e8a31e2ae3e9f00ba1d0add648e80c480ea22e0c7d3000000008b483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5ceaffffffff02404b4c00000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac1f312906000000001976a914107b7086b31518935c8d28703d66d09b3623134388ac00000000
|
0100000001d717279515f88e2f56ce4e8a31e2ae3e9f00ba1d0add648e80c480ea22e0c7d3000000008b483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5ceaffffffff02404b4c00000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac1f312906000000001976a914107b7086b31518935c8d28703d66d09b3623134388ac00000000
|
||||||
----
|
----
|
||||||
|
|
||||||
To decode this hex string, we can use the +decoderawtransaction+ command. Copy and paste the hex as the first parameter of +decoderawtransaction+ to get the full contents interpreted as a JSON data structure (for formatting reasons the hex string is shortened in the example below):
|
To decode this hex string, we can use the +decoderawtransaction+ command. Copy and paste the hex as the first parameter of +decoderawtransaction+ to get the full contents interpreted as a JSON data structure (for formatting reasons the hex string is shortened in the example below):
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli decoderawtransaction 0100000001d717...388ac00000000
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind decoderawtransaction 0100000001d717...388ac00000000
|
|
||||||
{
|
{
|
||||||
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
||||||
"version" : 1,
|
"version" : 1,
|
||||||
@ -597,8 +657,14 @@ $ bitcoind decoderawtransaction 0100000001d717...388ac00000000
|
|||||||
"txid" : "d3c7e022ea80c4808e64dd0a1dba009f3eaee2318a4ece562f8ef815952717d7",
|
"txid" : "d3c7e022ea80c4808e64dd0a1dba009f3eaee2318a4ece562f8ef815952717d7",
|
||||||
"vout" : 0,
|
"vout" : 0,
|
||||||
"scriptSig" : {
|
"scriptSig" : {
|
||||||
"asm" : "3045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba201 04793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5cea",
|
"asm" : "3045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0\
|
||||||
"hex" : "483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0dd0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5cea"
|
758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac1b\
|
||||||
|
d193dfba201 04793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede65e4\
|
||||||
|
c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5cea",
|
||||||
|
"hex" : "483045022100a4ebbeec83225dedead659bbde7da3d026c8b8e12e61a2df0d\
|
||||||
|
d0758e227383b302203301768ef878007e9ef7c304f70ffaf1f2c975b192d34c5b9b2ac\
|
||||||
|
1bd193dfba2014104793ac8a58ea751f9710e39aad2e296cc14daa44fa59248be58ede6\
|
||||||
|
5e4c4b884ac5b5b6dede05ba84727e34c8fd3ee1d6929d7a44b6e111d41cc79e05dbfe5cea"
|
||||||
},
|
},
|
||||||
"sequence" : 4294967295
|
"sequence" : 4294967295
|
||||||
}
|
}
|
||||||
@ -608,7 +674,8 @@ $ bitcoind decoderawtransaction 0100000001d717...388ac00000000
|
|||||||
"value" : 0.05000000,
|
"value" : 0.05000000,
|
||||||
"n" : 0,
|
"n" : 0,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2 OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -621,7 +688,8 @@ $ bitcoind decoderawtransaction 0100000001d717...388ac00000000
|
|||||||
"value" : 1.03362847,
|
"value" : 1.03362847,
|
||||||
"n" : 1,
|
"n" : 1,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 107b7086b31518935c8d28703d66d09b36231343 OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 107b7086b31518935c8d28703d66d09b36231343\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a914107b7086b31518935c8d28703d66d09b3623134388ac",
|
"hex" : "76a914107b7086b31518935c8d28703d66d09b3623134388ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -640,8 +708,12 @@ We can further explore the blockchain by examining the previous transaction refe
|
|||||||
|
|
||||||
Once the transaction we received has been confirmed by inclusion in a block, the +gettransaction+ command will return additional information, showing the _block hash (identifier)_ in which the transaction was included:
|
Once the transaction we received has been confirmed by inclusion in a block, the +gettransaction+ command will return additional information, showing the _block hash (identifier)_ in which the transaction was included:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3
|
|
||||||
{
|
{
|
||||||
"amount" : 0.05000000,
|
"amount" : 0.05000000,
|
||||||
"confirmations" : 1,
|
"confirmations" : 1,
|
||||||
@ -664,14 +736,24 @@ $ bitcoind gettransaction 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309ac
|
|||||||
|
|
||||||
Above, we see the new information in the entries +blockhash+, the hash of the block in which the transaction was included, and +blockindex+ with value 18, indicating that our transaction was the 18th transaction in that block.
|
Above, we see the new information in the entries +blockhash+, the hash of the block in which the transaction was included, and +blockindex+ with value 18, indicating that our transaction was the 18th transaction in that block.
|
||||||
|
|
||||||
|
[[txindex]]
|
||||||
|
.Transaction database index and txindex option
|
||||||
|
****
|
||||||
|
By default, Bitcoin Core builds a database containing _only_ the transactions related to the user's wallet. If you want to be able to access _any_ transaction with commands like +gettransaction+, you need to configure Bitcoin Core to build a complete transaction index, which can be achieved with the +txindex+ option. Set +txindex=1+ in the Bitcoin Core configuration file (usually found in your home directory under +.bitcoin/bitcoin.conf+). Once you change this parameter, you need to restart bitcoind and wait for it to rebuild the index.
|
||||||
|
****
|
||||||
|
|
||||||
==== Exploring blocks
|
==== Exploring blocks
|
||||||
|
|
||||||
Commands: getblock, getblockhash
|
Commands: getblock, getblockhash
|
||||||
|
|
||||||
Now that we know which block our transaction was included in, we can query that block. We use the +getblock+ command with the block hash as the parameter:
|
Now that we know which block our transaction was included in, we can query that block. We use the +getblock+ command with the block hash as the parameter:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli getblock 000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a717b true
|
||||||
|
----
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getblock 000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a717b true
|
|
||||||
{
|
{
|
||||||
"hash" : "000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a717b",
|
"hash" : "000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a717b",
|
||||||
"confirmations" : 2,
|
"confirmations" : 2,
|
||||||
@ -700,7 +782,7 @@ $ bitcoind getblock 000000000000000051d2e759c63a26e247f185ecb7926ed7a6624bc31c2a
|
|||||||
"e57a4c70f91c8d9ba0ff0a55987ea578affb92daaa59c76820125f31a9584dfc",
|
"e57a4c70f91c8d9ba0ff0a55987ea578affb92daaa59c76820125f31a9584dfc",
|
||||||
"9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
"9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
||||||
|
|
||||||
[... many more transactions ...]
|
#[... many more transactions ...]
|
||||||
|
|
||||||
],
|
],
|
||||||
"time" : 1392660808,
|
"time" : 1392660808,
|
||||||
@ -717,15 +799,20 @@ The block contains 367 transactions and as you see above, the 18th transaction l
|
|||||||
|
|
||||||
We can also retrieve a block by its block height using the +getblockhash+ command, which takes the block height as the parameter and returns the block hash for that block:
|
We can also retrieve a block by its block height using the +getblockhash+ command, which takes the block height as the parameter and returns the block hash for that block:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getblockhash 0
|
$ bitcoin-cli getblockhash 0
|
||||||
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||||
----
|
----
|
||||||
|
|
||||||
Above, we retrieve the block hash of the "genesis block", the first block mined by Satoshi Nakamoto, at height zero. Retrieving this block shows:
|
Above, we retrieve the block hash of the "genesis block", the first block mined by Satoshi Nakamoto, at height zero. Retrieving this block shows:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
|
||||||
{
|
{
|
||||||
"hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
"hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
||||||
"confirmations" : 286388,
|
"confirmations" : 286388,
|
||||||
@ -756,8 +843,12 @@ Bitcoin's transactions are based on the concept of spending "outputs", which are
|
|||||||
|
|
||||||
First, we use the +listunspent+ command to show all the unspent *confirmed* outputs in our wallet:
|
First, we use the +listunspent+ command to show all the unspent *confirmed* outputs in our wallet:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli listunspent
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind listunspent
|
|
||||||
[
|
[
|
||||||
{
|
{
|
||||||
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
||||||
@ -775,8 +866,12 @@ We see that the transaction +9ca8f9...+ created an output (with vout index 0) as
|
|||||||
|
|
||||||
First, let's look at the specific output in more detail. We use the +gettxout+ to get the details of this unspent output above. Transaction outputs are always referenced by txid and vout, and these are the parameters we pass to +gettxout+:
|
First, let's look at the specific output in more detail. We use the +gettxout+ to get the details of this unspent output above. Transaction outputs are always referenced by txid and vout, and these are the parameters we pass to +gettxout+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli gettxout 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3 0
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind gettxout 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3 0
|
|
||||||
{
|
{
|
||||||
"bestblock" : "0000000000000001405ce69bd4ceebcdfdb537749cebe89d371eb37e13899fd9",
|
"bestblock" : "0000000000000001405ce69bd4ceebcdfdb537749cebe89d371eb37e13899fd9",
|
||||||
"confirmations" : 7,
|
"confirmations" : 7,
|
||||||
@ -797,8 +892,9 @@ $ bitcoind gettxout 9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c1
|
|||||||
|
|
||||||
What we see above is the output that assigned 50 millibits to our address +1hvz...+. To spend this output we will create a new transaction. First, let's make an address to which we will send the money:
|
What we see above is the output that assigned 50 millibits to our address +1hvz...+. To spend this output we will create a new transaction. First, let's make an address to which we will send the money:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getnewaddress
|
$ bitcoin-cli getnewaddress
|
||||||
1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb
|
1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb
|
||||||
----
|
----
|
||||||
|
|
||||||
@ -806,19 +902,31 @@ We will send 25 millibits to the new address +1LnfTn...+ we just created in our
|
|||||||
|
|
||||||
We use the +createrawtransaction+ to create the transaction described above. As parameters to +createrawtransaction+ we provide the transaction input (the 50 millibit unspent output from our confirmed transaction) and the two transaction outputs (money sent to the new address and change sent back to the previous address):
|
We use the +createrawtransaction+ to create the transaction described above. As parameters to +createrawtransaction+ we provide the transaction input (the 50 millibit unspent output from our confirmed transaction) and the two transaction outputs (money sent to the new address and change sent back to the previous address):
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
bitcoind createrawtransaction
|
$ bitcoin-cli createrawtransaction \
|
||||||
'[{"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3", "vout" : 0}]'
|
'[{"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3", "vout" : 0}]' \
|
||||||
'{"1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb": 0.025,
|
'{"1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb": 0.025, \
|
||||||
"1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL": 0.0245}'
|
"1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL": 0.0245}'
|
||||||
|
|
||||||
0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c\
|
||||||
|
0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd6810756\
|
||||||
|
4a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d\
|
||||||
|
1fd288ac00000000
|
||||||
----
|
----
|
||||||
|
|
||||||
The +createrawtransaction+ command produces a raw hex string that encodes the transaction details we supplied. Let's confirm everything is correct by decoding this raw string using the +decoderawtransaction+ command:
|
The +createrawtransaction+ command produces a raw hex string that encodes the transaction details we supplied. Let's confirm everything is correct by decoding this raw string using the +decoderawtransaction+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli decoderawtransaction \
|
||||||
|
0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c\
|
||||||
|
0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd6810756\
|
||||||
|
4a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d\
|
||||||
|
1fd288ac00000000
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
|
||||||
{
|
{
|
||||||
"txid" : "0793299cb26246a8d24e468ec285a9520a1c30fcb5b6125a102e3fc05d4f3cba",
|
"txid" : "0793299cb26246a8d24e468ec285a9520a1c30fcb5b6125a102e3fc05d4f3cba",
|
||||||
"version" : 1,
|
"version" : 1,
|
||||||
@ -839,7 +947,8 @@ $ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db
|
|||||||
"value" : 0.02500000,
|
"value" : 0.02500000,
|
||||||
"n" : 0,
|
"n" : 0,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 d90d36e98f62968d2bc9bbd68107564a156a9bcf OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 d90d36e98f62968d2bc9bbd68107564a156a9bcf\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac",
|
"hex" : "76a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -852,7 +961,8 @@ $ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db
|
|||||||
"value" : 0.02450000,
|
"value" : 0.02450000,
|
||||||
"n" : 1,
|
"n" : 1,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2 OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -874,9 +984,10 @@ As you may notice, the transaction contains an empty +scriptSig+ because we have
|
|||||||
An encrypted wallet must be unlocked before a transaction is signed because signing requires access to the secret keys in the wallet.
|
An encrypted wallet must be unlocked before a transaction is signed because signing requires access to the secret keys in the wallet.
|
||||||
====
|
====
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind walletpassphrase foo 360
|
$ bitcoin-cli walletpassphrase foo 360
|
||||||
$ bitcoind signrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
$ bitcoin-cli signrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c0000000000ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
||||||
{
|
{
|
||||||
"hex" : "0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000",
|
"hex" : "0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000",
|
||||||
"complete" : true
|
"complete" : true
|
||||||
@ -885,8 +996,19 @@ $ bitcoind signrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f
|
|||||||
|
|
||||||
The +signrawtransaction+ command returns another hex encoded raw transaction. We decode it to see what changed, with +decoderawtransaction+:
|
The +signrawtransaction+ command returns another hex encoded raw transaction. We decode it to see what changed, with +decoderawtransaction+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli decoderawtransaction\
|
||||||
|
0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c\
|
||||||
|
000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76\
|
||||||
|
d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051\
|
||||||
|
a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ff\
|
||||||
|
ffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88a\
|
||||||
|
c50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac000000\
|
||||||
|
00
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
|
||||||
{
|
{
|
||||||
"txid" : "ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346",
|
"txid" : "ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346",
|
||||||
"version" : 1,
|
"version" : 1,
|
||||||
@ -896,8 +1018,14 @@ $ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db
|
|||||||
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
"txid" : "9ca8f969bd3ef5ec2a8685660fdbf7a8bd365524c2e1fc66c309acbae2c14ae3",
|
||||||
"vout" : 0,
|
"vout" : 0,
|
||||||
"scriptSig" : {
|
"scriptSig" : {
|
||||||
"asm" : "304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a0601 03c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127",
|
"asm" : "304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76\
|
||||||
"hex" : "47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127"
|
d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af5\
|
||||||
|
2051a0601 03c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71d\
|
||||||
|
c5127",
|
||||||
|
"hex" : "47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b\
|
||||||
|
76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4a\
|
||||||
|
f52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c\
|
||||||
|
71dc5127"
|
||||||
},
|
},
|
||||||
"sequence" : 4294967295
|
"sequence" : 4294967295
|
||||||
}
|
}
|
||||||
@ -907,7 +1035,8 @@ $ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db
|
|||||||
"value" : 0.02500000,
|
"value" : 0.02500000,
|
||||||
"n" : 0,
|
"n" : 0,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 d90d36e98f62968d2bc9bbd68107564a156a9bcf OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 d90d36e98f62968d2bc9bbd68107564a156a9bcf\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac",
|
"hex" : "76a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -920,7 +1049,8 @@ $ bitcoind decoderawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db
|
|||||||
"value" : 0.02450000,
|
"value" : 0.02450000,
|
||||||
"n" : 1,
|
"n" : 1,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2 OP_EQUALVERIFY OP_CHECKSIG",
|
"asm" : "OP_DUP OP_HASH160 07bdb518fa2e6089fd810235cf1100c9c13d1fd2\
|
||||||
|
OP_EQUALVERIFY OP_CHECKSIG",
|
||||||
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
"hex" : "76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkeyhash",
|
"type" : "pubkeyhash",
|
||||||
@ -937,16 +1067,29 @@ Now, the inputs used in the transaction contain a +scriptSig+, which is a digita
|
|||||||
|
|
||||||
Now it's time to submit the newly created transaction to the network. We do that with the command +sendrawtransaction+ which takes the raw hex string produced by +signrawtransaction+. This is the same string we just decoded above:
|
Now it's time to submit the newly created transaction to the network. We do that with the command +sendrawtransaction+ which takes the raw hex string produced by +signrawtransaction+. This is the same string we just decoded above:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind sendrawtransaction 0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ffffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac00000000
|
$ bitcoin-cli sendrawtransaction\
|
||||||
|
0100000001e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c\
|
||||||
|
000000006a47304402203e8a16522da80cef66bacfbc0c800c6d52c4a26d1d86a54e0a1b76\
|
||||||
|
d661f020c9022010397f00149f2a8fb2bc5bca52f2d7a7f87e3897a273ef54b277e4af52051\
|
||||||
|
a06012103c9700559f690c4a9182faa8bed88ad8a0c563777ac1d3f00fd44ea6c71dc5127ff\
|
||||||
|
ffffff02a0252600000000001976a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88a\
|
||||||
|
c50622500000000001976a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac000000\
|
||||||
|
00
|
||||||
|
|
||||||
ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
|
ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
|
||||||
----
|
----
|
||||||
|
|
||||||
The command +sendrawtransaction+ returns a _transaction hash (txid)_ as it submits the transaction on the network. We can now query that transaction id with +gettransaction+:
|
The command +sendrawtransaction+ returns a _transaction hash (txid)_ as it submits the transaction on the network. We can now query that transaction id with +gettransaction+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
|
----
|
||||||
|
$ bitcoin-cli gettransaction \
|
||||||
|
ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
$ bitcoind gettransaction ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346
|
|
||||||
{
|
{
|
||||||
"amount" : 0.00000000,
|
"amount" : 0.00000000,
|
||||||
"fee" : -0.00050000,
|
"fee" : -0.00050000,
|
||||||
@ -999,9 +1142,12 @@ Alternative implementations include:
|
|||||||
* btcd, a Go language full node bitcoin client (https://opensource.conformal.com/wiki/btcd)
|
* btcd, a Go language full node bitcoin client (https://opensource.conformal.com/wiki/btcd)
|
||||||
* Bits of Proof (BOP), a Java enterprise-class implementation of bitcoin (https://bitsofproof.com)
|
* Bits of Proof (BOP), a Java enterprise-class implementation of bitcoin (https://bitsofproof.com)
|
||||||
* picocoin, a C implementation of a light-weight client library for bitcoin (https://github.com/jgarzik/picocoin)
|
* picocoin, a C implementation of a light-weight client library for bitcoin (https://github.com/jgarzik/picocoin)
|
||||||
|
* pybitcointools, a Python bitcoin library (https://github.com/vbuterin/pybitcointools)
|
||||||
|
* pycoin, another Python bitcoin library (https://github.com/richardkiss/pycoin)
|
||||||
|
|
||||||
Many more libraries exist in a variety of other programming languages and more are created all the time.
|
Many more libraries exist in a variety of other programming languages and more are created all the time.
|
||||||
|
|
||||||
|
[[sx_tools]]
|
||||||
==== Libbitcoin and sx tools
|
==== Libbitcoin and sx tools
|
||||||
|
|
||||||
The libbitcoin library is a C++ scalable multi-threaded and modular implementation that supports a full-node client and a command-line toolset named "sx", which offers many of the same capabilities as the bitcoind client commands we illustrated in this chapter. The sx tools also offer some key management and manipulation tools that are not offered by bitcoind, including type-2 deterministic keys and key mnemonics.
|
The libbitcoin library is a C++ scalable multi-threaded and modular implementation that supports a full-node client and a command-line toolset named "sx", which offers many of the same capabilities as the bitcoind client commands we illustrated in this chapter. The sx tools also offer some key management and manipulation tools that are not offered by bitcoind, including type-2 deterministic keys and key mnemonics.
|
||||||
@ -1010,122 +1156,19 @@ The libbitcoin library is a C++ scalable multi-threaded and modular implementati
|
|||||||
|
|
||||||
To install sx and the supporting library libbitcoin, download and run the online installer on a Linux system:
|
To install sx and the supporting library libbitcoin, download and run the online installer on a Linux system:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ wget http://sx.dyne.org/install-sx.sh
|
$ wget http://sx.dyne.org/install-sx.sh
|
||||||
$ sudo bash ./install-sx.sh
|
$ sudo bash ./install-sx.sh
|
||||||
----
|
----
|
||||||
|
|
||||||
You should now have the sx tools installed. Type +sx+ with no parameters to display the help text, which lists all the available commands:
|
You should now have the sx tools installed. Type +sx+ with no parameters to display the help text, which lists all the available commands (See <<sx_cmds_>>)
|
||||||
|
|
||||||
----
|
===== Generating and manipulating keys with sx
|
||||||
Usage: sx COMMAND [ARGS]...
|
|
||||||
|
|
||||||
-c, --config Specify a config file
|
|
||||||
|
|
||||||
The sx commands are:
|
|
||||||
|
|
||||||
DETERMINISTIC KEYS AND ADDRESSES
|
|
||||||
genaddr Generate a Bitcoin address deterministically from a wallet
|
|
||||||
seed or master public key.
|
|
||||||
genpriv Generate a private key deterministically from a seed.
|
|
||||||
genpub Generate a public key deterministically from a wallet
|
|
||||||
seed or master public key.
|
|
||||||
mpk Extract a master public key from a deterministic wallet seed.
|
|
||||||
newseed Create a new deterministic wallet seed.
|
|
||||||
|
|
||||||
TRANSACTION PARSING
|
|
||||||
showscript Show the details of a raw script.
|
|
||||||
showtx Show the details of a transaction.
|
|
||||||
|
|
||||||
BLOCKCHAIN QUERIES (blockexplorer.com)
|
|
||||||
blke-fetch-transaction Fetches a transaction from blockexplorer.com
|
|
||||||
|
|
||||||
FORMAT
|
|
||||||
base58-decode Convert from base58 to hex
|
|
||||||
base58-encode Convert from hex to base58
|
|
||||||
base58check-decode Convert from base58check to hex
|
|
||||||
base58check-encode Convert from hex to base58check
|
|
||||||
decode-addr Decode an address to its internal RIPEMD representation.
|
|
||||||
embed-addr Generate an address used for embedding record of data into the blockchain.
|
|
||||||
encode-addr Encode an address to base58check form.
|
|
||||||
ripemd-hash RIPEMD hash data from STDIN.
|
|
||||||
unwrap Validates checksum and recovers version byte and original data from hexstring.
|
|
||||||
validaddr Validate an address.
|
|
||||||
wrap Adds version byte and checksum to hexstring.
|
|
||||||
|
|
||||||
BRAINWALLET
|
|
||||||
brainwallet Make a private key from a brainwallet
|
|
||||||
mnemonic Work with Electrum compatible mnemonics (12 words wallet seed).
|
|
||||||
|
|
||||||
BLOCKCHAIN WATCHING
|
|
||||||
monitor Monitor an address.
|
|
||||||
watchtx Watch transactions from the network searching for a certain hash.
|
|
||||||
|
|
||||||
BLOCKCHAIN QUERIES (blockchain.info)
|
|
||||||
bci-fetch-last-height Fetch the last block height using blockchain.info.
|
|
||||||
bci-history Get list of output points, values, and their spends
|
|
||||||
from blockchain.info
|
|
||||||
|
|
||||||
MISC
|
|
||||||
btc Convert Satoshis into Bitcoins.
|
|
||||||
initchain Initialize a new blockchain.
|
|
||||||
qrcode Generate Bitcoin QR codes offline.
|
|
||||||
satoshi Convert Bitcoins into Satoshis.
|
|
||||||
showblkhead Show the details of a block header.
|
|
||||||
wallet Experimental command line wallet.
|
|
||||||
|
|
||||||
MULTISIG ADDRESSES
|
|
||||||
scripthash Create BIP 16 script hash address from raw script hex.
|
|
||||||
|
|
||||||
LOOSE KEYS AND ADDRESSES
|
|
||||||
addr See Bitcoin address of a public or private key.
|
|
||||||
get-pubkey Get the pubkey of an address if available
|
|
||||||
newkey Create a new private key.
|
|
||||||
pubkey See the public part of a private key.
|
|
||||||
|
|
||||||
STEALTH
|
|
||||||
secret-to-wif Convert a secret exponent value to Wallet. Import. Format.
|
|
||||||
stealth-new Generate a new master stealth secret.
|
|
||||||
stealth-recv Regenerate the secret from your master secret and provided nonce.
|
|
||||||
stealth-send Generate a new sending address and a stealth nonce.
|
|
||||||
|
|
||||||
CREATE TRANSACTIONS
|
|
||||||
mktx Create an unsigned tx.
|
|
||||||
rawscript Create the raw hex representation from a script.
|
|
||||||
set-input Set a transaction input.
|
|
||||||
sign-input Sign a transaction input.
|
|
||||||
|
|
||||||
VALIDATE
|
|
||||||
validsig Validate a transaction input's signature.
|
|
||||||
|
|
||||||
BLOCKCHAIN QUERIES
|
|
||||||
balance Show balance of a Bitcoin address in satoshis.
|
|
||||||
fetch-block-header Fetch raw block header.
|
|
||||||
fetch-last-height Fetch the last block height.
|
|
||||||
fetch-transaction Fetch a raw transaction using a network connection to make requests against the obelisk load balancer backend.
|
|
||||||
fetch-transaction-index Fetch block height and index in block of transaction.
|
|
||||||
get-utxo Get enough unspent transaction outputs from a given set of
|
|
||||||
addresses to pay a given number of satoshis
|
|
||||||
history Get list of output points, values, and their spends for an
|
|
||||||
address. grep can filter for just unspent outputs which can
|
|
||||||
be fed into mktx.
|
|
||||||
validtx Validate a transaction.
|
|
||||||
|
|
||||||
BLOCKCHAIN UPDATES
|
|
||||||
sendtx-bci Send tx to blockchain.info/pushtx.
|
|
||||||
sendtx-node Send transaction to a single node.
|
|
||||||
sendtx-obelisk Send tx to obelisk server.
|
|
||||||
sendtx-p2p Send tx to bitcoin network.
|
|
||||||
|
|
||||||
See 'sx help COMMAND' for more information on a specific command.
|
|
||||||
|
|
||||||
SpesmiloXchange home page: <http://sx.dyne.org/>
|
|
||||||
----
|
|
||||||
|
|
||||||
===== Generating and manipulating keys with sxBitcoin Core
|
|
||||||
|
|
||||||
Generate a new private key with the operating system's random number generator by using the +newkey+ command. We save the standard output into the file +private_key+:
|
Generate a new private key with the operating system's random number generator by using the +newkey+ command. We save the standard output into the file +private_key+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx newkey > private_key
|
$ sx newkey > private_key
|
||||||
$ cat private_key
|
$ cat private_key
|
||||||
@ -1134,6 +1177,7 @@ $ cat private_key
|
|||||||
|
|
||||||
Now, generate the public key from that private key using the +pubkey+ command. Pass the +private_key+ file into the standard input and save the standard output of the command into a new file +public_key+:
|
Now, generate the public key from that private key using the +pubkey+ command. Pass the +private_key+ file into the standard input and save the standard output of the command into a new file +public_key+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx pubkey < private_key > public_key
|
$ sx pubkey < private_key > public_key
|
||||||
$ cat public_key
|
$ cat public_key
|
||||||
@ -1141,6 +1185,8 @@ $ cat public_key
|
|||||||
----
|
----
|
||||||
|
|
||||||
We can re-format the public_key as an address using the +addr+ command. We pass the +public_key+ into standard input:
|
We can re-format the public_key as an address using the +addr+ command. We pass the +public_key+ into standard input:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx addr < public_key
|
$ sx addr < public_key
|
||||||
17re1S4Q8ZHyCP8Kw7xQad1Lr6XUzWUnkG
|
17re1S4Q8ZHyCP8Kw7xQad1Lr6XUzWUnkG
|
||||||
@ -1152,6 +1198,7 @@ The keys generated above are so called type-0 non-deterministic keys. That means
|
|||||||
|
|
||||||
First, we generate a "seed" that will be used as the basis to derive a chain of keys, compatible with the Electrum wallet and other similar implementations. We use the +newseed+ command to produce a seed value:
|
First, we generate a "seed" that will be used as the basis to derive a chain of keys, compatible with the Electrum wallet and other similar implementations. We use the +newseed+ command to produce a seed value:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx newseed > seed
|
$ sx newseed > seed
|
||||||
$ cat seed
|
$ cat seed
|
||||||
@ -1161,6 +1208,7 @@ eb68ee9f3df6bd4441a9feadec179ff1
|
|||||||
The seed value can also be exported as a word mnemonic that is human readable and easier to store and type than a hexadecimal string
|
The seed value can also be exported as a word mnemonic that is human readable and easier to store and type than a hexadecimal string
|
||||||
using the +mnemonic+ command:
|
using the +mnemonic+ command:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx mnemonic < seed > words
|
$ sx mnemonic < seed > words
|
||||||
$ cat words
|
$ cat words
|
||||||
@ -1169,6 +1217,7 @@ adore repeat vision worst especially veil inch woman cast recall dwell appreciat
|
|||||||
|
|
||||||
The mnemonic words can be used to reproduce the seed using the +mnemonic+ command again:
|
The mnemonic words can be used to reproduce the seed using the +mnemonic+ command again:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx mnemonic < words
|
$ sx mnemonic < words
|
||||||
eb68ee9f3df6bd4441a9feadec179ff1
|
eb68ee9f3df6bd4441a9feadec179ff1
|
||||||
@ -1176,6 +1225,7 @@ eb68ee9f3df6bd4441a9feadec179ff1
|
|||||||
|
|
||||||
With the seed, we can now generate a sequence of private and public keys, a key chain. We use the +genpriv+ command to generate a sequence of private keys from a seed and the +addr+ command to generate the corresponding public key.
|
With the seed, we can now generate a sequence of private and public keys, a key chain. We use the +genpriv+ command to generate a sequence of private keys from a seed and the +addr+ command to generate the corresponding public key.
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ sx genpriv 0 < seed
|
$ sx genpriv 0 < seed
|
||||||
5JzY2cPZGViPGgXZ4Syb9Y4eUGjJpVt6sR8noxrpEcqgyj7LK7i
|
5JzY2cPZGViPGgXZ4Syb9Y4eUGjJpVt6sR8noxrpEcqgyj7LK7i
|
||||||
@ -1204,12 +1254,14 @@ One key difference between btcd and bitcoind is that btcd does not include walle
|
|||||||
|
|
||||||
To install btcd, for Windows, download and run the msi available at https://github.com/conformal/btcd/releases or run the following command on Linux, assuming you already have installed the Go language:
|
To install btcd, for Windows, download and run the msi available at https://github.com/conformal/btcd/releases or run the following command on Linux, assuming you already have installed the Go language:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ go get github.com/conformal/btcd/...
|
$ go get github.com/conformal/btcd/...
|
||||||
----
|
----
|
||||||
|
|
||||||
To update btcd to the latest version, just run:
|
To update btcd to the latest version, just run:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ go get -u -v github.com/conformal/btcd/...
|
$ go get -u -v github.com/conformal/btcd/...
|
||||||
----
|
----
|
||||||
@ -1218,6 +1270,7 @@ $ go get -u -v github.com/conformal/btcd/...
|
|||||||
|
|
||||||
btcd has a number of configuration options, which can be viewed by running:
|
btcd has a number of configuration options, which can be viewed by running:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ btcd --help
|
$ btcd --help
|
||||||
----
|
----
|
||||||
@ -1225,12 +1278,14 @@ $ btcd --help
|
|||||||
btcd comes prepacked with some goodies such as btcctl, a command line utility that can be used to both control and query btcd via RPC. btcd does not enable its RPC server by default; you must configure at minimum both an RPC username and password:
|
btcd comes prepacked with some goodies such as btcctl, a command line utility that can be used to both control and query btcd via RPC. btcd does not enable its RPC server by default; you must configure at minimum both an RPC username and password:
|
||||||
|
|
||||||
* btcd.conf configuration file
|
* btcd.conf configuration file
|
||||||
|
[source,ini]
|
||||||
----
|
----
|
||||||
[Application Options]
|
[Application Options]
|
||||||
rpcuser=myuser
|
rpcuser=myuser
|
||||||
rpcpass=SomeDecentp4ssw0rd
|
rpcpass=SomeDecentp4ssw0rd
|
||||||
----
|
----
|
||||||
* btcctl.conf configuration file
|
* btcctl.conf configuration file
|
||||||
|
[source,ini]
|
||||||
----
|
----
|
||||||
[Application Options]
|
[Application Options]
|
||||||
rpcuser=myuser
|
rpcuser=myuser
|
||||||
@ -1239,6 +1294,7 @@ rpcpass=SomeDecentp4ssw0rd
|
|||||||
|
|
||||||
Or if you want to override the configuration files from the command line:
|
Or if you want to override the configuration files from the command line:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ btcd -u myuser -P SomeDecentp4ssw0rd
|
$ btcd -u myuser -P SomeDecentp4ssw0rd
|
||||||
$ btcctl -u myuser -P SomeDecentp4ssw0rd
|
$ btcctl -u myuser -P SomeDecentp4ssw0rd
|
||||||
@ -1246,6 +1302,7 @@ $ btcctl -u myuser -P SomeDecentp4ssw0rd
|
|||||||
|
|
||||||
For a list of available options, run:
|
For a list of available options, run:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ btcctl --help
|
$ btcctl --help
|
||||||
----
|
----
|
||||||
|
|||||||
@ -5,6 +5,10 @@
|
|||||||
|
|
||||||
Ownership of bitcoin is established through _digital keys_, _bitcoin addresses_ and _digital signatures_. The digital keys are not actually stored in the network, but are instead created and stored by end-users in a file, or simple database, called a _wallet_. The digital keys in a user's wallet are completely independent of the bitcoin protocol and can be generated and managed by the user's wallet software without reference to the blockchain or access to the Internet. Keys enable many of the interesting properties of bitcoin, including de-centralized trust and control, ownership attestation and the cryptographic-proof security model.
|
Ownership of bitcoin is established through _digital keys_, _bitcoin addresses_ and _digital signatures_. The digital keys are not actually stored in the network, but are instead created and stored by end-users in a file, or simple database, called a _wallet_. The digital keys in a user's wallet are completely independent of the bitcoin protocol and can be generated and managed by the user's wallet software without reference to the blockchain or access to the Internet. Keys enable many of the interesting properties of bitcoin, including de-centralized trust and control, ownership attestation and the cryptographic-proof security model.
|
||||||
|
|
||||||
|
|
||||||
|
HNFUzKACoVNLnyx4PlW7hJg3dpko2UlDwttaxaUPan4afMmK9ZAtHMKB4PqJgYFe8VDIp0x7OpruTFugxA5hBTE=
|
||||||
|
|
||||||
|
|
||||||
Every bitcoin transaction requires a valid signature to be included in the blockchain, which can only be generated with valid digital keys, therefore anyone with a copy of those keys has control of the bitcoin in that account. Keys come in pairs consisting of a private (secret) and public key. Think of the public key as similar to a bank account number and the private key as similar to the secret PIN number, or signature on a cheque that provides control over the account. These digital keys are very rarely seen by the users of bitcoin. For the most part, they are stored inside the wallet file and managed by the bitcoin wallet software.
|
Every bitcoin transaction requires a valid signature to be included in the blockchain, which can only be generated with valid digital keys, therefore anyone with a copy of those keys has control of the bitcoin in that account. Keys come in pairs consisting of a private (secret) and public key. Think of the public key as similar to a bank account number and the private key as similar to the secret PIN number, or signature on a cheque that provides control over the account. These digital keys are very rarely seen by the users of bitcoin. For the most part, they are stored inside the wallet file and managed by the bitcoin wallet software.
|
||||||
|
|
||||||
In the payment portion of a bitcoin transaction, the recipient's public key is represented by its digital fingerprint, called a _bitcoin address_, which is used in the same way as the beneficiary name on a cheque (i.e. "Pay to the order of"). In most cases, a bitcoin address is generated from and corresponds to a public key. However, not all bitcoin addresses represent public keys; they can also represent other beneficiaries such as scripts, as we will see later in this chapter. This way, bitcoin addresses abstract the recipient of funds, making transaction destinations flexible, similar to paper cheques: a single payment instrument that can be used to pay into people's accounts, company accounts, pay for bills or pay to cash. The bitcoin address is the only representation of the keys that users will routinely see, as this is the part they need to share with the world.
|
In the payment portion of a bitcoin transaction, the recipient's public key is represented by its digital fingerprint, called a _bitcoin address_, which is used in the same way as the beneficiary name on a cheque (i.e. "Pay to the order of"). In most cases, a bitcoin address is generated from and corresponds to a public key. However, not all bitcoin addresses represent public keys; they can also represent other beneficiaries such as scripts, as we will see later in this chapter. This way, bitcoin addresses abstract the recipient of funds, making transaction destinations flexible, similar to paper cheques: a single payment instrument that can be used to pay into people's accounts, company accounts, pay for bills or pay to cash. The bitcoin address is the only representation of the keys that users will routinely see, as this is the part they need to share with the world.
|
||||||
@ -36,6 +40,7 @@ A bitcoin wallet contains a collection of key pairs, each consisting of a privat
|
|||||||
.Private Key, Public Key and Bitcoin Address
|
.Private Key, Public Key and Bitcoin Address
|
||||||
image::images/privk_to_pubK_to_addressA.png["privk_to_pubK_to_addressA"]
|
image::images/privk_to_pubK_to_addressA.png["privk_to_pubK_to_addressA"]
|
||||||
|
|
||||||
|
[[private_keys]]
|
||||||
==== Private Keys
|
==== Private Keys
|
||||||
|
|
||||||
A +private key+ is simply a number, picked at random. Ownership and control over the private key is the root of user control over all funds associated with the corresponding bitcoin address. The private key is used to create signatures that are required to spend bitcoins by proving ownership of funds used in a transaction. The private key must remain secret at all times, as revealing it to a third party is equivalent to giving them control over the bitcoins secured by that key. The private key must also be backed up and protected from accidental loss, since if lost it cannot be recovered and the funds secured by it are forever lost too.
|
A +private key+ is simply a number, picked at random. Ownership and control over the private key is the root of user control over all funds associated with the corresponding bitcoin address. The private key is used to create signatures that are required to spend bitcoins by proving ownership of funds used in a transaction. The private key must remain secret at all times, as revealing it to a third party is equivalent to giving them control over the bitcoins secured by that key. The private key must also be backed up and protected from accidental loss, since if lost it cannot be recovered and the funds secured by it are forever lost too.
|
||||||
@ -91,7 +96,7 @@ $ sx newkey
|
|||||||
[[pubkey]]
|
[[pubkey]]
|
||||||
==== Public Keys
|
==== Public Keys
|
||||||
|
|
||||||
The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: latexmath:[\(K = k * G\)]+ where +k+ is the private key, +G+ is a constant point called the _Generator Point_ and +K+ is the resulting public key. The reverse operation, known as "finding the discrete logarithm" -- calculating +k+ if you know +K+ -- is as difficult as trying all possible values of +k+, i.e., a brute-force search. Before we demonstrate how to generate a public key from a private key, let's look at Elliptic Curve Cryptography in a bit more detail.
|
The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: latexmath:[\(K = k * G\)] where +k+ is the private key, +G+ is a constant point called the _Generator Point_ and +K+ is the resulting public key. The reverse operation, known as "finding the discrete logarithm" -- calculating +k+ if you know +K+ -- is as difficult as trying all possible values of +k+, i.e., a brute-force search. Before we demonstrate how to generate a public key from a private key, let's look at Elliptic Curve Cryptography in a bit more detail.
|
||||||
|
|
||||||
|
|
||||||
[[elliptic_curve]]
|
[[elliptic_curve]]
|
||||||
@ -111,7 +116,7 @@ Bitcoin uses a specific elliptic curve and set of mathematical constants, as def
|
|||||||
[latexmath]
|
[latexmath]
|
||||||
++++
|
++++
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
{y^2 = (x^3 \+ 7)} \text{over} \mathbb{F}_p
|
{y^2 = (x^3 \+ 7)} \text{over} \(\mathbb{F}_p\)
|
||||||
\end{equation}
|
\end{equation}
|
||||||
++++
|
++++
|
||||||
or
|
or
|
||||||
@ -123,7 +128,7 @@ or
|
|||||||
\end{equation}
|
\end{equation}
|
||||||
++++
|
++++
|
||||||
|
|
||||||
The +mod p+ (modulo prime number p) indicates that this curve is over a finite field of prime order +p+, also written as latexmath:[\(\mathbb{F}_p\)], where p = 2^256^ - 2^32^ - 2^9^ - 2^8^ - 2^7^ - 2^6^ - 2^4^ - 1\)], a very large prime number.
|
The +mod p+ (modulo prime number p) indicates that this curve is over a finite field of prime order +p+, also written as latexmath:[\(\mathbb{F}_p\)], where p = 2^256^ - 2^32^ - 2^9^ - 2^8^ - 2^7^ - 2^6^ - 2^4^ - 1, a very large prime number.
|
||||||
|
|
||||||
Because this curve is defined over a finite field of prime order instead of over the real numbers it 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. As an example, below is the same elliptic curve over a much smaller finite field of prime order 17, showing a pattern of dots on a grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much more complex pattern of dots on a unfathomably large grid.
|
Because this curve is defined over a finite field of prime order instead of over the real numbers it 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. As an example, below is the same elliptic curve over a much smaller finite field of prime order 17, showing a pattern of dots on a grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much more complex pattern of dots on a unfathomably large grid.
|
||||||
|
|
||||||
@ -133,7 +138,8 @@ image::images/ecc-over-F17-math.png["ecc-over-F17-math"]
|
|||||||
|
|
||||||
So for example, below is a point P with coordinates (x,y) that is a point on the secp256k1 curve. You can check this yourself using Python:
|
So for example, below is a point P with coordinates (x,y) that is a point on the secp256k1 curve. You can check this yourself using Python:
|
||||||
----
|
----
|
||||||
P = (55066263022277343669578718895168534326250603453777594175500187360389116729240, 32670510020758816978083085130507043184471273380659243275938904335757337482424)
|
P = (55066263022277343669578718895168534326250603453777594175500187360389116729240,\
|
||||||
|
32670510020758816978083085130507043184471273380659243275938904335757337482424)
|
||||||
----
|
----
|
||||||
|
|
||||||
====
|
====
|
||||||
@ -270,9 +276,15 @@ To add extra security against typos or transcription errors, Base58Check is a Ba
|
|||||||
|
|
||||||
To convert data (a number) into a Base58Check format, we first add a prefix to the data, called the "version byte", which serves to easily identify the type of data that is encoded. For example, in the case of a bitcoin address the prefix is zero (0x00 in hex), whereas the prefix used when encoding a private key is 128 (0x80 in hex). A list of common version prefixes is shown below in <<base58check_versions>>.
|
To convert data (a number) into a Base58Check format, we first add a prefix to the data, called the "version byte", which serves to easily identify the type of data that is encoded. For example, in the case of a bitcoin address the prefix is zero (0x00 in hex), whereas the prefix used when encoding a private key is 128 (0x80 in hex). A list of common version prefixes is shown below in <<base58check_versions>>.
|
||||||
|
|
||||||
Next compute the "double-SHA" checksum, meaning we apply the SHA256 hash-algorithm twice on the previous result (prefix and data): +checksum = SHA256(SHA256(prefix\+data))+ From the resulting 32-byte hash (hash-of-a-hash), we take only the first four bytes. These four bytes serve as the error-checking code, or checksum. The checksum is concatenated (appended) to the end.
|
Next compute the "double-SHA" checksum, meaning we apply the SHA256 hash-algorithm twice on the previous result (prefix and data):
|
||||||
|
|
||||||
|
----
|
||||||
|
checksum = SHA256(SHA256(prefix+data))
|
||||||
|
----
|
||||||
|
|
||||||
The result of the above is now a prefix, the data and a checksum, concatenated (bytewise). This result is encoded using the base-58 alphabet described in the section above.
|
From the resulting 32-byte hash (hash-of-a-hash), we take only the first four bytes. These four bytes serve as the error-checking code, or checksum. The checksum is concatenated (appended) to the end.
|
||||||
|
|
||||||
|
The result of the above is now a prefix, the data and a checksum. This result is encoded using the base-58 alphabet described in the section above.
|
||||||
|
|
||||||
[[base58check_encoding]]
|
[[base58check_encoding]]
|
||||||
.Base58Check Encoding: A base-58, versioned and checksummed format for unambiguously encoding bitcoin data
|
.Base58Check Encoding: A base-58, versioned and checksummed format for unambiguously encoding bitcoin data
|
||||||
@ -437,18 +449,31 @@ include::code/key-to-address-ecc-example.py[]
|
|||||||
----
|
----
|
||||||
|
|
||||||
Here's the output from running this code:
|
Here's the output from running this code:
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ python key-to-address-ecc-example.py
|
$ python key-to-address-ecc-example.py
|
||||||
Private Key (hex) is: 3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa6
|
Private Key (hex) is:
|
||||||
Private Key (decimal) is: 26563230048437957592232553826663696440606756685920117476832299673293013768870
|
3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa6
|
||||||
Private Key (WIF) is: 5JG9hT3beGTJuUAmCQEmNaxAuMacCTfXuw1R3FCXig23RQHMr4K
|
Private Key (decimal) is:
|
||||||
Private Key Compressed (hex) is: 3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa601
|
26563230048437957592232553826663696440606756685920117476832299673293013768870
|
||||||
Private Key (WIF-Compressed) is: KyBsPXxTuVD82av65KZkrGrWi5qLMah5SdNq6uftawDbgKa2wv6S
|
Private Key (WIF) is:
|
||||||
Public Key (x,y) coordinates is: (41637322786646325214887832269588396900663353932545912953362782457239403430124L, 16388935128781238405526710466724741593761085120864331449066658622400339362166L)
|
5JG9hT3beGTJuUAmCQEmNaxAuMacCTfXuw1R3FCXig23RQHMr4K
|
||||||
Public Key (hex) is: 045c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec243bcefdd4347074d44bd7356d6a53c495737dd96295e2a9374bf5f02ebfc176
|
Private Key Compressed (hex) is:
|
||||||
Compressed Public Key (hex) is: 025c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec
|
3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa601
|
||||||
Bitcoin Address (b58check) is: 1thMirt546nngXqyPEz532S8fLwbozud8
|
Private Key (WIF-Compressed) is:
|
||||||
Compressed Bitcoin Address (b58check) is: 14cxpo3MBCYYWCgF74SWTdcmxipnGUsPw3
|
KyBsPXxTuVD82av65KZkrGrWi5qLMah5SdNq6uftawDbgKa2wv6S
|
||||||
|
Public Key (x,y) coordinates is:
|
||||||
|
(41637322786646325214887832269588396900663353932545912953362782457239403430124L,
|
||||||
|
16388935128781238405526710466724741593761085120864331449066658622400339362166L)
|
||||||
|
Public Key (hex) is:
|
||||||
|
045c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec
|
||||||
|
243bcefdd4347074d44bd7356d6a53c495737dd96295e2a9374bf5f02ebfc176
|
||||||
|
Compressed Public Key (hex) is:
|
||||||
|
025c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec
|
||||||
|
Bitcoin Address (b58check) is:
|
||||||
|
1thMirt546nngXqyPEz532S8fLwbozud8
|
||||||
|
Compressed Bitcoin Address (b58check) is:
|
||||||
|
14cxpo3MBCYYWCgF74SWTdcmxipnGUsPw3
|
||||||
----
|
----
|
||||||
|
|
||||||
|
|
||||||
@ -509,7 +534,8 @@ Here are some examples of mnemonic codes and the seeds they produce:
|
|||||||
|=======
|
|=======
|
||||||
| entropy input (128 bits) | 0c1e24e5917779d297e14d45f14e1a1a
|
| entropy input (128 bits) | 0c1e24e5917779d297e14d45f14e1a1a
|
||||||
| mnemonic (12 words) | army van defense carry jealous true garbage claim echo media make crunch
|
| mnemonic (12 words) | army van defense carry jealous true garbage claim echo media make crunch
|
||||||
| seed (512 bits) | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb888a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7
|
| seed (512 bits) | 3338a6d2ee71c7f28eb5b882159634cd46a898463e9d2d0980f8e80dfbba5b0fa0291e5fb88\
|
||||||
|
8a599b44b93187be6ee3ab5fd3ead7dd646341b2cdb8d08d13bf7
|
||||||
|=======
|
|=======
|
||||||
|
|
||||||
|
|
||||||
@ -518,8 +544,8 @@ Here are some examples of mnemonic codes and the seeds they produce:
|
|||||||
| entropy input (256 bits) | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c
|
| entropy input (256 bits) | 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c
|
||||||
| mnemonic (24 words) | cake apple borrow silk endorse fitness top denial coil riot stay wolf
|
| mnemonic (24 words) | cake apple borrow silk endorse fitness top denial coil riot stay wolf
|
||||||
luggage oxygen faint major edit measure invite love trap field dilemma oblige
|
luggage oxygen faint major edit measure invite love trap field dilemma oblige
|
||||||
| seed (512 bits) | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977
|
| seed (512 bits) | 3972e432e99040f75ebe13a660110c3e29d131a2c808c7ee5f1631d0a977fcf473bee22\
|
||||||
fcf473bee22fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343
|
fce540af281bf7cdeade0dd2c1c795bd02f1e4049e205a0158906c343
|
||||||
|=======
|
|=======
|
||||||
|
|
||||||
[[hd_wallets]]
|
[[hd_wallets]]
|
||||||
@ -699,17 +725,21 @@ Using the command line tool +sx+, introduced in chapter 3, you can experiment wi
|
|||||||
----
|
----
|
||||||
$ sx hd-seed > m # create a new master private key from a seed and store in file "m"
|
$ sx hd-seed > m # create a new master private key from a seed and store in file "m"
|
||||||
$ cat m # show the master extended private key
|
$ cat m # show the master extended private key
|
||||||
xprv9s21ZrQH143K38iQ9Y5p6qoB8C75TE71NfpyQPdfGvzghDt39DHPFpovvtWZaRgY5uPwV7RpEgHs7cvdgfiSjLjjbuGKGcjRyU7RGGSS8Xa
|
xprv9s21ZrQH143K38iQ9Y5p6qoB8C75TE71NfpyQPdfGvzghDt39DHPFpovvtWZaRgY5uPwV7RpEgHs7cvd\
|
||||||
|
gfiSjLjjbuGKGcjRyU7RGGSS8Xa
|
||||||
$ cat m | sx hd-pub 0 # generate the M/0 extended public key
|
$ cat m | sx hd-pub 0 # generate the M/0 extended public key
|
||||||
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9
|
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJun\
|
||||||
|
SDMstweyLXhRgPxdp14sk9tJPW9
|
||||||
$ cat m | sx hd-priv 0 # generate the m/0 extended private key
|
$ cat m | sx hd-priv 0 # generate the m/0 extended private key
|
||||||
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
|
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6\
|
||||||
|
GoNMKUga5biW6Hx4tws2six3b9c
|
||||||
$ cat m | sx hd-priv 0 | sx hd-to-wif # show the private key of m/0 as a WIF
|
$ cat m | sx hd-priv 0 | sx hd-to-wif # show the private key of m/0 as a WIF
|
||||||
L1pbvV86crAGoDzqmgY85xURkz3c435Z9nirMt52UbnGjYMzKBUN
|
L1pbvV86crAGoDzqmgY85xURkz3c435Z9nirMt52UbnGjYMzKBUN
|
||||||
$ cat m | sx hd-pub 0 | sx hd-to-address # show the bitcoin address of M/0
|
$ cat m | sx hd-pub 0 | sx hd-to-address # show the bitcoin address of M/0
|
||||||
1CHCnCjgMNb6digimckNQ6TBVcTWBAmPHK
|
1CHCnCjgMNb6digimckNQ6TBVcTWBAmPHK
|
||||||
$ cat m | sx hd-priv 0 | sx hd-priv 12 --hard | sx hd-priv 4 # generate m/0/12'/4
|
$ cat m | sx hd-priv 0 | sx hd-priv 12 --hard | sx hd-priv 4 # generate m/0/12'/4
|
||||||
xprv9yL8ndfdPVeDWJenF18oiHguRUj8jHmVrqqD97YQHeTcR3LCeh53q5PXPkLsy2kRaqgwoS6YZBLatRZRyUeAkRPe1kLR1P6Mn7jUrXFquUt
|
xprv9yL8ndfdPVeDWJenF18oiHguRUj8jHmVrqqD97YQHeTcR3LCeh53q5PXPkLsy2kRaqgwoS6YZBLatRZR\
|
||||||
|
yUeAkRPe1kLR1P6Mn7jUrXFquUt
|
||||||
----
|
----
|
||||||
====
|
====
|
||||||
|
|
||||||
@ -735,14 +765,14 @@ Test the following encrypted keys using bitaddress.org to see how you can get th
|
|||||||
|=======
|
|=======
|
||||||
|
|
||||||
|
|
||||||
[[p2sh]]
|
[[p2sh_addresses]]
|
||||||
==== Pay To Script Hash (P2SH) and Multi-Sig Addresses
|
==== Pay To Script Hash (P2SH) and Multi-Sig Addresses
|
||||||
|
|
||||||
As we know, traditional bitcoin addresses begin with the number “1” and are derived from the public key, which is derived from the private key. While anyone can send bitcoin to a “1” address, that bitcoin can only be spent by presenting the corresponding private key signature and public key hash.
|
As we know, traditional bitcoin addresses begin with the number “1” and are derived from the public key, which is derived from the private key. While anyone can send bitcoin to a “1” address, that bitcoin can only be spent by presenting the corresponding private key signature and public key hash.
|
||||||
|
|
||||||
Bitcoin addresses that begin with the number “3” are pay-to-script-hash (P2SH) addresses, sometimes erroneously called multi-signature or multi-sig addresses. They designate the beneficiary of a bitcoin transaction as the hash of a script, instead of the owner of a public key. The feature was introduced in January 2012 with Bitcoin Improvement Proposal 16 or BIP0016 (see <<bip0016>>) and is being widely adopted because it provides the opportunity to add functionality to the address itself. Unlike transactions that "send" funds to traditional “1” bitcoin addresses, also known as pay-to-public-key-hash (P2PKH), funds sent to “3” addresses require something more than the presentation of one public key hash and one private key signature as proof of ownership. The requirements are designated at the time the address is created, within the script, and all inputs to this address will be encumbered with the same requirements.
|
Bitcoin addresses that begin with the number “3” are pay-to-script-hash (P2SH) addresses, sometimes erroneously called multi-signature or multi-sig addresses. They designate the beneficiary of a bitcoin transaction as the hash of a script, instead of the owner of a public key. The feature was introduced in January 2012 with Bitcoin Improvement Proposal 16 or BIP0016 (see <<bip0016>>) and is being widely adopted because it provides the opportunity to add functionality to the address itself. Unlike transactions that "send" funds to traditional “1” bitcoin addresses, also known as pay-to-public-key-hash (P2PKH), funds sent to “3” addresses require something more than the presentation of one public key hash and one private key signature as proof of ownership. The requirements are designated at the time the address is created, within the script, and all inputs to this address will be encumbered with the same requirements.
|
||||||
|
|
||||||
A pay-to-script-hash address is created from a transaction script, which defines who can spend a transaction output (for more detail, see <<transactions>>). Encoding a pay-to-script hash address involves using the same double-hash function as used during creation of a bitcoin address, only applied on the script instead of the public key.
|
A pay-to-script-hash address is created from a transaction script, which defines who can spend a transaction output (for more detail, see <<p2sh>>). Encoding a pay-to-script hash address involves using the same double-hash function as used during creation of a bitcoin address, only applied on the script instead of the public key.
|
||||||
|
|
||||||
----
|
----
|
||||||
script hash = RIPEMD160(SHA256(script))
|
script hash = RIPEMD160(SHA256(script))
|
||||||
@ -823,6 +853,7 @@ In both cases, one of the risks of using a single fixed address (rather than a s
|
|||||||
So does a vanity address increase security? If Eugenia generates the vanity address "1Kids33q44erFfpeXrmDSz7zEqG2FesZEN",
|
So does a vanity address increase security? If Eugenia generates the vanity address "1Kids33q44erFfpeXrmDSz7zEqG2FesZEN",
|
||||||
users are likely to look at the vanity pattern word _and a few characters beyond_, for example noticing the "1Kids33" part of the address. That would force an attacker to generate a vanity address matching at least 6 characters (2 more), expending an effort that is 3,364 times (58 x 58) higher than the effort Eugenia expended for her 4 character vanity. Essentially, the effort Eugenia expends (or pays a vanity pool for) "pushes" the attacker into having to produce a longer pattern vanity. If Eugenia pays a pool to generate an 8 character vanity address, the attacker would be pushed into the realm of 10 characters which is infeasible on a personal computer and expensive even with a custom vanity-mining rig or vanity pool. What is affordable for Eugenia becomes unaffordable for the attacker, especially if the potential reward of fraud is not high enough to cover the cost of the vanity address generation.
|
users are likely to look at the vanity pattern word _and a few characters beyond_, for example noticing the "1Kids33" part of the address. That would force an attacker to generate a vanity address matching at least 6 characters (2 more), expending an effort that is 3,364 times (58 x 58) higher than the effort Eugenia expended for her 4 character vanity. Essentially, the effort Eugenia expends (or pays a vanity pool for) "pushes" the attacker into having to produce a longer pattern vanity. If Eugenia pays a pool to generate an 8 character vanity address, the attacker would be pushed into the realm of 10 characters which is infeasible on a personal computer and expensive even with a custom vanity-mining rig or vanity pool. What is affordable for Eugenia becomes unaffordable for the attacker, especially if the potential reward of fraud is not high enough to cover the cost of the vanity address generation.
|
||||||
|
|
||||||
|
[[paper_wallets]]
|
||||||
==== Paper Wallets
|
==== Paper Wallets
|
||||||
|
|
||||||
Paper wallets are bitcoin private keys printed on paper. Often the paper wallet also includes the corresponding bitcoin address, for convenience, but this is not necessary since it can be derived from the private key. Paper wallets are a very effective way to create backups or offline bitcoin storage, also known as "cold storage". As a backup mechanism, a paper wallet can provide security against the loss of key due to a computer mishap such as a hard drive failure, theft, or accidental deletion. As a "cold storage" mechanism, if the paper wallet keys are generated offline and never stored on a computer system, they are much more secure against hackers, key-loggers and other online computer threats.
|
Paper wallets are bitcoin private keys printed on paper. Often the paper wallet also includes the corresponding bitcoin address, for convenience, but this is not necessary since it can be derived from the private key. Paper wallets are a very effective way to create backups or offline bitcoin storage, also known as "cold storage". As a backup mechanism, a paper wallet can provide security against the loss of key due to a computer mishap such as a hard drive failure, theft, or accidental deletion. As a "cold storage" mechanism, if the paper wallet keys are generated offline and never stored on a computer system, they are much more secure against hackers, key-loggers and other online computer threats.
|
||||||
|
|||||||
@ -1,5 +1,6 @@
|
|||||||
[[ch5]]
|
[[ch5]]
|
||||||
== Chapter 5 - Transactions
|
[[transactions]]
|
||||||
|
== Transactions
|
||||||
|
|
||||||
[[ch5_intro]]
|
[[ch5_intro]]
|
||||||
=== Introduction
|
=== Introduction
|
||||||
@ -11,37 +12,39 @@ In this chapter we will examine all the various forms of transactions, what they
|
|||||||
[[tx_lifecycle]]
|
[[tx_lifecycle]]
|
||||||
=== Transaction Lifecycle
|
=== Transaction Lifecycle
|
||||||
|
|
||||||
A transaction's lifecycle starts with the transaction's creation, also known as origination. The transaction is then signed, with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each network node (participant) validates and propagates the transaction until it reaches (almost) every node in the network. Finally, the transaction is verified by a mining node and included in a block of transactions that is recorded on the blockchain. Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. The funds allocated to a new owner by the transaction can then be spent in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again.
|
A transaction's lifecycle starts with the transaction's creation, also known as origination. The transaction is then signed, with one or more signatures indicating the authorization to spend the funds referenced by the transaction. The transaction is then broadcast on the bitcoin network, where each network node (participant) validates and propagates the transaction until it reaches (almost) every node in the network. Finally, the transaction is verified by a mining node and included in a block of transactions that is recorded on the blockchain.
|
||||||
|
|
||||||
|
Once recorded on the blockchain and confirmed by sufficient subsequent blocks (confirmations), the transaction is a permanent part of the bitcoin ledger and is accepted as valid by all participants. The funds allocated to a new owner by the transaction can then be spent in a new transaction, extending the chain of ownership and beginning the lifecycle of a transaction again.
|
||||||
|
|
||||||
[[tx_origination]]
|
[[tx_origination]]
|
||||||
==== Creating Transactions
|
==== Creating Transactions
|
||||||
|
|
||||||
In some ways it helps to think of a transaction in the same way as a paper cheque. Like a cheque, a transaction is an instrument that expresses the intent to transfer money and is not visible to the financial system until it is submitted for execution. Like a cheque, the originator of the transaction does not have to be the one signing the transaction. Transactions can be created online or offline by anyone, even if the person creating the transaction is not an authorized signer on the account. For example an accounts payable clerk might process payable cheques for signature by the CEO. Similarly, an accounts payable clerk can create bitcoin transactions and then have the CEO apply digital signatures to make them valid. While a cheque references a specific account as the source of the funds, a bitcoin transaction references a specific previous transaction as its source, rather than an account.
|
In some ways it helps to think of a transaction in the same way as a paper cheque. Like a cheque, a transaction is an instrument that expresses the intent to transfer money and is not visible to the financial system until it is submitted for execution. Like a cheque, the originator of the transaction does not have to be the one signing the transaction.
|
||||||
|
|
||||||
|
Transactions can be created online or offline by anyone, even if the person creating the transaction is not an authorized signer on the account. For example an accounts payable clerk might process payable cheques for signature by the CEO. Similarly, an accounts payable clerk can create bitcoin transactions and then have the CEO apply digital signatures to make them valid. While a cheque references a specific account as the source of the funds, a bitcoin transaction references a specific previous transaction as its source, rather than an account.
|
||||||
|
|
||||||
Once a transaction has been created, it is signed by the owner (or owners) of the source funds. If it was properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of funds. Finally, the valid transaction has to reach the bitcoin network so that it can be propagated until it reaches a miner for inclusion in the pubic ledger, the blockchain.
|
Once a transaction has been created, it is signed by the owner (or owners) of the source funds. If it was properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of funds. Finally, the valid transaction has to reach the bitcoin network so that it can be propagated until it reaches a miner for inclusion in the pubic ledger, the blockchain.
|
||||||
|
|
||||||
[[tx_bcast]]
|
[[tx_bcast]]
|
||||||
==== Broadcasting Transactions to the Bitcoin Network
|
==== Broadcasting Transactions to the Bitcoin Network
|
||||||
|
|
||||||
First, a transaction needs to be delivered to the bitcoin network so that it can be propagated and be included in the blockchain. In essence, a bitcoin transaction is just 300-400 bytes of data and has to reach any one of tens of thousands of bitcoin nodes. The sender does not need to trust the nodes they use to broadcast the transaction, as long as they use more than one to ensure that it propagates. The nodes don't need to trust the sender or establish the sender's "identity". Since the transaction is signed and contains no confidential information, private keys or credentials, it can be publicly broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network. As long as the transaction can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node. Bitcoin transactions can therefore be transmitted to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copying and pasting into a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hopping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a public forum or sent as a text message or Skype chat message. Bitcoin has turned money into a data structure, making it virtually impossible to stop anyone from creating and executing a bitcoin transaction.
|
First, a transaction needs to be delivered to the bitcoin network so that it can be propagated and be included in the blockchain. In essence, a bitcoin transaction is just 300-400 bytes of data and has to reach any one of tens of thousands of bitcoin nodes. The sender does not need to trust the nodes they use to broadcast the transaction, as long as they use more than one to ensure that it propagates. The nodes don't need to trust the sender or establish the sender's "identity". Since the transaction is signed and contains no confidential information, private keys or credentials, it can be publicly broadcast using any underlying network transport that is convenient. Unlike credit card transactions, for example, which contain sensitive information and can only be transmitted on encrypted networks, a bitcoin transaction can be sent over any network. As long as the transaction can reach a bitcoin node that will propagate it into the bitcoin network, it doesn't matter how it is transported to the first node.
|
||||||
|
|
||||||
|
Bitcoin transactions can therefore be transmitted to the bitcoin network over insecure networks such as Wifi, Bluetooth, NFC, Chirp, barcodes or by copying and pasting into a web form. In extreme cases, a bitcoin transaction could be transmitted over packet radio, satellite relay or shortwave using burst transmission, spread spectrum or frequency hopping to evade detection and jamming. A bitcoin transaction could even be encoded as smileys (emoticons) and posted in a public forum or sent as a text message or Skype chat message. Bitcoin has turned money into a data structure, making it virtually impossible to stop anyone from creating and executing a bitcoin transaction.
|
||||||
|
|
||||||
[[tx_propagation]]
|
[[tx_propagation]]
|
||||||
==== Propagating Transactions on the Bitcoin Network
|
==== Propagating Transactions on the Bitcoin Network
|
||||||
|
|
||||||
Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is connected and a success message will be returned synchronously to the originator. If the transaction is invalid, the node will reject it and synchronously return a rejection message to the originator. The bitcoin network is a peer-to-peer network meaning that each bitcoin node is connected to a few other bitcoin nodes that it discovers during startup through the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed topology or any structure making all nodes equal peers. Messages, including transactions and blocks, are propagated from each node to the peers to which it is connected. A new validated transaction injected into any node on the network will be sent to 3 to 4 of the neighboring nodes, each of which will send it to 3 to 4 more nodes and so on. In this way, within a few seconds a valid transaction will propagate in an exponentially expanding ripple across the network until all connected nodes have received it. The bitcoin network is designed to propagate transactions and blocks to all nodes in an efficient and resilient manner that is resistant to attacks. To prevent spamming, denial of service attacks, or other nuisance attacks against the bitcoin system, every node will independently validate every transaction before propagating it further. A malformed transaction will not get beyond one node. The rules by which transactions are validated are explained in more detail in <<tx_validation>>.
|
Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is connected and a success message will be returned synchronously to the originator. If the transaction is invalid, the node will reject it and synchronously return a rejection message to the originator.
|
||||||
|
|
||||||
[[tx_mining]]
|
The bitcoin network is a peer-to-peer network meaning that each bitcoin node is connected to a few other bitcoin nodes that it discovers during startup through the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed topology or any structure making all nodes equal peers. Messages, including transactions and blocks, are propagated from each node to the peers to which it is connected. A new validated transaction injected into any node on the network will be sent to 3 to 4 of the neighboring nodes, each of which will send it to 3 to 4 more nodes and so on. In this way, within a few seconds a valid transaction will propagate in an exponentially expanding ripple across the network until all connected nodes have received it.
|
||||||
==== Mining Transactions into Blocks
|
|
||||||
|
|
||||||
Some of the nodes in the bitcoin network participate in "mining". Mining is the process creating new blocks of transactions that will become part of the blockchain. Miners collect transactions and group them into blocks, they then attempt to prove each block with the proof-of-work algorithm. Blocks with a valid proof of work are added to and extend the linked chain of blocks called the blockchain. Once a transaction is added to the blockchain, the new owner of the funds can reference it in a new transaction and spend the funds.
|
|
||||||
|
|
||||||
The blockchain forms the authoritative ledger of all transactions since bitcoin's beginning in 2009. The blockchain is the subject of the next chapter, where we will examine the formation of the authoritative record through the competitive process of proof-of-work, also known as mining.
|
|
||||||
|
|
||||||
|
The bitcoin network is designed to propagate transactions and blocks to all nodes in an efficient and resilient manner that is resistant to attacks. To prevent spamming, denial of service attacks, or other nuisance attacks against the bitcoin system, every node will independently validate every transaction before propagating it further. A malformed transaction will not get beyond one node. The rules by which transactions are validated are explained in more detail in <<tx_verification>>.
|
||||||
|
|
||||||
[[tx_structure]]
|
[[tx_structure]]
|
||||||
=== Transaction Structure
|
=== Transaction Structure
|
||||||
|
|
||||||
A transaction is a data structure that encodes a transfer of value from a source of funds, called an "input", to a destination, called an "output". Transaction inputs and outputs are not related to accounts or identities. Instead you should think of them as bitcoin amounts, chunks of bitcoin, being locked with a specific secret which only the owner, or person who knows the secret, can unlock.
|
A transaction is a _data structure_ that encodes a transfer of value from a source of funds, called an _input_, to a destination, called an _output_. Transaction inputs and outputs are not related to accounts or identities. Instead you should think of them as bitcoin amounts, chunks of bitcoin, being locked with a specific secret which only the owner, or person who knows the secret, can unlock.
|
||||||
|
|
||||||
A transaction contains a number of fields, as follows:
|
A transaction contains a number of fields, as follows:
|
||||||
|
|
||||||
@ -58,7 +61,10 @@ A transaction contains a number of fields, as follows:
|
|||||||
| 4 bytes | Locktime | A unix timestamp or block number
|
| 4 bytes | Locktime | A unix timestamp or block number
|
||||||
|=======
|
|=======
|
||||||
|
|
||||||
Note: Locktime defines the earliest time that a transaction can be added to the blockchain. It is set to zero in most transactions to indicate immediate execution. If locktime is non-zero and below 500 million, it is interpreted as a block height, meaning the transaction is not included in the blockchain prior to the specified block height. If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not included in the blockchain prior to the specified time. The use of locktime is equivalent to post-dating a paper cheque.
|
.Transaction Locktime
|
||||||
|
****
|
||||||
|
Locktime defines the earliest time that a transaction can be added to the blockchain. It is set to zero in most transactions to indicate immediate execution. If locktime is non-zero and below 500 million, it is interpreted as a block height, meaning the transaction is not included in the blockchain prior to the specified block height. If it is above 500 million, it is interpreted as a Unix Epoch timestamp (seconds since Jan-1-1970) and the transaction is not included in the blockchain prior to the specified time. The use of locktime is equivalent to post-dating a paper cheque.
|
||||||
|
****
|
||||||
|
|
||||||
[[tx_inputs_outputs]]
|
[[tx_inputs_outputs]]
|
||||||
=== Transaction Outputs and Inputs
|
=== Transaction Outputs and Inputs
|
||||||
@ -72,7 +78,11 @@ There are no accounts or balances in bitcoin, there are only _unspent transactio
|
|||||||
|
|
||||||
A UTXO can have an arbitrary value denominated as a multiple of satoshis. Just like dollars can be divided down to two decimal places as cents, bitcoins can be divided down to eight decimal places as satoshis. While UTXO can be any arbitrary value, once created it is indivisible just like a coin that cannot be cut in half. If a UTXO is larger than the desired value of a transaction, it must still be consumed in its entirety and change must be generated in the transaction. In other words, if you have a 20 bitcoin UTXO and want to pay 1 bitcoin, your transaction must consume the entire 20 bitcoin UTXO and produce two outputs: one paying 1 bitcoin to your desired recipient and another paying 19 bitcoin in change back to your wallet. As a result, most bitcoin transactions will generate change.
|
A UTXO can have an arbitrary value denominated as a multiple of satoshis. Just like dollars can be divided down to two decimal places as cents, bitcoins can be divided down to eight decimal places as satoshis. While UTXO can be any arbitrary value, once created it is indivisible just like a coin that cannot be cut in half. If a UTXO is larger than the desired value of a transaction, it must still be consumed in its entirety and change must be generated in the transaction. In other words, if you have a 20 bitcoin UTXO and want to pay 1 bitcoin, your transaction must consume the entire 20 bitcoin UTXO and produce two outputs: one paying 1 bitcoin to your desired recipient and another paying 19 bitcoin in change back to your wallet. As a result, most bitcoin transactions will generate change.
|
||||||
|
|
||||||
In simple terms, transactions consume the sender's available UTXO and create new UTXO locked to the recipient's bitcoin address. Imagine a shopper buying a $1.50 beverage, reaching into their wallet and trying to find a combination of coins and bank notes to cover the $1.50 cost. The shopper will choose exact change if available (a dollar bill and two quarters), or a combination of smaller denominations (six quarters), or if necessary, a larger unit such as a five dollar bank note. If they hand too much money, say $5, to the shop owner they will expect $3.50 change, which they will return to their wallet and have available for future transactions. Similarly, a bitcoin transaction must be created from a user's UTXO in whatever denominations that user has available. They cannot cut a UTXO in half any more than they can cut a dollar bill in half and use it as currency. The user's wallet application will typically select from the user's available UTXO various units to compose an amount greater than or equal to the desired transaction amount. As with real life, the bitcoin application can use several strategies to satisfy the purchase amount: combining several smaller units, finding exact change, or using a single unit larger than the transaction value and making change. All of this complex assembly of spendable UTXO is done by the user's wallet automatically and is invisible to users. It is only relevant if you are programmatically constructing raw transactions from UTXO.
|
Imagine a shopper buying a $1.50 beverage, reaching into their wallet and trying to find a combination of coins and bank notes to cover the $1.50 cost. The shopper will choose exact change if available (a dollar bill and two quarters), or a combination of smaller denominations (six quarters), or if necessary, a larger unit such as a five dollar bank note. If they hand too much money, say $5, to the shop owner they will expect $3.50 change, which they will return to their wallet and have available for future transactions.
|
||||||
|
|
||||||
|
Similarly, a bitcoin transaction must be created from a user's UTXO in whatever denominations that user has available. They cannot cut a UTXO in half any more than they can cut a dollar bill in half and use it as currency. The user's wallet application will typically select from the user's available UTXO various units to compose an amount greater than or equal to the desired transaction amount.
|
||||||
|
|
||||||
|
As with real life, the bitcoin application can use several strategies to satisfy the purchase amount: combining several smaller units, finding exact change, or using a single unit larger than the transaction value and making change. All of this complex assembly of spendable UTXO is done by the user's wallet automatically and is invisible to users. It is only relevant if you are programmatically constructing raw transactions from UTXO.
|
||||||
|
|
||||||
The UTXO consumed by a transaction are called transaction inputs, while the UTXO created by a transaction are called transaction outputs. This way, chunks of bitcoin value move forward from owner to owner in a chain of transactions consuming and creating UTXO. Transactions consume UTXO unlocking it with the signature of the current owner and create UTXO locking it to the bitcoin address of the new owner.
|
The UTXO consumed by a transaction are called transaction inputs, while the UTXO created by a transaction are called transaction outputs. This way, chunks of bitcoin value move forward from owner to owner in a chain of transactions consuming and creating UTXO. Transactions consume UTXO unlocking it with the signature of the current owner and create UTXO locking it to the bitcoin address of the new owner.
|
||||||
|
|
||||||
@ -164,7 +174,10 @@ If we run the select-utxo.py script without a parameter it will attempt to const
|
|||||||
----
|
----
|
||||||
$ python select-utxo.py 50000000
|
$ python select-utxo.py 50000000
|
||||||
For transaction amount 50000000 Satoshis (0.500000 bitcoin) use:
|
For transaction amount 50000000 Satoshis (0.500000 bitcoin) use:
|
||||||
([<7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1:0 with 25000000 Satoshis>, <7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818:0 with 16100000 Satoshis>, <6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf:0 with 16050000 Satoshis>], 'Change: 7150000 Satoshis')
|
([<7dbc497969c7475e45d952c4a872e213fb15d45e5cd3473c386a71a1b0c136a1:0 with 25000000 Satoshis>, \
|
||||||
|
<7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818:0 with 16100000 Satoshis>, \
|
||||||
|
<6596fd070679de96e405d52b51b8e1d644029108ec4cbfe451454486796a1ecf:0 with 16050000 Satoshis>],\
|
||||||
|
'Change: 7150000 Satoshis')
|
||||||
----
|
----
|
||||||
====
|
====
|
||||||
|
|
||||||
@ -219,7 +232,11 @@ If you forget to add a change output in a manually constructed transaction you w
|
|||||||
|
|
||||||
Let's see how this works in practice, by looking at Alice's coffee purchase again. Alice wants to spend 0.015 bitcoin to pay for coffee. To ensure this transaction is processed promptly, she will want to include a transaction fee, say 0.001. That will mean that the total cost of the transaction will be 0.016. Her wallet must therefore source a set of UTXO that adds up to 0.016 bitcoin or more and if necessary create change. Let's say her wallet has a 0.2 bitcoin UTXO available. It will therefore need to consume this UTXO, create one output to Bob's Cafe for 0.015, and a second output with 0.184 bitcoin in change back to her own wallet, leaving 0.001 bitcoin unallocated, as an implicit fee for the transaction.
|
Let's see how this works in practice, by looking at Alice's coffee purchase again. Alice wants to spend 0.015 bitcoin to pay for coffee. To ensure this transaction is processed promptly, she will want to include a transaction fee, say 0.001. That will mean that the total cost of the transaction will be 0.016. Her wallet must therefore source a set of UTXO that adds up to 0.016 bitcoin or more and if necessary create change. Let's say her wallet has a 0.2 bitcoin UTXO available. It will therefore need to consume this UTXO, create one output to Bob's Cafe for 0.015, and a second output with 0.184 bitcoin in change back to her own wallet, leaving 0.001 bitcoin unallocated, as an implicit fee for the transaction.
|
||||||
|
|
||||||
Now let's look at a different scenario. Eugenia, our children's charity director in the Philippines has completed a fundraiser to purchase school books for the children. She received several thousand small donations from people all around the world, totaling 50 bitcoin. Now she wants to purchase hundreds of school books from a local publisher, paying in bitcoin. The charity received thousands of small donations from all around the world. As Eugenia's wallet application tries to construct a single larger payment transaction, it must source from the available UTXO set which is composed of many smaller amounts. That means that the resulting transaction will source from more than a hundred small-value UTXO as inputs and only one output, paying the book publisher. A transaction with that many inputs will be larger than one kilobyte, perhaps 2-3 kilobytes in size. As a result, it will require a higher fee than the minimal network fee of 0.0001 bitcoin. Eugenia's wallet application will calculate the appropriate fee by measuring the size of the transaction and multiplying that by the per-kilobyte fee. Many wallets will overpay fees for larger transactions to ensure the transaction is processed promptly. The higher fee is not because Eugenia is spending more money, but because her transaction is more complex and larger in size - the fee is independent of the transaction's bitcoin value.
|
Now let's look at a different scenario. Eugenia, our children's charity director in the Philippines has completed a fundraiser to purchase school books for the children. She received several thousand small donations from people all around the world, totaling 50 bitcoin. Now she wants to purchase hundreds of school books from a local publisher, paying in bitcoin. The charity received thousands of small donations from all around the world, so her wallet is full of very small payments (UTXO).
|
||||||
|
|
||||||
|
As Eugenia's wallet application tries to construct a single larger payment transaction, it must source from the available UTXO set which is composed of many smaller amounts. That means that the resulting transaction will source from more than a hundred small-value UTXO as inputs and only one output, paying the book publisher. A transaction with that many inputs will be larger than one kilobyte, perhaps 2-3 kilobytes in size. As a result, it will require a higher fee than the minimal network fee of 0.0001 bitcoin.
|
||||||
|
|
||||||
|
Eugenia's wallet application will calculate the appropriate fee by measuring the size of the transaction and multiplying that by the per-kilobyte fee. Many wallets will overpay fees for larger transactions to ensure the transaction is processed promptly. The higher fee is not because Eugenia is spending more money, but because her transaction is more complex and larger in size - the fee is independent of the transaction's bitcoin value.
|
||||||
|
|
||||||
[[tx_chains]]
|
[[tx_chains]]
|
||||||
=== Transaction Chaining and Orphan Transactions
|
=== Transaction Chaining and Orphan Transactions
|
||||||
@ -352,7 +369,8 @@ The locking script above can be satisfied with an unlocking script of the form:
|
|||||||
The two scripts together would form the combined validation script below:
|
The two scripts together would form the combined validation script below:
|
||||||
|
|
||||||
----
|
----
|
||||||
<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
|
<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 \
|
||||||
|
<Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
|
||||||
----
|
----
|
||||||
|
|
||||||
When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe's private key which corresponds to the public key hash set as an encumbrance.
|
When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe's private key which corresponds to the public key hash set as an encumbrance.
|
||||||
@ -416,7 +434,8 @@ _Note: The prefix OP_0 is required because of a bug in the original implementati
|
|||||||
|
|
||||||
The two scripts together would form the combined validation script below:
|
The two scripts together would form the combined validation script below:
|
||||||
----
|
----
|
||||||
OP_0 <Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
|
OP_0 <Signature B> <Signature C>\
|
||||||
|
2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
|
||||||
----
|
----
|
||||||
|
|
||||||
When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In this case, the condition is whether the unlocking script has a valid signature from the two private keys that correspond to two of the three public keys set as an encumbrance.
|
When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In this case, the condition is whether the unlocking script has a valid signature from the two private keys that correspond to two of the three public keys set as an encumbrance.
|
||||||
@ -452,7 +471,8 @@ In chapter 1 we introduced Mohammed, an electronics importer based in Dubai. Moh
|
|||||||
The resulting script is quite long and looks like this:
|
The resulting script is quite long and looks like this:
|
||||||
|
|
||||||
----
|
----
|
||||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> \
|
||||||
|
<Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||||
----
|
----
|
||||||
|
|
||||||
While multi-signature scripts are a powerful feature, they are cumbersome to use. Given the script above, Mohammed would have to communicate this script to every customer prior to payment. Each customer would have to use special bitcoin wallet software with the ability to create custom transaction scripts and each customer would have to understand how to create a transaction using custom scripts. Furthermore, the resulting transaction would be about five times larger than a simple payment transaction, as this script contains very long public keys. The burden of that extra-large transaction would be borne by the customer in the form of fees. Finally, a large transaction script like this would be carried in the UTXO set in RAM in every full node, until it was spent. All of these issues make using complex output scripts difficult in practice.
|
While multi-signature scripts are a powerful feature, they are cumbersome to use. Given the script above, Mohammed would have to communicate this script to every customer prior to payment. Each customer would have to use special bitcoin wallet software with the ability to create custom transaction scripts and each customer would have to understand how to create a transaction using custom scripts. Furthermore, the resulting transaction would be about five times larger than a simple payment transaction, as this script contains very long public keys. The burden of that extra-large transaction would be borne by the customer in the form of fees. Finally, a large transaction script like this would be carried in the UTXO set in RAM in every full node, until it was spent. All of these issues make using complex output scripts difficult in practice.
|
||||||
@ -482,18 +502,25 @@ Let's look at Mohammed's company, their complex multi-signature script and the r
|
|||||||
|
|
||||||
First, the multi-signature script that Mohammed's company uses for all incoming payments from customers:
|
First, the multi-signature script that Mohammed's company uses for all incoming payments from customers:
|
||||||
----
|
----
|
||||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> \
|
||||||
|
<Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||||
----
|
----
|
||||||
|
|
||||||
If the placeholders above are replaced by actual public keys (shown below as 520 bit numbers starting with 04) you can see that this script becomes very long:
|
If the placeholders above are replaced by actual public keys (shown below as 520 bit numbers starting with 04) you can see that this script becomes very long:
|
||||||
----
|
----
|
||||||
2
|
2
|
||||||
04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C587
|
04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370\
|
||||||
04A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49
|
D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD\
|
||||||
047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D9977965
|
4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495\
|
||||||
0421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5
|
E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B\
|
||||||
043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800
|
1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8\
|
||||||
5 OP_CHECKMULTISIG
|
CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1\
|
||||||
|
A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CB\
|
||||||
|
D7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4\
|
||||||
|
AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2\
|
||||||
|
AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0\
|
||||||
|
AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AA\
|
||||||
|
B59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG
|
||||||
----
|
----
|
||||||
|
|
||||||
The entire script above can instead be represented by a 20-byte cryptographic hash, by first applying the SHA256 hashing algorithm and then applying the RIPEMD160 algorithm on the result. The 20-byte hash of the above script is:
|
The entire script above can instead be represented by a 20-byte cryptographic hash, by first applying the SHA256 hashing algorithm and then applying the RIPEMD160 algorithm on the result. The 20-byte hash of the above script is:
|
||||||
|
|||||||
@ -1,8 +1,7 @@
|
|||||||
[[ch6]]
|
[[ch6]]
|
||||||
|
[[bitcoin_network]]
|
||||||
== The Bitcoin Network
|
== The Bitcoin Network
|
||||||
|
|
||||||
=== Introduction
|
|
||||||
|
|
||||||
=== Peer-to-Peer Network Architecture
|
=== Peer-to-Peer Network Architecture
|
||||||
|
|
||||||
Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other, that they are all equal, that there are no "special" nodes and that all nodes share the burden of providing network services. The network nodes interconnect in a mesh network with a "flat" topology. There is no "server", no centralized service, and no hierarchy within the network. Nodes in a peer-to-peer network both provide and consume services at the same time with reciprocity acting as the incentive for participation. Peer-to-peer networks are inherently resilient, de-centralized, and open. The pre-eminent example of a P2P network architecture was the early Internet itself, where nodes on the IP network were equal. Today's Internet architecture is more hierarchical, but the Internet Protocol still retains its flat-topology essence. Beyond bitcoin, the largest and most successful application of P2P technologies is file sharing with Napster as the pioneer and bittorrent as the most recent evolution of the architecture.
|
Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other, that they are all equal, that there are no "special" nodes and that all nodes share the burden of providing network services. The network nodes interconnect in a mesh network with a "flat" topology. There is no "server", no centralized service, and no hierarchy within the network. Nodes in a peer-to-peer network both provide and consume services at the same time with reciprocity acting as the incentive for participation. Peer-to-peer networks are inherently resilient, de-centralized, and open. The pre-eminent example of a P2P network architecture was the early Internet itself, where nodes on the IP network were equal. Today's Internet architecture is more hierarchical, but the Internet Protocol still retains its flat-topology essence. Beyond bitcoin, the largest and most successful application of P2P technologies is file sharing with Napster as the pioneer and bittorrent as the most recent evolution of the architecture.
|
||||||
@ -81,8 +80,13 @@ image::images/AddressPropagation.png["AddressPropagation"]
|
|||||||
A node must connect to a few different peers in order to establish diverse paths into the bitcoin network. Paths are not reliable, nodes come and go, and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap. Only one connection is needed to bootstrap, as the first node can offer introductions to its peer nodes and those peers can offer further introductions. It's also unnecessary and wasteful of network resources to connect to more than a handful of nodes. After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
|
A node must connect to a few different peers in order to establish diverse paths into the bitcoin network. Paths are not reliable, nodes come and go, and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap. Only one connection is needed to bootstrap, as the first node can offer introductions to its peer nodes and those peers can offer further introductions. It's also unnecessary and wasteful of network resources to connect to more than a handful of nodes. After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
|
||||||
|
|
||||||
On a node running the Bitcoin Core client, you can list the peer connections with the command +getpeerinfo+:
|
On a node running the Bitcoin Core client, you can list the peer connections with the command +getpeerinfo+:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoin-cli getpeerinfo
|
$ bitcoin-cli getpeerinfo
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
|
----
|
||||||
[
|
[
|
||||||
{
|
{
|
||||||
"addr" : "85.213.199.39:8333",
|
"addr" : "85.213.199.39:8333",
|
||||||
@ -149,6 +153,7 @@ This process of comparing the local blockchain with the peers and retrieving any
|
|||||||
.Node synchronizing the blockchain by retrieving blocks from a peer
|
.Node synchronizing the blockchain by retrieving blocks from a peer
|
||||||
image::images/InventorySynchronization.png["InventorySynchronization"]
|
image::images/InventorySynchronization.png["InventorySynchronization"]
|
||||||
|
|
||||||
|
[[spv_nodes]]
|
||||||
=== Simplified Payment Verification (SPV) Nodes
|
=== Simplified Payment Verification (SPV) Nodes
|
||||||
|
|
||||||
Not all nodes have the ability to store the full blockchain. Many bitcoin clients are designed to run on space- and power-constrained devices, such as smartphones, tablets or embedded systems. For such devices, a _simplified payment verification_ (SPV) method is used to allow them to operate without storing the full blockchain. These types of clients are called SPV clients or lightweight clients. As bitcoin adoption surges, the SPV node is becoming the most common form of bitcoin node, especially for bitcoin wallets.
|
Not all nodes have the ability to store the full blockchain. Many bitcoin clients are designed to run on space- and power-constrained devices, such as smartphones, tablets or embedded systems. For such devices, a _simplified payment verification_ (SPV) method is used to allow them to operate without storing the full blockchain. These types of clients are called SPV clients or lightweight clients. As bitcoin adoption surges, the SPV node is becoming the most common form of bitcoin node, especially for bitcoin wallets.
|
||||||
|
|||||||
@ -1,8 +1,9 @@
|
|||||||
[[ch7]]
|
[[ch7]]
|
||||||
|
[[blockchain]]
|
||||||
== The Blockchain
|
== The Blockchain
|
||||||
|
|
||||||
[[blockchain]]
|
|
||||||
=== The Blockchain
|
=== Introduction
|
||||||
|
|
||||||
The blockchain data structure is an ordered back-linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. The bitcoin core client stores the blockchain metadata using Google's LevelDB database. Blocks are linked "back", each referring to the previous block in the chain. The blockchain is often visualized as a vertical stack, with blocks layered on top of each other and the first block ever serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms like "height" to refer to the distance from the first block, and "top" or "tip" to refer to the most recently added block.
|
The blockchain data structure is an ordered back-linked list of blocks of transactions. The blockchain can be stored as a flat file, or in a simple database. The bitcoin core client stores the blockchain metadata using Google's LevelDB database. Blocks are linked "back", each referring to the previous block in the chain. The blockchain is often visualized as a vertical stack, with blocks layered on top of each other and the first block ever serving as the foundation of the stack. The visualization of blocks stacked on top of each other results in the use of terms like "height" to refer to the distance from the first block, and "top" or "tip" to refer to the most recently added block.
|
||||||
|
|
||||||
@ -72,6 +73,7 @@ The first block in the blockchain is called the _genesis block_ and was created
|
|||||||
Every node always starts with a blockchain of at least one block because the genesis block is statically encoded within the bitcoin client software, such that it cannot be altered. Every node always "knows" the genesis block's hash and structure, the fixed time it was created and even the single transaction within. Thus, every node has the starting point for the blockchain, a secure "root" from which to build a trusted blockchain.
|
Every node always starts with a blockchain of at least one block because the genesis block is statically encoded within the bitcoin client software, such that it cannot be altered. Every node always "knows" the genesis block's hash and structure, the fixed time it was created and even the single transaction within. Thus, every node has the starting point for the blockchain, a secure "root" from which to build a trusted blockchain.
|
||||||
|
|
||||||
See the statically encoded genesis block inside the Bitcoin Core client, in chainparams.cpp:
|
See the statically encoded genesis block inside the Bitcoin Core client, in chainparams.cpp:
|
||||||
|
|
||||||
https://github.com/bitcoin/bitcoin/blob/3955c3940eff83518c186facfec6f50545b5aab5/src/chainparams.cpp#L123
|
https://github.com/bitcoin/bitcoin/blob/3955c3940eff83518c186facfec6f50545b5aab5/src/chainparams.cpp#L123
|
||||||
|
|
||||||
The genesis block has the identifier hash +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+. You can search for that block hash in any block explorer website, such as blockchain.info, and you will find a page describing the contents of this block, with a URL containing that hash:
|
The genesis block has the identifier hash +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+. You can search for that block hash in any block explorer website, such as blockchain.info, and you will find a page describing the contents of this block, with a URL containing that hash:
|
||||||
@ -82,8 +84,12 @@ https://blockexplorer.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c1
|
|||||||
|
|
||||||
Using the Bitcoin Core reference client on the command-line:
|
Using the Bitcoin Core reference client on the command-line:
|
||||||
|
|
||||||
|
[source,bash]
|
||||||
----
|
----
|
||||||
$ bitcoind getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
$ bitcoind getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
|
----
|
||||||
{
|
{
|
||||||
"hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
"hash" : "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
||||||
"confirmations" : 308321,
|
"confirmations" : 308321,
|
||||||
@ -111,6 +117,8 @@ Bitcoin nodes maintain a local copy of the blockchain, starting at the genesis b
|
|||||||
Let's assume, for example, that a node has 277,314 blocks in the local copy of the blockchain. The last block the node knows about is block 277,314, with a block header hash of +00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249+.
|
Let's assume, for example, that a node has 277,314 blocks in the local copy of the blockchain. The last block the node knows about is block 277,314, with a block header hash of +00000000000000027e7ba6fe7bad39faf3b5a83daed765f05f7d1b71a1632249+.
|
||||||
|
|
||||||
The bitcoin node then receives a new block from the network, which it parses as follows:
|
The bitcoin node then receives a new block from the network, which it parses as follows:
|
||||||
|
|
||||||
|
[source,json]
|
||||||
----
|
----
|
||||||
{
|
{
|
||||||
"size" : 43560,
|
"size" : 43560,
|
||||||
@ -125,7 +133,7 @@ The bitcoin node then receives a new block from the network, which it parses as
|
|||||||
"tx" : [
|
"tx" : [
|
||||||
"257e7497fb8bc68421eb2c7b699dbab234831600e7352f0d9e6522c7cf3f6c77",
|
"257e7497fb8bc68421eb2c7b699dbab234831600e7352f0d9e6522c7cf3f6c77",
|
||||||
|
|
||||||
[... many more transactions omitted ...]
|
#[... many more transactions omitted ...]
|
||||||
|
|
||||||
"05cfd38f6ae6aa83674cc99e4d75a1458c165b7ab84725eda41d018a09176634"
|
"05cfd38f6ae6aa83674cc99e4d75a1458c165b7ab84725eda41d018a09176634"
|
||||||
]
|
]
|
||||||
@ -175,7 +183,7 @@ The same method for constructing a tree from four transactions can be generalize
|
|||||||
.A Merkle Tree summarizing many data elements
|
.A Merkle Tree summarizing many data elements
|
||||||
image::images/MerkleTreeLarge.png["merkle_tree_large"]
|
image::images/MerkleTreeLarge.png["merkle_tree_large"]
|
||||||
|
|
||||||
To prove that a specific transaction is included in a block, a node only needs to produce +log~2~(N)+ 32-byte hashes, constituting an _authentication path_ or _merkle path_ connecting the specific transaction to the root of the tree. This is especially important as the number of transactions increases, because the base-2 logarithm of the number of transactions increases much more slowly. This allows bitcoin nodes to efficiently produce paths of ten or twelve hashes (320-384 bytes) which can provide proof of a single transaction out of more than a thousand transactions in a megabyte sized block. In the example below, a node can prove that a transaction K is included in the block by producing a merkle path that is only four 32-byte hashes long (128 bytes total). The path consists of the four hashes H~L~, H~IJ~, H~MNOP~ and H~ABCDEFGH~. With those four hashes provided as an authentication path, any node can prove that H~K~ is included in the merkle root by computing four additional pair-wise hashes H~KL~, H~IJKL~ and H~IJKLMNOP~ that lead to the merkle root.
|
To prove that a specific transaction is included in a block, a node only needs to produce +log~2~(N)+ 32-byte hashes, constituting an _authentication path_ or _merkle path_ connecting the specific transaction to the root of the tree. This is especially important as the number of transactions increases, because the base-2 logarithm of the number of transactions increases much more slowly. This allows bitcoin nodes to efficiently produce paths of ten or twelve hashes (320-384 bytes) which can provide proof of a single transaction out of more than a thousand transactions in a megabyte sized block. In the example below, a node can prove that a transaction K is included in the block by producing a merkle path that is only four 32-byte hashes long (128 bytes total). The path consists of the four hashes (noted in blue in the diagram below) H~L~, H~IJ~, H~MNOP~ and H~ABCDEFGH~. With those four hashes provided as an authentication path, any node can prove that H~K~ (noted in green in the diagram below) is included in the merkle root by computing four additional pair-wise hashes H~KL~, H~IJKL~ and H~IJKLMNOP~ (outlined in a dotted line in the diagram below) that lead to the merkle root.
|
||||||
|
|
||||||
[[merkle_tree_path]]
|
[[merkle_tree_path]]
|
||||||
.A Merkle Path used to prove inclusion of a data element
|
.A Merkle Path used to prove inclusion of a data element
|
||||||
|
|||||||
@ -2,23 +2,31 @@
|
|||||||
== Mining and Consensus
|
== Mining and Consensus
|
||||||
|
|
||||||
[[mining]]
|
[[mining]]
|
||||||
=== Introduction - Mining and Consensus
|
=== Introduction
|
||||||
|
|
||||||
Mining is the process by which new bitcoin is added to the money supply. Mining also serves to secure the bitcoin system against fraudulent transactions or transactions spending the same amount of bitcoin more than once, known as a double-spend. Miners provide processing power to the bitcoin network in exchange for the opportunity to be rewarded bitcoin. Miners validate new transactions and record them on the global ledger. A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes, thereby adding those transactions to the blockchain. Transactions that become part of a block and added to the blockchain are considered "confirmed", which allows the new owners of bitcoin to spend the bitcoin they received in those transactions. Miners receive two types of reward for mining: new coins created with each new block and transaction fees from all the transactions included in the block. To earn this reward, the miners compete to solve a difficult mathematical problem based on a cryptographic hash algorithm. The solution to the problem, called the Proof-of-Work, is included in the new block and acts as proof that the miner expended significant computing effort. The competition to solve the Proof-of-Work algorithm to earn reward and the right to record transactions on the blockchain is the basis for bitcoin's security model.
|
Mining is the process by which new bitcoin is added to the money supply. Mining also serves to secure the bitcoin system against fraudulent transactions or transactions spending the same amount of bitcoin more than once, known as a double-spend. Miners provide processing power to the bitcoin network in exchange for the opportunity to be rewarded bitcoin.
|
||||||
|
|
||||||
|
Miners validate new transactions and record them on the global ledger. A new block, containing transactions that occurred since the last block, is "mined" every 10 minutes, thereby adding those transactions to the blockchain. Transactions that become part of a block and added to the blockchain are considered "confirmed", which allows the new owners of bitcoin to spend the bitcoin they received in those transactions.
|
||||||
|
|
||||||
|
Miners receive two types of reward for mining: new coins created with each new block and transaction fees from all the transactions included in the block. To earn this reward, the miners compete to solve a difficult mathematical problem based on a cryptographic hash algorithm. The solution to the problem, called the Proof-of-Work, is included in the new block and acts as proof that the miner expended significant computing effort. The competition to solve the Proof-of-Work algorithm to earn reward and the right to record transactions on the blockchain is the basis for bitcoin's security model.
|
||||||
|
|
||||||
The process of new coin generation is called mining, because the reward is designed to simulate diminishing returns, just like mining for precious metals. Bitcoin's money supply is created through mining, similar to how a central bank issues new money by printing bank notes. The amount of newly created bitcoin a miner can add to a block decreases approximately every four years (or precisely every 210,000 blocks). It started at 50 bitcoin per block in January of 2009 and halved to 25 bitcoin per block in November of 2012. It will halve again to 12.5 bitcoin per block sometime in 2016. Based on this formula, bitcoin mining rewards decrease exponentially until approximately the year 2140 when all bitcoin (20.99999998 million) will have been issued. After 2140, no new bitcoins will be issued.
|
The process of new coin generation is called mining, because the reward is designed to simulate diminishing returns, just like mining for precious metals. Bitcoin's money supply is created through mining, similar to how a central bank issues new money by printing bank notes. The amount of newly created bitcoin a miner can add to a block decreases approximately every four years (or precisely every 210,000 blocks). It started at 50 bitcoin per block in January of 2009 and halved to 25 bitcoin per block in November of 2012. It will halve again to 12.5 bitcoin per block sometime in 2016. Based on this formula, bitcoin mining rewards decrease exponentially until approximately the year 2140 when all bitcoin (20.99999998 million) will have been issued. After 2140, no new bitcoins will be issued.
|
||||||
|
|
||||||
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 winning bitcoin miner gets to "keep the change" on the transactions included in the winning block. Today, the fees represent 0.5% or less of a bitcoin miner's income, the vast majority coming from the newly minted bitcoins. However, as the reward decreases over time and the number of transactions per block increases, a greater proportion of bitcoin mining earnings will come from fees. After 2140, all bitcoin miner earnings will be in the form of transaction fees.
|
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 winning bitcoin miner gets to "keep the change" on the transactions included in the winning block. Today, the fees represent 0.5% or less of a bitcoin miner's income, the vast majority coming from the newly minted bitcoins. However, as the reward decreases over time and the number of transactions per block increases, a greater proportion of bitcoin mining earnings will come from fees. After 2140, all bitcoin miner earnings will be in the form of transaction fees.
|
||||||
|
|
||||||
The word "mining" is somewhat misleading. By evoking the extraction of precious metals, it focuses our attention on the reward for mining, the new bitcoins in each block. While mining is incentivized by this reward, the primary purpose of mining is not the reward or the generation of new coins. If you view mining only as the process by which coins are created you are mistaking the means (incentives) as a goal of the process. Mining is the main process of the de-centralized clearinghouse, by which transactions are validated and cleared. Mining secures the bitcoin system and enables the emergence of network-wide consensus without a central authority. Mining is the invention that makes bitcoin special, a de-centralized security mechanism that is the basis for peer-to-peer digital cash. The reward of newly minted coins and transaction fees is an incentive scheme that aligns the actions of miners with the security of the network, while simultaneously implementing the monetary supply.
|
The word "mining" is somewhat misleading. By evoking the extraction of precious metals, it focuses our attention on the reward for mining, the new bitcoins in each block. While mining is incentivized by this reward, the primary purpose of mining is not the reward or the generation of new coins. If you view mining only as the process by which coins are created you are mistaking the means (incentives) as a goal of the process. Mining is the main process of the de-centralized clearinghouse, by which transactions are validated and cleared. Mining secures the bitcoin system and enables the emergence of network-wide consensus without a central authority.
|
||||||
|
|
||||||
|
Mining is the invention that makes bitcoin special, a de-centralized security mechanism that is the basis for peer-to-peer digital cash. The reward of newly minted coins and transaction fees is an incentive scheme that aligns the actions of miners with the security of the network, while simultaneously implementing the monetary supply.
|
||||||
|
|
||||||
In this chapter, we will first examine mining as a monetary supply mechanism and then look at the most important function of mining, the de-centralized emergent consensus mechanism that underpins bitcoin's security.
|
In this chapter, we will first examine mining as a monetary supply mechanism and then look at the most important function of mining, the de-centralized emergent consensus mechanism that underpins bitcoin's security.
|
||||||
|
|
||||||
==== Bitcoin Economics and Currency Creation
|
==== Bitcoin Economics and Currency Creation
|
||||||
|
|
||||||
Bitcoins are "minted" during the creation of each block at a fixed and diminishing rate. Each block, generated on average every 10 minutes, contains entirely new bitcoins, created from nothing. Every 210,000 blocks or approximately every four years the currency issuance rate is decreased by 50%. For the first four years of operation of the network, each block contained 50 new bitcoin. In November of 2012, the new bitcoin issuance rate was decreased to 25 bitcoin per block and it will decrease again to 12.5 bitcoin at block 420,000, which will be mined sometime in 2016. The rate of new coins decreases like this exponentially over 64 "halvings", until block 13,230,000 (mined approximately in year 2137) when it reaches the minimum currency unit of 1 satoshi. Finally, after 13.44 million blocks, in approximately 2140, all 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin will be issued. Thereafter, blocks will contain no new bitcoin, and miners will be rewarded solely through the transaction fees.
|
Bitcoins are "minted" during the creation of each block at a fixed and diminishing rate. Each block, generated on average every 10 minutes, contains entirely new bitcoins, created from nothing. Every 210,000 blocks or approximately every four years the currency issuance rate is decreased by 50%. For the first four years of operation of the network, each block contained 50 new bitcoin.
|
||||||
|
|
||||||
In the example code below, we calculate the total amount of bitcoin that will be issued:
|
In November of 2012, the new bitcoin issuance rate was decreased to 25 bitcoin per block and it will decrease again to 12.5 bitcoin at block 420,000, which will be mined sometime in 2016. The rate of new coins decreases like this exponentially over 64 "halvings", until block 13,230,000 (mined approximately in year 2137) when it reaches the minimum currency unit of 1 satoshi. Finally, after 13.44 million blocks, in approximately 2140, all 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin will be issued. Thereafter, blocks will contain no new bitcoin, and miners will be rewarded solely through the transaction fees.
|
||||||
|
|
||||||
|
In the example code in <<max_money_>>, we calculate the total amount of bitcoin that will be issued:
|
||||||
|
|
||||||
[[max_money]]
|
[[max_money]]
|
||||||
.A script for calculating how much total bitcoin will be issued
|
.A script for calculating how much total bitcoin will be issued
|
||||||
@ -47,8 +55,8 @@ image::images/BitcoinMoneySupply.png["BitcoinMoneySupply"]
|
|||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
===== Deflationary Money
|
.Deflationary Money
|
||||||
|
****
|
||||||
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 the money has more purchasing power over time.
|
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 the 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 people will tend to hoard money instead of spending 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.
|
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 people will tend to hoard money instead of spending 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.
|
||||||
@ -56,6 +64,7 @@ Many economists argue that a deflationary economy is a disaster that should be a
|
|||||||
Bitcoin experts argue that deflation is not bad *per se*. Rather, deflation is associated 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 a predictably constrained supply.
|
Bitcoin experts argue that deflation is not bad *per se*. Rather, deflation is associated 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 a 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.
|
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.
|
||||||
|
****
|
||||||
|
|
||||||
=== De-centralized Consensus
|
=== De-centralized Consensus
|
||||||
|
|
||||||
@ -199,7 +208,8 @@ The first transaction added to the block is a special transaction, called a _gen
|
|||||||
====
|
====
|
||||||
[source, bash]
|
[source, bash]
|
||||||
----
|
----
|
||||||
$ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1
|
$ bitcoin-cli getrawtransaction\
|
||||||
|
d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f 1
|
||||||
----
|
----
|
||||||
====
|
====
|
||||||
|
|
||||||
@ -209,7 +219,9 @@ $ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda1
|
|||||||
[source,json]
|
[source,json]
|
||||||
----
|
----
|
||||||
{
|
{
|
||||||
"hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
|
"hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff\
|
||||||
|
0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d\
|
||||||
|
6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
|
||||||
"txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
|
"txid" : "d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f",
|
||||||
"version" : 1,
|
"version" : 1,
|
||||||
"locktime" : 0,
|
"locktime" : 0,
|
||||||
@ -224,7 +236,8 @@ $ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda1
|
|||||||
"value" : 25.09094928,
|
"value" : 25.09094928,
|
||||||
"n" : 0,
|
"n" : 0,
|
||||||
"scriptPubKey" : {
|
"scriptPubKey" : {
|
||||||
"asm" : "02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21 OP_CHECKSIG",
|
"asm" : "02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21\
|
||||||
|
OP_CHECKSIG",
|
||||||
"hex" : "2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
|
"hex" : "2102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac",
|
||||||
"reqSigs" : 1,
|
"reqSigs" : 1,
|
||||||
"type" : "pubkey",
|
"type" : "pubkey",
|
||||||
@ -328,7 +341,7 @@ In a generation transaction, the first two fields are set to values that do not
|
|||||||
|
|
||||||
Generation transactions do not have an unlocking script (a.k.a. scriptSig) field. Instead, this field is replaced by coinbase data, which must be between 2 and 100 bytes. Except for the first few bytes (see below) the rest of the coinbase data can be used by miners in any way they want; it is arbitrary data.
|
Generation transactions do not have an unlocking script (a.k.a. scriptSig) field. Instead, this field is replaced by coinbase data, which must be between 2 and 100 bytes. Except for the first few bytes (see below) the rest of the coinbase data can be used by miners in any way they want; it is arbitrary data.
|
||||||
|
|
||||||
In the genesis block, for example, Satoshi Nakamoto added the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the coinbase data, using it as a proof of the date and to convey a message. Currently, miners use the coinbase data to include extra nonce values (see <<mining>>) and strings identifying the mining pool, as we will see in the following sections.
|
In the genesis block, for example, Satoshi Nakamoto added the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the coinbase data, using it as a proof of the date and to convey a message. Currently, miners use the coinbase data to include extra nonce values and strings identifying the mining pool, as we will see in the following sections.
|
||||||
|
|
||||||
The first few bytes of the coinbase used to be arbitrary, but that is no longer the case. As per Bitcoin Improvement Proposal 34 (BIP0034), version-2 blocks (blocks with the version field set to 2) must contain the block height index as a script "push" operation in the beginning of the coinbase field.
|
The first few bytes of the coinbase used to be arbitrary, but that is no longer the case. As per Bitcoin Improvement Proposal 34 (BIP0034), version-2 blocks (blocks with the version field set to 2) must contain the block height index as a script "push" operation in the beginning of the coinbase field.
|
||||||
|
|
||||||
@ -336,7 +349,7 @@ In block 277,316 we see that the coinbase (see <<generation_tx_example>>), which
|
|||||||
|
|
||||||
The first byte, +03+ instructs the script execution engine to push the next 3 bytes onto the script stack (see <<tx_script_ops_table_pushdata>>). The next 3 bytes, +0x443b04+, are the block height encoded in little-endian format (backwards, least significant byte first). Reverse the order of the bytes and the result is +0x043b44+ which is 277,316 in decimal.
|
The first byte, +03+ instructs the script execution engine to push the next 3 bytes onto the script stack (see <<tx_script_ops_table_pushdata>>). The next 3 bytes, +0x443b04+, are the block height encoded in little-endian format (backwards, least significant byte first). Reverse the order of the bytes and the result is +0x043b44+ which is 277,316 in decimal.
|
||||||
|
|
||||||
The next few hexadecimal digits (+03858402062+) are used to encode an extra _nonce_, or random value, used to find a suitable Proof-of-Work solution. This is discussed in more detail in the next section on <<mining>>
|
The next few hexadecimal digits (+03858402062+) are used to encode an extra _nonce_ (See <<extra_nonce_>>), or random value, used to find a suitable Proof-of-Work solution.
|
||||||
|
|
||||||
The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string "/P2SH/", which indicates that the mining node that mined this block supports the Pay-to-Script-Hash (P2SH) improvement defined in BIP0016. The introduction of the P2SH capability required a "vote" by miners to endorse either BIP0016 or BIP0017. Those endorsing the BIP0016 implementation were to include "/P2SH/" in their coinbase data. Those endorsing the BIP0017 implementation of P2SH were to include the string "p2sh/CHV" in their coinbase data. The BIP0016 was elected as the winner, and many miners continued including the string "/P2SH/" in their coinbase to indicate support for this feature.
|
The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string "/P2SH/", which indicates that the mining node that mined this block supports the Pay-to-Script-Hash (P2SH) improvement defined in BIP0016. The introduction of the P2SH capability required a "vote" by miners to endorse either BIP0016 or BIP0017. Those endorsing the BIP0016 implementation were to include "/P2SH/" in their coinbase data. Those endorsing the BIP0017 implementation of P2SH were to include the string "p2sh/CHV" in their coinbase data. The BIP0016 was elected as the winner, and many miners continued including the string "/P2SH/" in their coinbase to indicate support for this feature.
|
||||||
|
|
||||||
@ -540,6 +553,7 @@ As you can see, increasing the difficulty by 1 bit causes an exponential increas
|
|||||||
|
|
||||||
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 than 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 100 Peta Hashes per second of processing power to bear, which will be able to find a block in about 10 minutes on average.
|
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 than 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 100 Peta Hashes per second of processing power to bear, which will be able to find a block in about 10 minutes on average.
|
||||||
|
|
||||||
|
[[difficulty_bits]]
|
||||||
==== Difficulty Representation
|
==== Difficulty Representation
|
||||||
|
|
||||||
In <<block277316>> we saw that the block contains the difficulty target, in a notation called "difficulty bits" or just "bits", which in block 277,316 has the value of +0x1903a30c+. This notation expresses the difficulty target as a coefficient/exponent format, with the first two hexadecimal digits for the exponent and the next six hex digits as the coefficient. In this block, therefore, the exponent is +0x19+ and the coefficient is +0x03a30c+.
|
In <<block277316>> we saw that the block contains the difficulty target, in a notation called "difficulty bits" or just "bits", which in block 277,316 has the value of +0x1903a30c+. This notation expresses the difficulty target as a coefficient/exponent format, with the first two hexadecimal digits for the exponent and the next six hex digits as the coefficient. In this block, therefore, the exponent is +0x19+ and the coefficient is +0x03a30c+.
|
||||||
@ -568,6 +582,7 @@ switching back to hexadecimal:
|
|||||||
|
|
||||||
This means that a valid block for height 277,316 is one that has a block header hash that is less than the target. In binary that number would have more than the first 60 bits set to zero. With this level of difficulty, a single miner processing 1 trillion hashes per second (1 tera-hash per second or 1 TH/sec) would only find a solution once every 8,496 blocks or once every 59 days, on average.
|
This means that a valid block for height 277,316 is one that has a block header hash that is less than the target. In binary that number would have more than the first 60 bits set to zero. With this level of difficulty, a single miner processing 1 trillion hashes per second (1 tera-hash per second or 1 TH/sec) would only find a solution once every 8,496 blocks or once every 59 days, on average.
|
||||||
|
|
||||||
|
[[difficulty_target]]
|
||||||
==== Difficulty Target and Re-Targeting
|
==== Difficulty Target and Re-Targeting
|
||||||
|
|
||||||
As we saw above the target determines the difficulty and therefore affects how long it takes to find a solution to the Proof-of-Work algorithm. This leads to the obvious questions: Why is the difficulty adjustable, who adjusts it and how?
|
As we saw above the target determines the difficulty and therefore affects how long it takes to find a solution to the Proof-of-Work algorithm. This leads to the obvious questions: Why is the difficulty adjustable, who adjusts it and how?
|
||||||
@ -588,30 +603,30 @@ Here's the code used in the Bitcoin Core client
|
|||||||
[source,cpp]
|
[source,cpp]
|
||||||
----
|
----
|
||||||
|
|
||||||
// Go back by what we want to be 14 days worth of blocks
|
// Go back by what we want to be 14 days worth of blocks
|
||||||
const CBlockIndex* pindexFirst = pindexLast;
|
const CBlockIndex* pindexFirst = pindexLast;
|
||||||
for (int i = 0; pindexFirst && i < Params().Interval()-1; i++)
|
for (int i = 0; pindexFirst && i < Params().Interval()-1; i++)
|
||||||
pindexFirst = pindexFirst->pprev;
|
pindexFirst = pindexFirst->pprev;
|
||||||
assert(pindexFirst);
|
assert(pindexFirst);
|
||||||
|
|
||||||
// Limit adjustment step
|
// Limit adjustment step
|
||||||
int64_t nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
|
int64_t nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
|
||||||
LogPrintf(" nActualTimespan = %d before bounds\n", nActualTimespan);
|
LogPrintf(" nActualTimespan = %d before bounds\n", nActualTimespan);
|
||||||
if (nActualTimespan < Params().TargetTimespan()/4)
|
if (nActualTimespan < Params().TargetTimespan()/4)
|
||||||
nActualTimespan = Params().TargetTimespan()/4;
|
nActualTimespan = Params().TargetTimespan()/4;
|
||||||
if (nActualTimespan > Params().TargetTimespan()*4)
|
if (nActualTimespan > Params().TargetTimespan()*4)
|
||||||
nActualTimespan = Params().TargetTimespan()*4;
|
nActualTimespan = Params().TargetTimespan()*4;
|
||||||
|
|
||||||
// Retarget
|
// Retarget
|
||||||
uint256 bnNew;
|
uint256 bnNew;
|
||||||
uint256 bnOld;
|
uint256 bnOld;
|
||||||
bnNew.SetCompact(pindexLast->nBits);
|
bnNew.SetCompact(pindexLast->nBits);
|
||||||
bnOld = bnNew;
|
bnOld = bnNew;
|
||||||
bnNew *= nActualTimespan;
|
bnNew *= nActualTimespan;
|
||||||
bnNew /= Params().TargetTimespan();
|
bnNew /= Params().TargetTimespan();
|
||||||
|
|
||||||
if (bnNew > Params().ProofOfWorkLimit())
|
if (bnNew > Params().ProofOfWorkLimit())
|
||||||
bnNew = Params().ProofOfWorkLimit();
|
bnNew = Params().ProofOfWorkLimit();
|
||||||
|
|
||||||
----
|
----
|
||||||
====
|
====
|
||||||
@ -719,8 +734,6 @@ It is theoretically possible for a fork to extend to two blocks, if two blocks a
|
|||||||
|
|
||||||
Bitcoin's block interval of 10 minutes is a design compromise between fast confirmation times (settlement of transactions) and the probability of a fork. A faster block time would make transactions clear faster but lead to more frequent blockchain forks, whereas a slower block time would decrease the number of forks but make settlement slower.
|
Bitcoin's block interval of 10 minutes is a design compromise between fast confirmation times (settlement of transactions) and the probability of a fork. A faster block time would make transactions clear faster but lead to more frequent blockchain forks, whereas a slower block time would decrease the number of forks but make settlement slower.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
=== Mining and the Hashing Race
|
=== Mining and the Hashing Race
|
||||||
|
|
||||||
Bitcoin mining is an extremely competitive industry. The hashing power has increased exponentially, every year of bitcoin's existence. Some years the growth has reflected a complete change of technology, such as in 2010 and 2011 when many miners switched from using CPU mining to Graphical Processing Unit (GPU) mining and Field Programmable Gate Array (FPGA) mining. In 2013 the introduction of Application Specific Integrated Circuit (ASIC) mining lead to another giant leap in mining power, by placing the SHA-256 function directly on silicon chips specialized for the purpose of mining. The first such chips could deliver more mining power in a single box than the entire bitcoin network in 2010.
|
Bitcoin mining is an extremely competitive industry. The hashing power has increased exponentially, every year of bitcoin's existence. Some years the growth has reflected a complete change of technology, such as in 2010 and 2011 when many miners switched from using CPU mining to Graphical Processing Unit (GPU) mining and Field Programmable Gate Array (FPGA) mining. In 2013 the introduction of Application Specific Integrated Circuit (ASIC) mining lead to another giant leap in mining power, by placing the SHA-256 function directly on silicon chips specialized for the purpose of mining. The first such chips could deliver more mining power in a single box than the entire bitcoin network in 2010.
|
||||||
@ -746,10 +759,12 @@ image::images/BitcoinDifficulty.png["BitcoinDifficulty"]
|
|||||||
|
|
||||||
In the last two years, the ASIC mining chips have become denser and denser, approaching the cutting edge of silicon fabrication with a feature size (resolution) of 22 nanometers (nm). Currently, ASIC manufacturers are aiming to overtake general purpose CPU chip manufacturers, designing chips with a feature size of 16nm, because the profitability of mining is driving this industry even faster than general computing. There are no more giant leaps left in bitcoin mining, because the industry has reached the forefront of "Moore's Law". Still, the mining power of the network continues to advance at an exponential pace as the race for higher density chips is matched with a race for higher density data centers where thousands of these chips can be deployed. It's no longer about how much mining can be done with one chip but how many chips can be squeezed into a building, while still dissipating the heat and providing adequate power.
|
In the last two years, the ASIC mining chips have become denser and denser, approaching the cutting edge of silicon fabrication with a feature size (resolution) of 22 nanometers (nm). Currently, ASIC manufacturers are aiming to overtake general purpose CPU chip manufacturers, designing chips with a feature size of 16nm, because the profitability of mining is driving this industry even faster than general computing. There are no more giant leaps left in bitcoin mining, because the industry has reached the forefront of "Moore's Law". Still, the mining power of the network continues to advance at an exponential pace as the race for higher density chips is matched with a race for higher density data centers where thousands of these chips can be deployed. It's no longer about how much mining can be done with one chip but how many chips can be squeezed into a building, while still dissipating the heat and providing adequate power.
|
||||||
|
|
||||||
|
[[extra_nonce]]
|
||||||
==== The Extra Nonce Solution
|
==== The Extra Nonce Solution
|
||||||
|
|
||||||
Since 2012 bitcoin mining has evolved to resolve a fundamental limitation in the structure of the block header. In the early days of bitcoin, a miner could find a block by iterating through the nonce until the resulting hash was below the target. As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. However, this was easily resolved by updating the block timestamp to account for the elapsed time. Since the timestamp is part of the header, the change would allow miners to iterate through the values of the nonce again with different results. Once mining hardware exceeded 4 GH/sec however, this approach became increasingly difficult as the nonce values were exhausted in less than a second. As ASIC mining equipment started pushing and then exceeding the TH/sec hash rate, the mining software needed more space for nonce values in order to find valid blocks. The timestamp could be stretched a bit, but moving it too far into the future would cause the block to become invalid. A new source of "change" was needed in the block header. The solution was to use the coinbase transaction as a source of extra nonce values. Since the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks. The coinbase transaction is included in the merkle tree, which means that any change in the coinbase script causes the merkle root to change. Eight bytes of extra nonce, plus the 4 bytes of "standard" nonce allow miners to explore a total 2^96^ (8 followed by 28 zeroes) possibilities *per second* without having to modify the timestamp. If, in the future, a miner could run through all these possibilities, they could then modify the timestamp. There is also more space in the coinbase script for future expansion of the extra nonce space.
|
Since 2012 bitcoin mining has evolved to resolve a fundamental limitation in the structure of the block header. In the early days of bitcoin, a miner could find a block by iterating through the nonce until the resulting hash was below the target. As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. However, this was easily resolved by updating the block timestamp to account for the elapsed time. Since the timestamp is part of the header, the change would allow miners to iterate through the values of the nonce again with different results. Once mining hardware exceeded 4 GH/sec however, this approach became increasingly difficult as the nonce values were exhausted in less than a second. As ASIC mining equipment started pushing and then exceeding the TH/sec hash rate, the mining software needed more space for nonce values in order to find valid blocks. The timestamp could be stretched a bit, but moving it too far into the future would cause the block to become invalid. A new source of "change" was needed in the block header. The solution was to use the coinbase transaction as a source of extra nonce values. Since the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks. The coinbase transaction is included in the merkle tree, which means that any change in the coinbase script causes the merkle root to change. Eight bytes of extra nonce, plus the 4 bytes of "standard" nonce allow miners to explore a total 2^96^ (8 followed by 28 zeroes) possibilities *per second* without having to modify the timestamp. If, in the future, a miner could run through all these possibilities, they could then modify the timestamp. There is also more space in the coinbase script for future expansion of the extra nonce space.
|
||||||
|
|
||||||
|
[[mining_pools]]
|
||||||
==== Mining Pools
|
==== Mining Pools
|
||||||
|
|
||||||
In this highly competitive environment, individual miners working alone (also known as solo miners) don't stand a chance. The likelihood of them finding a block to offset their electricity and hardware costs is so low that it represents a gamble, like playing the lottery. Even the fastest consumer ASIC mining system cannot keep up with commercial systems that stack tens of thousands of these chips in giant warehouses near hydro-electric power stations. Miners now collaborate to form mining pools, pooling their hashing power and sharing the reward among thousands of participants. By participating in a pool, miners get a smaller share of the overall reward, but typically get rewarded every day, reducing uncertainty.
|
In this highly competitive environment, individual miners working alone (also known as solo miners) don't stand a chance. The likelihood of them finding a block to offset their electricity and hardware costs is so low that it represents a gamble, like playing the lottery. Even the fastest consumer ASIC mining system cannot keep up with commercial systems that stack tens of thousands of these chips in giant warehouses near hydro-electric power stations. Miners now collaborate to form mining pools, pooling their hashing power and sharing the reward among thousands of participants. By participating in a pool, miners get a smaller share of the overall reward, but typically get rewarded every day, reducing uncertainty.
|
||||||
|
|||||||
@ -1,9 +1,9 @@
|
|||||||
[[ch9]]
|
[[ch9]]
|
||||||
== Alternative Chains, Currencies, and Applications
|
== Alternative Chains, Currencies, and Applications
|
||||||
|
|
||||||
Bitcoin was neither the beginning nor the end of the digital currency evolution. It came from twenty years of research in distributed systems and currencies and brought a revolutionary new technology into the space: the de-centralized consensus mechanism based on Proof-of-Work. This invention at the heart of bitcoin has ushered a wave of innovation in currencies, financial services, economics, distributed systems, voting systems, corporate governance, and contracts.
|
Bitcoin was the result of twenty years of research in distributed systems and currencies and brought a revolutionary new technology into the space: the de-centralized consensus mechanism based on Proof-of-Work. This invention at the heart of bitcoin has ushered a wave of innovation in currencies, financial services, economics, distributed systems, voting systems, corporate governance, and contracts.
|
||||||
|
|
||||||
In this chapter we'll examine the many offshoots of the bitcoin and blockchain inventions, the alternative chains, currencies, and applications built since the introduction of this technology in 2009.
|
In this chapter we'll examine the many offshoots of the bitcoin and blockchain inventions, the alternative chains, currencies, and applications built since the introduction of this technology in 2009. Mostly, we will look at _alt-coins_, which are digital currencies implemented using the same design pattern as bitcoin, but with a completely separate blockchain and network.
|
||||||
|
|
||||||
For every alt-coin mentioned in this chapter, 50 or more will go unmentioned, eliciting howls of anger from their creators and fans. The purpose of this chapter is not to evaluate or qualify alt-coins, or to mention the most "significant" ones based on some subjective assessment. Instead, we will highlight a few examples that show the breadth and variety of the ecosystem, noting the first-of-a-kind for each innovation or significant differentiation. Some of the most interesting examples of alt-coins are in fact complete failures from a monetary perspective. That perhaps makes them even more interesting for study and highlights the fact that this chapter is not to be used as an investment guide.
|
For every alt-coin mentioned in this chapter, 50 or more will go unmentioned, eliciting howls of anger from their creators and fans. The purpose of this chapter is not to evaluate or qualify alt-coins, or to mention the most "significant" ones based on some subjective assessment. Instead, we will highlight a few examples that show the breadth and variety of the ecosystem, noting the first-of-a-kind for each innovation or significant differentiation. Some of the most interesting examples of alt-coins are in fact complete failures from a monetary perspective. That perhaps makes them even more interesting for study and highlights the fact that this chapter is not to be used as an investment guide.
|
||||||
|
|
||||||
@ -71,7 +71,7 @@ Counterparty is another protocol layer implemented on top of bitcoin. Counterpar
|
|||||||
|
|
||||||
=== Alt-coins
|
=== Alt-coins
|
||||||
|
|
||||||
Alt-coins are digital currencies implemented using the same design pattern as bitcoin, but with a completely separate blockchain and network. The vast majority of alt-coins are derived from bitcoin's source code, also known as "forks". Some are implemented "from scratch" based on the blockchain model but without using any of bitcoin's source code. Alt-coins and alt-chains (in the next section) are both separate implementations of blockchain technology and both forms use their own blockchain. The difference in the terms is to indicate that alt-coins are primarily used as currency, whereas alt-chains are used for other purposes, not primarily currency.
|
The vast majority of alt-coins are derived from bitcoin's source code, also known as "forks". Some are implemented "from scratch" based on the blockchain model but without using any of bitcoin's source code. Alt-coins and alt-chains (in the next section) are both separate implementations of blockchain technology and both forms use their own blockchain. The difference in the terms is to indicate that alt-coins are primarily used as currency, whereas alt-chains are used for other purposes, not primarily currency.
|
||||||
|
|
||||||
The first alt-coins appeared in August of 2011 as forks of the bitcoin source code. Strictly speaking, the first major fork of bitcoin's code was not an alt-coin but the alt-chain _Namecoin_, which will be discussed in the next section.
|
The first alt-coins appeared in August of 2011 as forks of the bitcoin source code. Strictly speaking, the first major fork of bitcoin's code was not an alt-coin but the alt-chain _Namecoin_, which will be discussed in the next section.
|
||||||
|
|
||||||
@ -297,8 +297,12 @@ The Namecoin client is very similar to Bitcoin Core, as it is derived from the s
|
|||||||
|
|
||||||
For example, to register the domain +mastering-bitcoin.bit+, we use the command +name_new+ as follows:
|
For example, to register the domain +mastering-bitcoin.bit+, we use the command +name_new+ as follows:
|
||||||
|
|
||||||
|
[source.bash]
|
||||||
----
|
----
|
||||||
$ namecoind name_new d/mastering-bitcoin
|
$ namecoind name_new d/mastering-bitcoin
|
||||||
|
----
|
||||||
|
[source,json]
|
||||||
|
----
|
||||||
[
|
[
|
||||||
"21cbab5b1241c6d1a6ad70a2416b3124eb883ac38e423e5ff591d1968eb6664a",
|
"21cbab5b1241c6d1a6ad70a2416b3124eb883ac38e423e5ff591d1968eb6664a",
|
||||||
"a05555e0fc56c023"
|
"a05555e0fc56c023"
|
||||||
@ -343,6 +347,7 @@ Ethereum is a Turing-complete contract processing and execution platform based o
|
|||||||
|
|
||||||
Ethereum can implement quite complex systems that are otherwise implemented as alt-chains themselves. For example, below is a Namecoin-like name registration contract written in Ethereum (or more accurately, written in a high-level language that can be compiled to Ethereum code):
|
Ethereum can implement quite complex systems that are otherwise implemented as alt-chains themselves. For example, below is a Namecoin-like name registration contract written in Ethereum (or more accurately, written in a high-level language that can be compiled to Ethereum code):
|
||||||
|
|
||||||
|
[source,python]
|
||||||
----
|
----
|
||||||
if !contract.storage[msg.data[0]]: # Is the key not yet taken?
|
if !contract.storage[msg.data[0]]: # Is the key not yet taken?
|
||||||
# Then take it!
|
# Then take it!
|
||||||
|
|||||||
@ -5,7 +5,14 @@ import hashlib
|
|||||||
|
|
||||||
text = "I am Satoshi Nakamoto"
|
text = "I am Satoshi Nakamoto"
|
||||||
|
|
||||||
for nonce in xrange(20): # iterate nonce from 0 to 19
|
# iterate nonce from 0 to 19
|
||||||
input = text + str(nonce) # add the nonce to the end of the text
|
for nonce in xrange(20):
|
||||||
hash = hashlib.sha256(input).hexdigest() # calculate the SHA-256 hash of the input (text+nonce)
|
|
||||||
print input, '=>', hash # show the input and hash result
|
# add the nonce to the end of the text
|
||||||
|
input = text + str(nonce)
|
||||||
|
|
||||||
|
# calculate the SHA-256 hash of the input (text+nonce)
|
||||||
|
hash = hashlib.sha256(input).hexdigest()
|
||||||
|
|
||||||
|
# show the input and hash result
|
||||||
|
print input, '=>', hash
|
||||||
21
code/proof-of-work-example.py
Normal file → Executable file
21
code/proof-of-work-example.py
Normal file → Executable file
@ -8,11 +8,13 @@ max_nonce = 2 ** 32 # 4 billion
|
|||||||
|
|
||||||
def proof_of_work(header, difficulty_bits):
|
def proof_of_work(header, difficulty_bits):
|
||||||
|
|
||||||
|
# calculate the difficulty target
|
||||||
target = 2 ** (256-difficulty_bits)
|
target = 2 ** (256-difficulty_bits)
|
||||||
|
|
||||||
for nonce in xrange(max_nonce):
|
for nonce in xrange(max_nonce):
|
||||||
hash_result = hashlib.sha256(str(header)+str(nonce)).hexdigest()
|
hash_result = hashlib.sha256(str(header)+str(nonce)).hexdigest()
|
||||||
|
|
||||||
|
# check if this is a valid result, below the target
|
||||||
if long(hash_result, 16) < target:
|
if long(hash_result, 16) < target:
|
||||||
print "Success with nonce %d" % nonce
|
print "Success with nonce %d" % nonce
|
||||||
print "Hash is %s" % hash_result
|
print "Hash is %s" % hash_result
|
||||||
@ -26,21 +28,34 @@ if __name__ == '__main__':
|
|||||||
|
|
||||||
nonce = 0
|
nonce = 0
|
||||||
hash_result = ''
|
hash_result = ''
|
||||||
|
|
||||||
|
# difficulty from 0 to 31 bits
|
||||||
for difficulty_bits in xrange(32):
|
for difficulty_bits in xrange(32):
|
||||||
|
|
||||||
difficulty = 2 ** difficulty_bits
|
difficulty = 2 ** difficulty_bits
|
||||||
print "Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits)
|
print "Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits)
|
||||||
|
|
||||||
print "Starting search..."
|
print "Starting search..."
|
||||||
|
|
||||||
|
# checkpoint the current time
|
||||||
start_time = time.time()
|
start_time = time.time()
|
||||||
new_block = 'test block with transactions' + hash_result # make a new block which includes the hash from the previous block
|
|
||||||
(hash_result, nonce) = proof_of_work(new_block, difficulty_bits) # find a nonce for the new block
|
# make a new block which includes the hash from the previous block
|
||||||
|
# we fake a block of transactions - just a string
|
||||||
|
new_block = 'test block with transactions' + hash_result
|
||||||
|
|
||||||
|
# find a valid nonce for the new block
|
||||||
|
(hash_result, nonce) = proof_of_work(new_block, difficulty_bits)
|
||||||
|
|
||||||
|
# checkpoint how long it took to find a result
|
||||||
end_time = time.time()
|
end_time = time.time()
|
||||||
|
|
||||||
elapsed_time = end_time - start_time
|
elapsed_time = end_time - start_time
|
||||||
print "Elapsed Time: %.4f seconds" % elapsed_time
|
print "Elapsed Time: %.4f seconds" % elapsed_time
|
||||||
|
|
||||||
if elapsed_time > 0:
|
if elapsed_time > 0:
|
||||||
|
|
||||||
|
# estimate the hashes per second
|
||||||
hash_power = float(long(nonce)/elapsed_time)
|
hash_power = float(long(nonce)/elapsed_time)
|
||||||
print "Hashing Power: %ld hashes per second" % hash_power
|
print "Hashing Power: %ld hashes per second" % hash_power
|
||||||
|
|
||||||
|
|||||||
@ -56,7 +56,9 @@ This icon indicates a warning or caution.
|
|||||||
|
|
||||||
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
|
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
|
||||||
|
|
||||||
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Book Title_ by Some Author (O’Reilly). Copyright 2012 Some Copyright Holder, 978-0-596-xxxx-x.”
|
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos (O’Reilly). Copyright 2014 Andreas M. Antonopoulos, 978-1449374044.”
|
||||||
|
|
||||||
|
Some editions of this books are offered under an open source license, such as CC-BY-NC (creativecommons.org) in which case the terms of that licenses apply.
|
||||||
|
|
||||||
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at pass:[<email>permissions@oreilly.com</email>].
|
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at pass:[<email>permissions@oreilly.com</email>].
|
||||||
|
|
||||||
@ -192,6 +194,8 @@ wallet::
|
|||||||
|
|
||||||
=== Acknowledgments
|
=== Acknowledgments
|
||||||
|
|
||||||
|
==== Technical Review
|
||||||
|
|
||||||
==== Early Release Draft (Github Contributions)
|
==== Early Release Draft (Github Contributions)
|
||||||
|
|
||||||
Many contributors offered comments, corrections and additions to the early-release draft on Github. Thank you all for your contributions to this book. Notable contributors included the following:
|
Many contributors offered comments, corrections and additions to the early-release draft on Github. Thank you all for your contributions to this book. Notable contributors included the following:
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user