mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-02-02 02:41:42 +00:00
Merge branch 'develop'
This commit is contained in:
Andreas M. Antonopoulos
commit
8e0f98c04d
30
README.md
30
README.md
@ -1,38 +1,42 @@
|
||||
# Mastering Bitcoin
|
||||
|
||||
Mastering Bitcoin is a book for developers, but the first two chapters cover bitcoin at a level that is approachable to non-programmers. Anyone with a basic understanding of technology can read the first two chapters and get a great understanding of bitcoin.
|
||||
Mastering Bitcoin is a book for developers, but the first two chapters cover bitcoin at a level that is approachable to non-programmers. Anyone with a basic understanding of technology can read the first two chapters and get a great understanding of bitcoin.
|
||||
|
||||
This repository contains the complete [first edition](https://github.com/bitcoinbook/bitcoinbook/tree/first_edition) and the draft of the [second edition](https://github.com/bitcoinbook/bitcoinbook/tree/develop), currently in progress, scheduled for publication in Q1'2017.
|
||||
This repository contains the complete [first edition](https://github.com/bitcoinbook/bitcoinbook/tree/first_edition), published in Dec 2014, and the complete [second edition](https://github.com/bitcoinbook/bitcoinbook/tree/second_edition), published in June 2017.
|
||||
|
||||
# Issues, Errors, Comments, Contributions
|
||||
|
||||
If you know how to make a pull request to contribute a fix, please write the correction and use a pull request to submit it for consideration. Otherwise, please submit an issue, explaining the error or comment. If you would like to contribute extensive changes or new material, please coordinate with the author first. Contact forms can be found on his website https://antonopoulos.com/
|
||||
If you know how to make a pull request to contribute a fix, please write the correction and use a pull request to submit it for consideration against the [develop branch](https://github.com/bitcoinbook/bitcoinbook/tree/develop). Otherwise, please submit an issue, explaining the error or comment. If you would like to contribute extensive changes or new material, please coordinate with the author first. Contact forms can be found on his website https://antonopoulos.com/
|
||||
|
||||
# Published
|
||||
|
||||
"Mastering Bitcoin (First Edition)" is now available in print and e-book formats by many book sellers including [Amazon](http://www.amazon.com/Mastering-Bitcoin-Unlocking-Digital-Crypto-Currencies/dp/1449374042)
|
||||
, [Barnes & Nobles](http://www.barnesandnoble.com/w/mastering-bitcoin-andreas-m-antonopoulos/1119253039?ean=9781449374044
|
||||
) and [O'Reilly Media](http://shop.oreilly.com/product/0636920032281.do). Mastering Bitcoin (First Edition) is also published in Japanese, Korean and Chinese (Simplified) by publishers in the respective countries.
|
||||
"Mastering Bitcoin (Second Edition): Programming the Open Blockchain" is now available in paperback and e-book formats by many book sellers, worldwide:
|
||||
|
||||
Mastering Bitcoin has been translated by volunteers into more than a dozen languages. Translations are available for free under CC-BY-SA license on https://bitcoinbook.info
|
||||
* [Amazon](https://www.amazon.com/Mastering-Bitcoin-Programming-Open-Blockchain/dp/1491954388)
|
||||
|
||||
# Source
|
||||
Mastering Bitcoin (First Edition) is also published in Japanese, Korean and Chinese (Simplified) by publishers in the respective countries.
|
||||
|
||||
The book's source code, found in this repository, is kept synchronized with the print and ebook editions.
|
||||
Mastering Bitcoin (Open Edition), based on the First Edition has been translated by volunteers into more than a dozen languages. Translations are available for free under CC-BY-SA license on https://bitcoinbook.info
|
||||
|
||||
# Source
|
||||
|
||||
The book's source code, found in this repository, is kept synchronized with the print and ebook editions.
|
||||
|
||||
## Mastering Bitcoin - First Edition
|
||||
|
||||
The tags [Edition1Print1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print1), [Edition1Print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print2) correspond to the two existing prints of the Mastering Bitcoin (First Edition) as published by O'Reilly Media.
|
||||
The tags [Edition1Print1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print1), [Edition1Print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print2) correspond to the two existing prints of the Mastering Bitcoin (First Edition) as published by O'Reilly Media.
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">Mastering Bitcoin - First Edition</span> by <a xmlns:cc="http://creativecommons.org/ns#" href="http://antonopoulos.com/" property="cc:attributionName" rel="cc:attributionURL">Andreas M. Antonopoulos LLC</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
|
||||
|
||||
This "Free Culture" compliant license was approved by my publisher O'Reilly Media (http://oreilly.com), who understand the value of open source. O'Reilly Media is not just the world's best publisher of technical books but also a strong supporter of an open culture and the sharing of knowledge.
|
||||
This "Free Culture" compliant license was approved by my publisher O'Reilly Media (http://oreilly.com), who understand the value of open source. O'Reilly Media is not just the world's best publisher of technical books but also a strong supporter of an open culture and the sharing of knowledge.
|
||||
|
||||
Thank you O'Reilly Media!
|
||||
|
||||
## Mastering Bitcoin - Second Edition
|
||||
|
||||
The [develop branch](https://github.com/bitcoinbook/bitcoinbook/tree/develop), containing the most recent changes you see here is the in-progress drafting of Mastering Bitcoin (Second Edition).
|
||||
The [second_edition](https://github.com/bitcoinbook/bitcoinbook/tree/second_edition) branch, is the source for the published versions of Mastering Bitcoin (Second Edition).
|
||||
|
||||
The tag [second_edition_print_1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print_1), corresponds to the first print of the second edition.
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" property="dct:title">Mastering Bitcoin - Second Edition</span> by <a xmlns:cc="http://creativecommons.org/ns#" href="https://antonopoulos.com/" property="cc:attributionName" rel="cc:attributionURL">Andreas M. Antonopoulos LLC</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>.
|
||||
|
||||
@ -41,4 +45,4 @@ It is expected that the second edition will be released under a CC-BY-SA license
|
||||
# Translations
|
||||
|
||||
If you are interested in translating this book, please join a team of volunteers at https://www.transifex.com/bitcoinbook/mastering-bitcoin/
|
||||
Free copies of "Mastering Bitcoin Open Edition", translated in many languages, can be downloaded from https://bitcoinbook.info
|
||||
Free copies of "Mastering Bitcoin Open Edition", translated in many languages, can be downloaded from https://bitcoinbook.info
|
||||
|
||||
221
ch03.asciidoc
221
ch03.asciidoc
@ -25,7 +25,7 @@ image::images/mbc2_0301.png["Bitcoin Core Architecture"]
|
||||
[[compiling_core]]
|
||||
=== Compiling Bitcoin Core from the Source Code
|
||||
|
||||
((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as a ZIP archive or by cloning the authoritative source repository from GitHub. ((("GitHub bitcoin page")))On the https://github.com/bitcoin/bitcoin[GitHub bitcoin page], select Download ZIP from the sidebar. Alternatively, use the git command line to create a local copy of the source code on your system.
|
||||
((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as a archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g. +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page].
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -37,10 +37,11 @@ image::images/mbc2_0301.png["Bitcoin Core Architecture"]
|
||||
----
|
||||
$ git clone https://github.com/bitcoin/bitcoin.git
|
||||
Cloning into 'bitcoin'...
|
||||
remote: Counting objects: 66193, done.
|
||||
remote: Total 66193 (delta 0), reused 0 (delta 0), pack-reused 66193
|
||||
Receiving objects: 100% (66193/66193), 63.39 MiB | 574.00 KiB/s, done.
|
||||
Resolving deltas: 100% (48395/48395), done.
|
||||
remote: Counting objects: 102071, done.
|
||||
remote: Compressing objects: 100% (10/10), done.
|
||||
Receiving objects: 100% (102071/102071), 86.38 MiB | 730.00 KiB/s, done.
|
||||
remote: Total 102071 (delta 4), reused 5 (delta 1), pack-reused 102060
|
||||
Resolving deltas: 100% (76168/76168), done.
|
||||
Checking connectivity... done.
|
||||
$
|
||||
----
|
||||
@ -72,18 +73,18 @@ v0.12.0rc2
|
||||
...
|
||||
----
|
||||
|
||||
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 preceding list, select the highest version release, which at the time of writing was v0.11.2. To synchronize the local code with this version, 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 preceding list, select the highest version release, which at the time of writing was v0.15.0. To synchronize the local code with this version, use the +git checkout+ command:
|
||||
|
||||
----
|
||||
$ git checkout v0.11.2
|
||||
HEAD is now at 7e27892... Merge pull request #6975
|
||||
$ git checkout v0.15.0
|
||||
HEAD is now at 3751912... Merge #11295: doc: Old fee_estimates.dat are discarded by 0.15.0
|
||||
----
|
||||
|
||||
You can confirm you have the desired version "checked out" by issuing the command +git status+:
|
||||
|
||||
----
|
||||
$ git status
|
||||
HEAD detached at v0.11.2
|
||||
HEAD detached at v0.15.0
|
||||
nothing to commit, working directory clean
|
||||
----
|
||||
|
||||
@ -93,11 +94,6 @@ nothing to commit, working directory clean
|
||||
|
||||
Carefully review the build prerequisites, which are in the first part of the build documentation. These are libraries that must be present on your system before you can begin to compile bitcoin. If these prerequisites are missing, the build process will fail with an error. If this happens because you missed a prerequisite, you can install it and then resume the build process from where you left off. Assuming the prerequisites are installed, you start the build process by generating a set of build scripts using the _autogen.sh_ script.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
((("autogen/configure/make system", seealso="Bitcoin Core")))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 following example. 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 following examples.
|
||||
====
|
||||
|
||||
----
|
||||
$ ./autogen.sh
|
||||
...
|
||||
@ -119,7 +115,7 @@ The _autogen.sh_ script creates a set of automatic configuration scripts that wi
|
||||
|
||||
----
|
||||
$ ./configure --help
|
||||
`configure' configures Bitcoin Core 0.11.2 to adapt to many kinds of systems.
|
||||
`configure' configures Bitcoin Core 0.15.0 to adapt to many kinds of systems.
|
||||
|
||||
Usage: ./configure [OPTION]... [VAR=VALUE]...
|
||||
|
||||
@ -198,10 +194,10 @@ Making all in src
|
||||
$
|
||||
----
|
||||
|
||||
If all goes well, Bitcoin Core is now compiled. The final step is to install the various executables on your system using the +sudo make install+ command. You may be prompted for your user password, because this step requires administrative privileges:
|
||||
On a fast system with more than one CPU, you might want to set the number of parallel compile jobs. For instance, +make -j 2+ will use two cores if they are available. If all goes well, Bitcoin Core is now compiled. You should run the unit test suite with +make check+ to ensure the linked libraries are not broken in obvious ways. The final step is to install the various executables on your system using the +make install+ command. You may be prompted for your user password, because this step requires administrative privileges:
|
||||
|
||||
----
|
||||
$ sudo make install
|
||||
$ make check && sudo make install
|
||||
Password:
|
||||
Making install in src
|
||||
../build-aux/install-sh -c -d '/usr/local/lib'
|
||||
@ -247,43 +243,28 @@ Why would you want to run a node? Here are some of the most common reasons:
|
||||
|
||||
If you're reading this book and interested in developing bitcoin software, you should be running your own node.
|
||||
|
||||
==== Running Bitcoin Core for the First Time
|
||||
|
||||
((("security", see="also warnings and cautions")))((("passwords", "core node first run")))((("Bitcoin Core", "running core nodes", "first run")))When you first run +bitcoind+, it will remind you to create a configuration file with a strong password for the JSON-RPC interface. This password controls access to the application programming interface (API) offered by Bitcoin Core.
|
||||
|
||||
Run +bitcoind+ by typing ++**bitcoind**++ into the terminal:
|
||||
|
||||
----
|
||||
$ bitcoind
|
||||
Error: To use the "-server" option, you must set a rpcpassword in the configuration file:
|
||||
/home/ubuntu/.bitcoin/bitcoin.conf
|
||||
It is recommended you use the following random password:
|
||||
rpcuser=bitcoinrpc
|
||||
rpcpassword=2XA4DuKNCbtZXsBQRRNDEwEY2nM6M4H9Tx5dFjoAVVbK
|
||||
(you do not need to remember this password)
|
||||
The username and password MUST NOT be the same.
|
||||
If the file does not exist, create it with owner-readable-only file permissions.
|
||||
It is also recommended to set alertnotify so you are notified of problems;
|
||||
for example: alertnotify=echo %s | mail -s "Bitcoin Alert" admin@foo.com
|
||||
----
|
||||
|
||||
As you can see, the first time you run +bitcoind+ it tells you that you need to build a configuration file, with at least an +rpcuser+ and +rpcpassword+ entry. Additionally, it is recommended that you set up the alerting mechanism. In the next section we will examine the various configuration options and set up a configuration file.
|
||||
|
||||
==== Configuring the Bitcoin Core Node
|
||||
|
||||
((("Bitcoin Core", "running core nodes", "configuring")))((("warnings and cautions", "password creation")))((("passwords", "creating")))((("security", "passwords")))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 in the book. Create a file inside the _.bitcoin_ directory (under your user's home directory) so that it is named _.bitcoin/bitcoin.conf_ and provide a username and password:
|
||||
|
||||
[source,ini]
|
||||
----
|
||||
rpcuser=bitcoinrpc
|
||||
rpcpassword=CHANGE_THIS
|
||||
----
|
||||
|
||||
In addition to the +rpcuser+ and +rpcpassword+ options, Bitcoin Core offers more than 100 configuration options that modify the behavior of the network node, the storage of the blockchain, and many other aspects of its operation. To see a listing of these options, run +bitcoind --help+:
|
||||
((("Bitcoin Core", "running core nodes", "configuring")))((("warnings and cautions", "password creation")))((("passwords", "creating")))((("security", "passwords")))Bitcoin Core will look for a configuration file in its data directory on every start. In this section we will examine the various configuration options and set up a configuration file. To locate the configuration file, run +bitcoind -printtoconsole+ in your terminal and look for the first couple of lines.
|
||||
|
||||
----
|
||||
bitcoind --help
|
||||
Bitcoin Core Daemon version v0.11.2
|
||||
$ bitcoind -printtoconsole
|
||||
Bitcoin version v0.15.0
|
||||
Using the 'standard' SHA256 implementation
|
||||
Using data directory /home/ubuntu/.bitcoin/
|
||||
Using config file /home/ubuntu/.bitcoin/bitcoin.conf
|
||||
...
|
||||
[a lot more debug output]
|
||||
...
|
||||
----
|
||||
|
||||
You can hit Ctrl-C to shutdown the node once you determined the location of the config file. Usually the configuration file is inside the _.bitcoin_ data directory under your user's home directory. Open the configuration file in your preferred editor.
|
||||
|
||||
Bitcoin Core offers more than 100 configuration options that modify the behavior of the network node, the storage of the blockchain, and many other aspects of its operation. To see a listing of these options, run +bitcoind --help+:
|
||||
|
||||
----
|
||||
$ bitcoind --help
|
||||
Bitcoin Core Daemon version v0.15.0
|
||||
|
||||
Usage:
|
||||
bitcoind [options] Start Bitcoin Core Daemon
|
||||
@ -291,10 +272,10 @@ Usage:
|
||||
Options:
|
||||
|
||||
-?
|
||||
This help message
|
||||
Print this help message and exit
|
||||
|
||||
-alerts
|
||||
Receive and display P2P network alerts (default: 1)
|
||||
-version
|
||||
Print version and exit
|
||||
|
||||
-alertnotify=<cmd>
|
||||
Execute command when a relevant alert is received or we see a really
|
||||
@ -303,9 +284,8 @@ Options:
|
||||
[many more options]
|
||||
...
|
||||
|
||||
-rpcsslciphers=<ciphers>
|
||||
Acceptable ciphers (default:
|
||||
TLSv1.2+HIGH:TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH)
|
||||
-rpcthreads=<n>
|
||||
Set the number of threads to service RPC calls (default: 4)
|
||||
----
|
||||
|
||||
((("configuration options", seealso="Bitcoin Core")))Here are some of the most important options that you can set in the configuration file, or as command-line parameters to +bitcoind+:
|
||||
@ -320,13 +300,15 @@ prune:: Reduce the disk space requirements to this many megabytes, by deleting o
|
||||
|
||||
txindex:: Maintain an index of all transactions. This means a complete copy of the blockchain that allows you to programmatically retrieve any transaction by ID.
|
||||
|
||||
dbcache:: The size of the UTXO cache. The default is 300 MiB. Increase this on high-end hardware and reduce the size on low-end hardware to save memory at the expense of slow disk IO.
|
||||
|
||||
maxconnections:: Set the maximum number of nodes from which to accept connections. Reducing this from the default will reduce your bandwidth consumption. Use if you have a data cap or pay by the gigabyte.
|
||||
|
||||
maxmempool:: Limit the transaction memory pool to this many megabytes. Use it to reduce memory use of the node.
|
||||
maxmempool:: Limit the transaction memory pool to this many megabytes. Use it to reduce memory use on memory-constrained nodes.
|
||||
|
||||
maxreceivebuffer/maxsendbuffer:: Limit per-connection memory buffer to this many multiples of 1000 bytes. Use on memory-constrained nodes.
|
||||
|
||||
minrelaytxfee:: Set the minimum fee transaction you will relay. Below this value, the transaction is treated as zero fee. Use this on memory-constrained nodes to reduce the size of the in-memory transaction pool.
|
||||
minrelaytxfee:: Set the minimum fee rate for transaction you will relay. Below this value, the transaction is treated nonstandard, rejected from the transaction pool and not relayed.
|
||||
|
||||
|
||||
[[txindex]]
|
||||
@ -344,8 +326,6 @@ minrelaytxfee:: Set the minimum fee transaction you will relay. Below this value
|
||||
alertnotify=myemailscript.sh "Alert: %s"
|
||||
datadir=/lotsofspace/bitcoin
|
||||
txindex=1
|
||||
rpcuser=bitcoinrpc
|
||||
rpcpassword=CHANGE_THIS
|
||||
----
|
||||
====
|
||||
|
||||
@ -358,12 +338,10 @@ rpcpassword=CHANGE_THIS
|
||||
alertnotify=myemailscript.sh "Alert: %s"
|
||||
maxconnections=15
|
||||
prune=5000
|
||||
minrelaytxfee=0.0001
|
||||
maxmempool=200
|
||||
dbcache=150
|
||||
maxmempool=150
|
||||
maxreceivebuffer=2500
|
||||
maxsendbuffer=500
|
||||
rpcuser=bitcoinrpc
|
||||
rpcpassword=CHANGE_THIS
|
||||
----
|
||||
====
|
||||
|
||||
@ -372,26 +350,32 @@ Once you've edited the configuration file and set the options that best represen
|
||||
----
|
||||
$ bitcoind -printtoconsole
|
||||
|
||||
Bitcoin version v0.11.20.0
|
||||
Using OpenSSL version OpenSSL 1.0.2e 3 Dec 2015
|
||||
Startup time: 2015-01-02 19:56:17
|
||||
Using data directory /tmp/bitcoin
|
||||
Using config file /tmp/bitcoin/bitcoin.conf
|
||||
Using at most 125 connections (275 file descriptors available)
|
||||
Bitcoin version v0.15.0
|
||||
InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
|
||||
Assuming ancestors of block 0000000000000000003b9ce759c2a087d52abc4266f8f4ebd6d768b89defa50a have valid signatures.
|
||||
Using the 'standard' SHA256 implementation
|
||||
Default data directory /home/ubuntu/.bitcoin
|
||||
Using data directory /lotsofspace/.bitcoin
|
||||
Using config file /home/ubuntu/.bitcoin/bitcoin.conf
|
||||
Using at most 125 automatic connections (1048576 file descriptors available)
|
||||
Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
|
||||
Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
|
||||
Using 2 threads for script verification
|
||||
scheduler thread start
|
||||
HTTP: creating work queue of depth 16
|
||||
No rpcpassword set - using random cookie authentication
|
||||
Generated RPC authentication cookie /tmp/bitcoin/.cookie
|
||||
Generated RPC authentication cookie /lotsofspace/.bitcoin/.cookie
|
||||
HTTP: starting 4 worker threads
|
||||
Bound to [::]:8333
|
||||
Bound to 0.0.0.0:8333
|
||||
init message: Verifying wallet(s)...
|
||||
Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
|
||||
Using wallet wallet.dat
|
||||
CDBEnv::Open: LogDir=/lotsofspace/.bitcoin/database ErrorFile=/lotsofspace/.bitcoin/db.log
|
||||
scheduler thread start
|
||||
Cache configuration:
|
||||
* Using 2.0MiB for block index database
|
||||
* Using 32.5MiB for chain state database
|
||||
* Using 65.5MiB for in-memory UTXO set
|
||||
* Using 250.0MiB for block index database
|
||||
* Using 8.0MiB for chain state database
|
||||
* Using 1742.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
|
||||
init message: Loading block index...
|
||||
Opening LevelDB in /tmp/bitcoin/blocks/index
|
||||
Opening LevelDB in /lotsofspace/.bitcoin/blocks/index
|
||||
Opened LevelDB successfully
|
||||
|
||||
[... more startup messages ...]
|
||||
@ -401,29 +385,29 @@ You can hit Ctrl-C to interrupt the process once you are satisfied that it is lo
|
||||
|
||||
To run Bitcoin Core in the background as a process, start it with the +daemon+ option, as +bitcoind -daemon+.
|
||||
|
||||
To monitor the progress and runtime status of your bitcoin node, use the command +bitcoin-cli getinfo+:
|
||||
To monitor the progress and runtime status of your bitcoin node, use the command +bitcoin-cli getblockchaininfo+:
|
||||
|
||||
----
|
||||
$ bitcoin-cli getinfo
|
||||
$ bitcoin-cli getblockchaininfo
|
||||
----
|
||||
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"version" : 110200,
|
||||
"protocolversion" : 70002,
|
||||
"blocks" : 396328,
|
||||
"timeoffset" : 0,
|
||||
"connections" : 15,
|
||||
"proxy" : "",
|
||||
"difficulty" : 120033340651.23696899,
|
||||
"testnet" : false,
|
||||
"relayfee" : 0.00010000,
|
||||
"errors" : ""
|
||||
"chain": "main",
|
||||
"blocks": 0,
|
||||
"headers": 83999,
|
||||
"bestblockhash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
||||
"difficulty": 1,
|
||||
"mediantime": 1231006505,
|
||||
"verificationprogress": 3.783041623201835e-09,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
|
||||
"pruned": false,
|
||||
[...]
|
||||
}
|
||||
----
|
||||
|
||||
This shows a node running Bitcoin Core version 0.11.2, with a blockchain height of 396328 blocks and 15 active network connections.
|
||||
This shows a node with a blockchain height of 0 blocks and 83999 headers. The node currently fetches the block headers of the best chain and afterward continues to download the full blocks.
|
||||
|
||||
Once you are happy with the configuration options you have selected, you should add bitcoin to the startup scripts in your operating system, so that it runs continuously and restarts when the operating system restarts. You will find a number of example startup scripts for various operating systems in bitcoin's source directory under _contrib/init_ and a _README.md_ file showing which system uses which script.((("", startref="BCnode03")))((("", startref="BNcore03")))
|
||||
|
||||
@ -453,12 +437,12 @@ Each of these commands may take a number of parameters. To get additional help,
|
||||
|
||||
----
|
||||
$ bitcoin-cli help getblockhash
|
||||
getblockhash index
|
||||
getblockhash height
|
||||
|
||||
Returns hash of block in best-block-chain at index provided.
|
||||
Returns hash of block in best-block-chain at height provided.
|
||||
|
||||
Arguments:
|
||||
1. index (numeric, required) The block index
|
||||
1. height (numeric, required) The height index
|
||||
|
||||
Result:
|
||||
"hash" (string) The block hash
|
||||
@ -481,35 +465,42 @@ In the next sections we will demonstrate some very useful RPC commands and their
|
||||
|
||||
==== Getting Information on the Bitcoin Core Client Status
|
||||
|
||||
((("Bitcoin Core", "Bitcoin Core API", "status information")))Command: +getinfo+
|
||||
((("Bitcoin Core", "Bitcoin Core API", "status information")))Bitcoin Core provides status reports on diffent modules through the JSON-RPC interface. The most important commands include +getblockchaininfo+, +getmempoolinfo+, +getnetworkinfo+ and +getwalletinfo+.
|
||||
|
||||
Bitcoin's +getinfo+ RPC command displays basic information about the status of the bitcoin network node, the wallet, and the blockchain database. Use +bitcoin-cli+ to run it:
|
||||
Bitcoin's +getblockchaininfo+ RPC command was introduced earlier. The +getnetworkinfo+ command displays basic information about the status of the bitcoin network node. Use +bitcoin-cli+ to run it:
|
||||
|
||||
----
|
||||
$ bitcoin-cli getinfo
|
||||
$ bitcoin-cli getnetworkinfo
|
||||
----
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"version" : 110200,
|
||||
"protocolversion" : 70002,
|
||||
"blocks" : 396367,
|
||||
"timeoffset" : 0,
|
||||
"connections" : 15,
|
||||
"proxy" : "",
|
||||
"difficulty" : 120033340651.23696899,
|
||||
"testnet" : false,
|
||||
"relayfee" : 0.00010000,
|
||||
"errors" : ""
|
||||
"version": 150000,
|
||||
"subversion": "/Satoshi:0.15.0/",
|
||||
"protocolversion": 70015,
|
||||
"localservices": "000000000000000d",
|
||||
"localrelay": true,
|
||||
"timeoffset": 0,
|
||||
"networkactive": true,
|
||||
"connections": 8,
|
||||
"networks": [
|
||||
...
|
||||
detailed information about all networks (ipv4, ipv6 or onion)
|
||||
...
|
||||
],
|
||||
"relayfee": 0.00001000,
|
||||
"incrementalfee": 0.00001000,
|
||||
"localaddresses": [
|
||||
],
|
||||
"warnings": ""
|
||||
}
|
||||
|
||||
----
|
||||
|
||||
The data is returned in JavaScript Object Notation (JSON), a format that can easily be "consumed" by all programming languages but is also quite human-readable. Among this data we see the version numbers for the bitcoin software client (110200) and bitcoin protocol (70002). We see the current block height, showing us how many blocks are known to this client (396367). We also see various statistics about the bitcoin network and the settings related to this client.
|
||||
The data is returned in JavaScript Object Notation (JSON), a format that can easily be "consumed" by all programming languages but is also quite human-readable. Among this data we see the version numbers for the bitcoin software client (150000) and bitcoin protocol (70015). We see the current number of connections (8) and various information about the bitcoin network and the settings related to this client.
|
||||
|
||||
[TIP]
|
||||
====
|
||||
It will take some time, perhaps more than a day, for the +bitcoind+ client to "catch up" to the current blockchain height as it downloads blocks from other bitcoin clients. You can check its progress using +getinfo+ to see the number of known blocks.
|
||||
It will take some time, perhaps more than a day, for the +bitcoind+ client to "catch up" to the current blockchain height as it downloads blocks from other bitcoin clients. You can check its progress using +getblockchaininfo+ to see the number of known blocks.
|
||||
====
|
||||
|
||||
[[exploring_and_decoding_transanctions]]
|
||||
@ -688,19 +679,21 @@ Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript Object No
|
||||
When we used the +bitcoin-cli+ command to get help on a command, it showed us an example of using +curl+, the versatile command-line HTTP client to construct one of these JSON-RPC calls:
|
||||
|
||||
----
|
||||
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getinfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
----
|
||||
|
||||
This command shows that +curl+ submits an HTTP request to the local host (127.0.0.1), connecting to the default bitcoin port (8332), and submitting a +jsonrpc+ request for the +getinfo+ method using +text/plain+ encoding.
|
||||
This command shows that +curl+ submits an HTTP request to the local host (127.0.0.1), connecting to the default bitcoin port (8332), and submitting a +jsonrpc+ request for the +getblockchaininfo+ method using +text/plain+ encoding.
|
||||
|
||||
You might notice that curl will ask for credentials to be sent along with the request. Bitcoin Core will create a random password on each start and place it in the data directory under the name +.cookie+. The +bitcoin-cli+ helper can read this password file given the data directory. Similarly, you can copy the password and pass it to curl (or any higher level Bitcoin Core RPC wrappers). Alternatively, you can create a static password with the helper script provided in _./share/rpcuser/rpcuser.py_ in Bitcoin Core's source directory.
|
||||
|
||||
If you're implementing a JSON-RPC call in your own program, you can use a generic HTTP library to construct the call, similar to what is shown in the preceding +curl+ example.
|
||||
|
||||
However, there are libraries in most every programming language that "wrap" the Bitcoin Core API in a way that makes this a lot simpler. We will use the +python-bitcoinlib+ library to simplify API access. Remember, this requires you to have a running Bitcoin Core instance, which will be used to make JSON-RPC calls.
|
||||
|
||||
The Python script in <<rpc_example>> makes a simple +getinfo+ call and prints the +block+ parameter from the data returned by Bitcoin Core.
|
||||
The Python script in <<rpc_example>> makes a simple +getblockchaininfo+ call and prints the +block+ parameter from the data returned by Bitcoin Core.
|
||||
|
||||
[[rpc_example]]
|
||||
.Running getinfo via Bitcoin Core's JSON-RPC API
|
||||
.Running getblockchaininfo via Bitcoin Core's JSON-RPC API
|
||||
====
|
||||
[source,python]
|
||||
----
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
|
||||
((("digital keys", see="keys and addresses")))((("keys and addresses", "overview of", id="KAover04")))((("digital signatures", "purpose of")))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 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 decentralized trust and control, ownership attestation, and the cryptographic-proof security model.
|
||||
|
||||
Most bitcoin transactions requires a valid digital signature to be included in the blockchain, which can only be generated with a secret key; therefore, anyone with a copy of that key has control of the bitcoin. ((("witnesses")))The digital signature used to spend funds is also referred to as a _witness_, a term used in cryptography. The witness data in a bitcoin transaction testifies to the true ownership of the funds being spent.
|
||||
Most bitcoin transactions require a valid digital signature to be included in the blockchain, which can only be generated with a secret key; therefore, anyone with a copy of that key has control of the bitcoin. ((("witnesses")))The digital signature used to spend funds is also referred to as a _witness_, a term used in cryptography. The witness data in a bitcoin transaction testifies to the true ownership of the funds being spent.
|
||||
|
||||
((("public and private keys", "key pairs")))((("public and private keys", see="also keys and addresses")))Keys come in pairs consisting of a private (secret) key and a public key. Think of the public key as similar to a bank account number and the private key as similar to the secret PIN, or signature on a check, 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.
|
||||
|
||||
@ -651,7 +651,7 @@ script hash = RIPEMD160(SHA256(script))
|
||||
The resulting "script hash" is encoded with Base58Check with a version prefix of 5, which results in an encoded address starting with a +3+. An example of a P2SH address is +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which can be derived using the Bitcoin Explorer commands +script-encode+, +sha256+, +ripemd160+, and +base58check-encode+ (see <<appdx_bx>>) as follows:
|
||||
|
||||
----
|
||||
$ echo dup hash160 [ 89abcdefabbaabbaabbaabbaabbaabbaabbaabba ] equalverify checksig > script
|
||||
$ echo dup hash160 [89abcdefabbaabbaabbaabbaabbaabbaabbaabba] equalverify checksig > script
|
||||
$ bx script-encode < script | bx sha256 | bx ripemd160 | bx base58check-encode --version 5
|
||||
3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM
|
||||
----
|
||||
|
||||
@ -586,7 +586,7 @@ The signature verification algorithm takes the message (a hash of the transactio
|
||||
|
||||
((("digital signatures", "signature hash types")))((("commitment")))Digital signatures are applied to messages, which in the case of bitcoin, are the transactions themselves. The signature implies a _commitment_ by the signer to specific transaction data. In the simplest form, the signature applies to the entire transaction, thereby committing all the inputs, outputs, and other transaction fields. However, a signature can commit to only a subset of the data in a transaction, which is useful for a number of scenarios as we will see in this section.
|
||||
|
||||
((("SIGHASH flags")))Bitcoin signatures have a way of indicating which part of a transaction's data is included in the hash signed by the private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte that is appended to the signature. Every signature has a +SIGHASH+ flag and the flag can be different from to input to input. A transaction with three signed inputs may have three signatures with different +SIGHASH+ flags, each signature signing (committing) different parts of the transaction.
|
||||
((("SIGHASH flags")))Bitcoin signatures have a way of indicating which part of a transaction's data is included in the hash signed by the private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte that is appended to the signature. Every signature has a +SIGHASH+ flag and the flag can be different from input to input. A transaction with three signed inputs may have three signatures with different +SIGHASH+ flags, each signature signing (committing) different parts of the transaction.
|
||||
|
||||
Remember, each input may contain a signature in its unlocking script. As a result, a transaction that contains several inputs may have signatures with different +SIGHASH+ flags that commit different parts of the transaction in each of the inputs. Note also that bitcoin transactions may contain inputs from different "owners," who may sign only one input in a partially constructed (and invalid) transaction, collaborating with others to gather all the necessary signatures to make a valid transaction. Many of the +SIGHASH+ flag types only make sense if you think of multiple participants collaborating outside the bitcoin network and updating a partially signed transaction.
|
||||
|
||||
|
||||
@ -321,9 +321,9 @@ BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to the cons
|
||||
|
||||
===== Original meaning of nSequence
|
||||
|
||||
The +nSequence+ field was originally intended (but never properly implemented) to allow modification of transactions in the mempool. In that use, a transaction containing inputs with +nSequence+ value below 2^32^ (0xFFFFFFFF) indicated a transaction that was not yet "finalized." Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher +nSequence+ value. Once a transaction was received whose inputs had an +nSequence+ value of 2^32^ it would be considered "finalized" and mined.
|
||||
The +nSequence+ field was originally intended (but never properly implemented) to allow modification of transactions in the mempool. In that use, a transaction containing inputs with +nSequence+ value below 2^32^ - 1 (0xFFFFFFFF) indicated a transaction that was not yet "finalized." Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher +nSequence+ value. Once a transaction was received whose inputs had an +nSequence+ value of 0xFFFFFFFF it would be considered "finalized" and mined.
|
||||
|
||||
The original meaning of +nSequence+ was never properly implemented and the value of +nSequence+ is customarily set to 2^32^ in transactions that do not utilize timelocks. For transactions with nLocktime or +CHECKLOCKTIMEVERIFY+, the +nSequence+ value must be set to less than 2^32^ for the timelock guards to have effect. Customarily, it is set to pass:[<span class="keep-together">2<sup>32</sup> – 1</span>] (0xFFFFFFFE).
|
||||
The original meaning of +nSequence+ was never properly implemented and the value of +nSequence+ is customarily set to 0xFFFFFFFF in transactions that do not utilize timelocks. For transactions with nLocktime or +CHECKLOCKTIMEVERIFY+, the +nSequence+ value must be set to less than 2^31^ for the timelock guards to have effect, as explained below.
|
||||
|
||||
===== nSequence as a consensus-enforced relative timelock
|
||||
|
||||
|
||||
@ -301,29 +301,6 @@ bitcoind: Using data directory /home/username/.bitcoin/testnet3
|
||||
|
||||
To connect to bitcoind, you use the +bitcoin-cli+ command-line tool, but you must also switch it to testnet mode:
|
||||
|
||||
----
|
||||
$ bitcoin-cli -testnet getinfo
|
||||
{
|
||||
"version": 130200,
|
||||
"protocolversion": 70015,
|
||||
"walletversion": 130000,
|
||||
"balance": 0.00000000,
|
||||
"blocks": 416,
|
||||
"timeoffset": 0,
|
||||
"connections": 3,
|
||||
"proxy": "",
|
||||
"difficulty": 1,
|
||||
"testnet": true,
|
||||
"keypoololdest": 1484801486,
|
||||
"keypoolsize": 100,
|
||||
"paytxfee": 0.00000000,
|
||||
"relayfee": 0.00001000,
|
||||
"errors": ""
|
||||
}
|
||||
----
|
||||
|
||||
You can also use the +getblockchaininfo+ command to confirm the details of the testnet3 blockchain and your sync progress:
|
||||
|
||||
----
|
||||
$ bitcoin-cli -testnet getblockchaininfo
|
||||
{
|
||||
|
||||
@ -17,15 +17,15 @@ while (line[0] != "|"):
|
||||
line = f.readline()
|
||||
|
||||
while (line[1] == '-'):
|
||||
line_num = f.readline()
|
||||
line_layer = f.readline()[2:-1]
|
||||
line_title = f.readline()[2:-1]
|
||||
line_owner = f.readline()[2:-1]
|
||||
line_type = f.readline()[2:-1]
|
||||
line_num = f.readline()
|
||||
line_layer = f.readline()[2:-1]
|
||||
line_title = f.readline()[2:-1]
|
||||
line_owner = f.readline()[2:-1]
|
||||
line_type = f.readline()[2:-1]
|
||||
line_status = f.readline()[2:-1]
|
||||
line = f.readline()
|
||||
line = f.readline()
|
||||
while (line[0] != "|"):
|
||||
line = f.readline()
|
||||
line = f.readline()
|
||||
|
||||
num = regex_num.match(line_num)
|
||||
alt_num = regex_altnum.match(line_num)
|
||||
@ -34,6 +34,10 @@ while (line[1] == '-'):
|
||||
elif alt_num:
|
||||
bip_num = alt_num.group(1)
|
||||
|
||||
print "|[[bip-{0}]]https://github.com/bitcoin/bips/blob/master/bip-{0:04d}.mediawiki[BIP-{0}] |{1} |{2} |{3} |{4} ".format(int(bip_num), line_title, line_owner, line_type, line_status)
|
||||
|
||||
print("|[[bip-{0}]]https://github.com/bitcoin/bips/blob/master/bip-{0:04d}"
|
||||
".mediawiki[BIP-{0}] |{1} |{2} |{3} |{4} ".format(int(bip_num),
|
||||
line_title,
|
||||
line_owner,
|
||||
line_type,
|
||||
line_status))
|
||||
f.close()
|
||||
|
||||
@ -1,56 +1,56 @@
|
||||
import ecdsa
|
||||
import os
|
||||
from ecdsa.util import string_to_number, number_to_string
|
||||
|
||||
# secp256k1, http://www.oid-info.com/get/1.3.132.0.10
|
||||
_p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2FL
|
||||
_r = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141L
|
||||
_b = 0x0000000000000000000000000000000000000000000000000000000000000007L
|
||||
_a = 0x0000000000000000000000000000000000000000000000000000000000000000L
|
||||
_Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798L
|
||||
_Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8L
|
||||
_p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
|
||||
_r = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
|
||||
_b = 0x0000000000000000000000000000000000000000000000000000000000000007
|
||||
_a = 0x0000000000000000000000000000000000000000000000000000000000000000
|
||||
_Gx = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
|
||||
_Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
|
||||
curve_secp256k1 = ecdsa.ellipticcurve.CurveFp(_p, _a, _b)
|
||||
generator_secp256k1 = ecdsa.ellipticcurve.Point(curve_secp256k1, _Gx, _Gy, _r)
|
||||
oid_secp256k1 = (1, 3, 132, 0, 10)
|
||||
SECP256k1 = ecdsa.curves.Curve("SECP256k1", curve_secp256k1, generator_secp256k1, oid_secp256k1)
|
||||
SECP256k1 = ecdsa.curves.Curve("SECP256k1", curve_secp256k1,
|
||||
generator_secp256k1, oid_secp256k1)
|
||||
ec_order = _r
|
||||
|
||||
curve = curve_secp256k1
|
||||
generator = generator_secp256k1
|
||||
|
||||
|
||||
def random_secret():
|
||||
convert_to_int = lambda array: int("".join(array).encode("hex"), 16)
|
||||
|
||||
# Collect 256 bits of random data from the OS's cryptographically secure random generator
|
||||
|
||||
# Collect 256 bits of random data from the OS's cryptographically secure
|
||||
# random generator
|
||||
byte_array = os.urandom(32)
|
||||
|
||||
|
||||
return convert_to_int(byte_array)
|
||||
|
||||
|
||||
def get_point_pubkey(point):
|
||||
if point.y() & 1:
|
||||
key = '03' + '%064x' % point.x()
|
||||
else:
|
||||
key = '02' + '%064x' % point.x()
|
||||
key = ('03' if point.y() & 1 else '02') + '%064x' % point.x()
|
||||
return key.decode('hex')
|
||||
|
||||
|
||||
def get_point_pubkey_uncompressed(point):
|
||||
key = '04' + \
|
||||
'%064x' % point.x() + \
|
||||
'%064x' % point.y()
|
||||
key = ('04' +
|
||||
'%064x' % point.x() +
|
||||
'%064x' % point.y())
|
||||
return key.decode('hex')
|
||||
|
||||
|
||||
# Generate a new private key.
|
||||
secret = random_secret()
|
||||
print "Secret: ", secret
|
||||
print("Secret: ", secret)
|
||||
|
||||
# Get the public key point.
|
||||
point = secret * generator
|
||||
print "EC point:", point
|
||||
print("EC point:", point)
|
||||
|
||||
print "BTC public key:", get_point_pubkey(point).encode("hex")
|
||||
print("BTC public key:", get_point_pubkey(point).encode("hex"))
|
||||
|
||||
# Given the point (x, y) we can create the object using:
|
||||
point1 = ecdsa.ellipticcurve.Point(curve, point.x(), point.y(), ec_order)
|
||||
assert point1 == point
|
||||
|
||||
assert(point1 == point)
|
||||
|
||||
@ -25,4 +25,7 @@ resp = requests.get('https://blockchain.info/unspent?active=%s' % address)
|
||||
utxo_set = json.loads(resp.text)["unspent_outputs"]
|
||||
|
||||
for utxo in utxo_set:
|
||||
print "%s:%d - %ld Satoshis" % (utxo['tx_hash'], utxo['tx_output_n'], utxo['value'])
|
||||
print("%s:%d - %ld Satoshis" % (utxo['tx_hash'], utxo['tx_output_n'],
|
||||
utxo['value']))
|
||||
# Or try...
|
||||
# print("{tx_hash}:{tx_output_n} - {value} Satoshis".format(**utxo))
|
||||
|
||||
@ -1,18 +1,18 @@
|
||||
|
||||
# example of iterating a nonce in a hashing algorithm's input
|
||||
|
||||
from __future__ import print_function
|
||||
import hashlib
|
||||
|
||||
|
||||
text = "I am Satoshi Nakamoto"
|
||||
|
||||
# iterate nonce from 0 to 19
|
||||
for nonce in xrange(20):
|
||||
|
||||
for nonce in range(20):
|
||||
|
||||
# add the nonce to the end of the text
|
||||
input = text + str(nonce)
|
||||
|
||||
input = text + str(nonce)
|
||||
|
||||
# calculate the SHA-256 hash of the input (text+nonce)
|
||||
hash = hashlib.sha256(input).hexdigest()
|
||||
|
||||
hash = hashlib.sha256(input).hexdigest()
|
||||
|
||||
# show the input and hash result
|
||||
print input, '=>', hash
|
||||
print(input, '=>', hash)
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
from __future__ import print_function
|
||||
import bitcoin
|
||||
|
||||
# Generate a random private key
|
||||
@ -5,45 +6,41 @@ valid_private_key = False
|
||||
while not valid_private_key:
|
||||
private_key = bitcoin.random_key()
|
||||
decoded_private_key = bitcoin.decode_privkey(private_key, 'hex')
|
||||
valid_private_key = 0 < decoded_private_key < bitcoin.N
|
||||
valid_private_key = 0 < decoded_private_key < bitcoin.N
|
||||
|
||||
print "Private Key (hex) is: ", private_key
|
||||
print "Private Key (decimal) is: ", decoded_private_key
|
||||
print("Private Key (hex) is: ", private_key)
|
||||
print("Private Key (decimal) is: ", decoded_private_key)
|
||||
|
||||
# Convert private key to WIF format
|
||||
wif_encoded_private_key = bitcoin.encode_privkey(decoded_private_key, 'wif')
|
||||
print "Private Key (WIF) is: ", wif_encoded_private_key
|
||||
print("Private Key (WIF) is: ", wif_encoded_private_key)
|
||||
|
||||
# Add suffix "01" to indicate a compressed private key
|
||||
compressed_private_key = private_key + '01'
|
||||
print "Private Key Compressed (hex) is: ", compressed_private_key
|
||||
print("Private Key Compressed (hex) is: ", compressed_private_key)
|
||||
|
||||
# Generate a WIF format from the compressed private key (WIF-compressed)
|
||||
wif_compressed_private_key = bitcoin.encode_privkey(
|
||||
bitcoin.decode_privkey(compressed_private_key, 'hex'), 'wif')
|
||||
print "Private Key (WIF-Compressed) is: ", wif_compressed_private_key
|
||||
print("Private Key (WIF-Compressed) is: ", wif_compressed_private_key)
|
||||
|
||||
# Multiply the EC generator point G with the private key to get a public key point
|
||||
public_key = bitcoin.fast_multiply(bitcoin.G, decoded_private_key)
|
||||
print "Public Key (x,y) coordinates is:", public_key
|
||||
print("Public Key (x,y) coordinates is:", public_key)
|
||||
|
||||
# Encode as hex, prefix 04
|
||||
hex_encoded_public_key = bitcoin.encode_pubkey(public_key,'hex')
|
||||
print "Public Key (hex) is:", hex_encoded_public_key
|
||||
hex_encoded_public_key = bitcoin.encode_pubkey(public_key, 'hex')
|
||||
print("Public Key (hex) is:", hex_encoded_public_key)
|
||||
|
||||
# Compress public key, adjust prefix depending on whether y is even or odd
|
||||
(public_key_x, public_key_y) = public_key
|
||||
if (public_key_y % 2) == 0:
|
||||
compressed_prefix = '02'
|
||||
else:
|
||||
compressed_prefix = '03'
|
||||
compressed_prefix = '02' if (public_key_y % 2) == 0 else '03'
|
||||
hex_compressed_public_key = compressed_prefix + bitcoin.encode(public_key_x, 16)
|
||||
print "Compressed Public Key (hex) is:", hex_compressed_public_key
|
||||
print("Compressed Public Key (hex) is:", hex_compressed_public_key)
|
||||
|
||||
# Generate bitcoin address from public key
|
||||
print "Bitcoin Address (b58check) is:", bitcoin.pubkey_to_address(public_key)
|
||||
print("Bitcoin Address (b58check) is:", bitcoin.pubkey_to_address(public_key))
|
||||
|
||||
# Generate compressed bitcoin address from compressed public key
|
||||
print "Compressed Bitcoin Address (b58check) is:", \
|
||||
bitcoin.pubkey_to_address(hex_compressed_public_key)
|
||||
|
||||
print("Compressed Bitcoin Address (b58check) is:",
|
||||
bitcoin.pubkey_to_address(hex_compressed_public_key))
|
||||
|
||||
@ -3,6 +3,7 @@ start_block_reward = 50
|
||||
# 210000 is around every 4 years with a 10 minute block interval
|
||||
reward_interval = 210000
|
||||
|
||||
|
||||
def max_money():
|
||||
# 50 BTC = 50 0000 0000 Satoshis
|
||||
current_reward = 50 * 10**8
|
||||
@ -12,5 +13,5 @@ def max_money():
|
||||
current_reward /= 2
|
||||
return total
|
||||
|
||||
print "Total BTC to ever be created:", max_money(), "Satoshis"
|
||||
|
||||
print("Total BTC to ever be created:", max_money(), "Satoshis")
|
||||
|
||||
@ -4,60 +4,61 @@
|
||||
import hashlib
|
||||
import time
|
||||
|
||||
max_nonce = 2 ** 32 # 4 billion
|
||||
try:
|
||||
long # Python 2
|
||||
xrange
|
||||
except NameError:
|
||||
long = int # Python 3
|
||||
xrange = range
|
||||
|
||||
max_nonce = 2 ** 32 # 4 billion
|
||||
|
||||
|
||||
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):
|
||||
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:
|
||||
print "Success with nonce %d" % nonce
|
||||
print "Hash is %s" % hash_result
|
||||
return (hash_result,nonce)
|
||||
|
||||
print "Failed after %d (max_nonce) tries" % nonce
|
||||
print("Success with nonce %d" % nonce)
|
||||
print("Hash is %s" % hash_result)
|
||||
return (hash_result, nonce)
|
||||
|
||||
print("Failed after %d (max_nonce) tries" % nonce)
|
||||
return nonce
|
||||
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
|
||||
nonce = 0
|
||||
hash_result = ''
|
||||
|
||||
# difficulty from 0 to 31 bits
|
||||
|
||||
# difficulty from 0 to 31 bits
|
||||
for difficulty_bits in xrange(32):
|
||||
|
||||
difficulty = 2 ** difficulty_bits
|
||||
print "Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits)
|
||||
|
||||
print "Starting search..."
|
||||
|
||||
print("Difficulty: %ld (%d bits)" % (difficulty, difficulty_bits))
|
||||
print("Starting search...")
|
||||
|
||||
# checkpoint the current time
|
||||
start_time = time.time()
|
||||
|
||||
|
||||
# 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
|
||||
|
||||
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)
|
||||
|
||||
(hash_result, nonce) = proof_of_work(new_block, difficulty_bits)
|
||||
|
||||
# checkpoint how long it took to find a result
|
||||
end_time = time.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:
|
||||
|
||||
|
||||
# estimate the hashes per second
|
||||
hash_power = float(long(nonce)/elapsed_time)
|
||||
print "Hashing Power: %ld hashes per second" % hash_power
|
||||
|
||||
|
||||
|
||||
hash_power = float(long(nonce) / elapsed_time)
|
||||
print("Hashing Power: %ld hashes per second" % hash_power)
|
||||
|
||||
@ -1,5 +1,7 @@
|
||||
#!/usr/bin/env python
|
||||
|
||||
from __future__ import print_function
|
||||
|
||||
from pycoin.key import Key
|
||||
|
||||
from pycoin.key.validate import is_address_valid, is_wif_valid
|
||||
|
||||
@ -3,8 +3,8 @@ from bitcoin.rpc import RawProxy
|
||||
# Create a connection to local Bitcoin Core node
|
||||
p = RawProxy()
|
||||
|
||||
# Run the getinfo command, store the resulting data in info
|
||||
info = p.getinfo()
|
||||
# Run the getblockchaininfo command, store the resulting data in info
|
||||
info = p.getblockchaininfo()
|
||||
|
||||
# Retrieve the 'blocks' element from the info
|
||||
print(info['blocks'])
|
||||
|
||||
@ -2,8 +2,13 @@
|
||||
|
||||
from sys import argv
|
||||
|
||||
class OutputInfo:
|
||||
try:
|
||||
long # Python 2
|
||||
except NameError:
|
||||
long = int # Python 3
|
||||
|
||||
|
||||
class OutputInfo:
|
||||
def __init__(self, tx_hash, tx_index, value):
|
||||
self.tx_hash = tx_hash
|
||||
self.tx_index = tx_index
|
||||
@ -13,6 +18,7 @@ class OutputInfo:
|
||||
return "<%s:%s with %s Satoshis>" % (self.tx_hash, self.tx_index,
|
||||
self.value)
|
||||
|
||||
|
||||
# Select optimal outputs for a send from unspent outputs list.
|
||||
# Returns output list and remaining change to be sent to
|
||||
# a change address.
|
||||
@ -44,6 +50,7 @@ def select_outputs_greedy(unspent, min_value):
|
||||
# No results found.
|
||||
return None, 0
|
||||
|
||||
|
||||
def main():
|
||||
unspent = [
|
||||
OutputInfo("ebadfaa92f1fd29e2fe296eda702c48bd11ffd52313e986e99ddad9084062167", 1, 8000000),
|
||||
@ -54,15 +61,11 @@ def main():
|
||||
OutputInfo("12b6a7934c1df821945ee9ee3b3326d07ca7a65fd6416ea44ce8c3db0c078c64", 0, 10000000),
|
||||
OutputInfo("7f42eda67921ee92eae5f79bd37c68c9cb859b899ce70dba68c48338857b7818", 0, 16100000),
|
||||
]
|
||||
|
||||
if len(argv) > 1:
|
||||
target = long(argv[1])
|
||||
else:
|
||||
target = 55000000
|
||||
|
||||
print "For transaction amount %d Satoshis (%f bitcoin) use: " % (target, target/10.0**8)
|
||||
print select_outputs_greedy(unspent, target)
|
||||
target = long(argv[1]) if len(argv) > 1 else 55000000
|
||||
print("For transaction amount %d Satoshis (%f bitcoin) use: " %
|
||||
(target, target / 10.0 ** 8))
|
||||
print(select_outputs_greedy(unspent, target))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
|
||||
|
||||
@ -144,10 +144,10 @@ OP_RETURN::
|
||||
An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
|
||||
|
||||
OP_RETURN transaction::
|
||||
A transaction type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Not to be confused with OP_RETURN opcode.
|
||||
A transaction type that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Not to be confused with OP_RETURN opcode.
|
||||
|
||||
orphan block::
|
||||
Blocks whose parent block has not been processed by the local node, so they can’t be fully validated yet.
|
||||
Orphan Block::
|
||||
Blocks whose parent block has not been processed by the local node, so they can’t be fully validated yet. Not to be confused with stale block.
|
||||
|
||||
orphan transactions::
|
||||
Transactions that can't go into the pool due to one or more missing input transactions.
|
||||
@ -226,8 +226,11 @@ soft fork::
|
||||
soft fork or Soft-Forking Change is a temporary fork in the blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about.
|
||||
Not to be confused with fork, hard fork, software fork or Git fork.
|
||||
|
||||
stale block::
|
||||
Block which were successfully mined but which isn’t included on the current best block chain, likely because some other block at the same height had its chain extended first.
|
||||
SPV (aka Simplified Payment Verification)::
|
||||
SPV or Simplified Payment Verification is a method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
|
||||
|
||||
Stale Block::
|
||||
Block which were successfully mined but which isn’t included on the current best block chain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block.
|
||||
|
||||
timelocks::
|
||||
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.
|
||||
@ -239,7 +242,7 @@ transaction pool::
|
||||
An unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions.
|
||||
|
||||
Turing completeness::
|
||||
A program language is called "Turing complete," if that it can run any program that a Turing machine can run given enough time and memory.
|
||||
A program language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory.
|
||||
|
||||
unspent transaction output (UTXO)::
|
||||
UTXO is an unspent transaction output that can be spent as an input in a new transaction.
|
||||
|
||||
0
images/mbc2_0204.png
Executable file → Normal file
0
images/mbc2_0204.png
Executable file → Normal file
|
Before Width: | Height: | Size: 131 KiB After Width: | Height: | Size: 131 KiB |
@ -51,7 +51,7 @@ This icon indicates a warning or caution.
|
||||
|
||||
=== Code Examples
|
||||
|
||||
((("code examples, obtaining and using", id="codeuse00")))The examples are illustrated in Python, C++, and using the command line of a Unix-like operating system such as Linux or macOS. All code snippets are available in the Github repository (https://github.com/bitcoinbook/bitcoinbook[https://github.com/bitcoinbook/bitcoinbook]) in the _code_ subdirectory of the main repo. Fork the book code, try the code examples, or submit corrections via GitHub.
|
||||
((("code examples, obtaining and using", id="codeuse00")))The examples are illustrated in Python, C++, and using the command line of a Unix-like operating system such as Linux or macOS. All code snippets are available in the GitHub repository (https://github.com/bitcoinbook/bitcoinbook[https://github.com/bitcoinbook/bitcoinbook]) in the _code_ subdirectory of the main repo. Fork the book code, try the code examples, or submit corrections via GitHub.
|
||||
|
||||
All the code snippets can be replicated on most operating systems with a minimal installation of compilers and interpreters for the corresponding languages. Where necessary, we provide basic installation instructions and step-by-step examples of the output of those instructions.
|
||||
|
||||
@ -169,16 +169,19 @@ Many contributors offered comments, corrections, and additions to the early-rele
|
||||
|
||||
Following is a list of notable GitHub contributors, including their GitHub ID in parentheses:
|
||||
|
||||
* Akira Chiku (achiku)
|
||||
* Alex Waters (alexwaters)
|
||||
* Andrew Donald Kennedy (grkvlt)
|
||||
* bitcoinctf
|
||||
* Bryan Gmyrek (physicsdude)
|
||||
* Casey Flynn (cflynn07)
|
||||
* cclauss
|
||||
* Chapman Shoop (belovachap)
|
||||
* Christie D'Anna (avocadobreath)
|
||||
* Cody Scott (Siecje)
|
||||
* coinradar
|
||||
* Cragin Godley (cgodley)
|
||||
* Craig Dodd (cdodd)
|
||||
* dallyshalla
|
||||
* Diego Viola (diegoviola)
|
||||
* Dirk Jäckel (biafra23)
|
||||
@ -216,7 +219,9 @@ Following is a list of notable GitHub contributors, including their GitHub ID in
|
||||
* Jorgeminator
|
||||
* Kai Bakker (kaibakker)
|
||||
* Mai-Hsuan Chia (mhchia)
|
||||
* marcofalke
|
||||
* Marzig (marzig76)
|
||||
* Matt McGivney (mattmcgiv)
|
||||
* Maximilian Reichel (phramz)
|
||||
* Michalis Kargakis (kargakis)
|
||||
* Michael C. Ippolito (michaelcippolito)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user