In this book, the word "bitcoin" is generally written in lowercase. This differs from the usage specified on bitcoin.org and the Bitcoin Wiki, both of which recommend capitalizing the word when referring to the protocol or network and writing it lowercase in reference to the unit of currency. Vice's Motherboard blog also has a post explaining that this usage aids readability.

Is there a rationale for always writing "bitcoin" lowercase? If computer languages (Python, JavaScript) and protocols (Ethernet, File Transfer Protocol) are generally capitalized, why not write "Bitcoin" when referring to the protocol?

Corrections:

1. Confirmations (Blocks deep) should be Confirmations (Block depth) see https://en.bitcoin.it/wiki/Confirmation
2. Blocks (Blockchain) should be Blocks (Block height) see https://www.investopedia.com/terms/b/block-height.asp
3. Block 277315 should be deleted and instead of it there should be "Mempool Alice's transaction" as it wrong that this block has the transaction with 0 confirmations - it is the mempool.
4. The arrows connecting the blocks should go upwards not downwards as the block count goes up.

Cc: @montvid @rating89us

Hi Mr. Will Binns, thanks for you spending time on this book. I really appreciate it.

However, let's keep honest and rename the new version of this book to 'Bitcoin Core Book'.

Since you are one important person who is helping the Bitcoin Core chain to fight against the real Bitcoin chain. So it's immoral to intentionally cause confusion among newbies by pretending that you are still working for Bitcoin.

You can do anything on your Bitcoin Core chain, Knots or not, censorship or not. We Bitcoiners don't care. But at least please don't maliciously mislead newbies out of evil will.

I really appreciate it if you can be honest on this issue in the future. You will still be a good person, who works for the enemy of Bitcoin.

The third print of the second edition seems to have already been released (at least, that's what what I'm reading says: "2018-03-23: Third Release").

1. This isn't mentioned in the releases, I guess the tag and release description should be updated?
2. README.md still incorrectly mentions the second print as the last one.
3. The link to Amazon says it links to the second print, I guess whoever orders the book will get the third print. I think it makes sense to just drop the "Second Print" in the preface to the Amazon link.

I am having issues trying to run the addr.cpp program

I enter the command g++ -std=c++11 -o addr addr.cpp $(pkg-config --cflags --libs libbitcoin) and then get these errors

addr.cpp:11:9: error: no type named 'ec_point' in namespace 'libbitcoin'
    bc::ec_point public_key = bc::secret_to_public_key(secret);
    ~~~~^
addr.cpp:11:35: error: no member named 'secret_to_public_key' in namespace 'libbitcoin'
    bc::ec_point public_key = bc::secret_to_public_key(secret);
                              ~~~~^
addr.cpp:12:40: error: no member named 'encode_hex' in namespace 'libbitcoin'; did you
      mean 'encode_hash'?
    std::cout << "Public key: " << bc::encode_hex(public_key) << std::endl;
                                   ~~~~^~~~~~~~~~
                                       encode_hash
/usr/local/include/bitcoin/bitcoin/formats/base_16.hpp:65:20: note: 'encode_hash'
      declared here
BC_API std::string encode_hash(hash_digest hash);
                   ^
3 errors generated.

Can someone please help me?

Looks like Vitalik said bye bye to the code he wrote for bitcoin last year on Dec 15th. The referance of pybitcointools is no more valid.

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc#implementing-keys-and-addresses-in-python

I can't seem to find the tx in 2bbac8bb3a57a2363407ac8c16a67015ed2e88a4388af58cf90299e0744d3de4 in Block Explorer for the tx of 0.01 to Gopesh - can you? Why mix real and imaginary tx? Bob DID NOT PAY Gopesh - it is a lie! Bob did not pay to ANYONE! See: https://blockchain.info/address/1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA Or here - no inputs to Gopesh or anyone: https://blockchair.com/bitcoin/outputs?q=recipient(1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA)

Could someone add links instead of pictures of tx id's as I had to type the tx id myself to check...

The text in ch03 and ch04 introduces pybitcointools. But, sadly that support has ended. 😢

Example 4-5 and 4-6 uses pybitcointools, so, we may have to change or remove these examples.

It recently became clear to me that the holistic product/service/project “Bitcoin” is represented differently, in written communication online, in contrast to (actual rights to) a single “bitcoin” (or part there of). The difference is the capitalisation of b.

I apologize if this is the wrong place to post my troubles. I've installed libbitcoin am now getting errors I cannot solve during compilation of addr.cpp adn other cpp files. There are a bunch of depreciation warnings which are followed by the error. Here's one warning with the errors I'm getting:

In file included from /usr/include/boost/iostreams/detail/is_dereferenceable.hpp:13:0,
                 from /usr/include/boost/iostreams/detail/resolve.hpp:26,
                 from /usr/include/boost/iostreams/detail/push.hpp:24,
                 from /usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
                 from /usr/include/boost/iostreams/stream_buffer.hpp:22,
                 from /usr/include/boost/iostreams/stream.hpp:21,
                 from /usr/local/include/bitcoin/bitcoin/utility/container_sink.hpp:24,
                 from /usr/local/include/bitcoin/bitcoin/message/messages.hpp:57,
                 from /usr/local/include/bitcoin/bitcoin.hpp:114,
                 from addr.cpp:1:
/usr/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated
 # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
                                                                                    ^
addr.cpp: In function ‘int main()’:
addr.cpp:12:5: error: ‘ec_point’ is not a member of ‘bc’
     bc::ec_point public_key = bc::secret_to_public_key(secret);
     ^~
addr.cpp:13:36: error: ‘encode_hex’ is not a member of ‘bc’
     std::cout << "Public key: " << bc::encode_hex(public_key) << std::endl;
                                    ^~
addr.cpp:13:51: error: ‘public_key’ was not declared in this scope
     std::cout << "Public key: " << bc::encode_hex(public_key) << std::endl;
                                                   ^~~~~~~~~~

From the warning message, it looks like the compiler can see bitcoin.hpp file, but for some reason the namespace 'bc' doesn't have the methods ec_point etc? I'm not a pro in c++ so this is probably user error rather than a bug.

Using Ubuntu 16.10 with g++ compiler version 6.2.0

UTXOs aren't tied to addresses, but only to the script the address translates to (which may or may not be related to the user the address represents).

Given TransactionID of the example is not availble at blockchain.com: https://blockexplorer.com/txs/0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2

key-to-address-ecc-example.py (example 4-5) appears to use the incorrect representation of private key on line 45. It uses decoded_private_key (the decimal representation of primary key) rather than private_key (the hexadecimal representation).

This is inconsistent with the calculation of wif_compressed_private_key, which uses private_key + '01' rather than decoded_private_key + '01'.

Also, if I override the random private_key with the private key used in Table 4-4 (i.e., private_key = "1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD"), I get an inconsistent result for the wif encoding.

Per Table 4-4, the WIF value should be

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn.

Instead, I receive a value of

5JJrpphRQLdPJU1aNK3N43S5DjGbj8y9cQac2dxyGodtnk1SkfS.

By changing the code on line 45 to wif_encoded_private_key = cryptos.encode_privkey(private_key, 'wif'), I receive a wif value of 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn that is consistent with the example in table 4-4.

The values for WIF-Compressed are consistent between Example 4-5, as-is, and Table 4-4.

Finally, the source code for cryptos.encode_privkey seems to indicate the input should be in decimal - see line 223.

Am I missing something? I wondered if the wif format works equally well for hexadecimal and decimal private keys, and tried this:

$ bx wif-to-ec 5JJrpphRQLdPJU1aNK3N43S5DjGbj8y9cQac2dxyGodtnk1SkfS                                                                      
40e0fe11b6a62375e206e33810a16cd942c5a94068b55eb3ceaf75a9642c4d11

The result matched neither the decimal nor hexadecimal representation of private key.

Currently the book says: .... "mining," which involves competing to find solutions to a mathematical problem while processing Bitcoin transactions. This could make the wrong impression that mining solves some general usage mathematical prblems or mathematical problems that has some utility other than hashing blocks and proof of work. I think it is important not to confuse the reader at the beginning, since the beginnng of the book is often used by journalists and (sloppy) researchers has inluence on wide public. I would recommend to change it to something like: .... "mining", which involves processing Bitcoin transactions, organising the into "blocks" and competing to solve a mathematical problem of encoding those blocks in certain way that will be explained further later in this book.

p.s. (Also the comma should be after the closing paranthesis)

The coinprism.info example in chapter 12 needs to either be updated or removed given that coinprism.info is no longer online (currently points to a domain for sale page) and cpr.sm is not resolvable.

Figure 10-3 and 10-4 are mislabeled - There are "Node X" and "Node Y" in the images but the text talks about "Node A and Node B", but then reading the description, "Node A" = "Node X", and "Node Y" is not "Node B", and that "Node B" is not labeled at all.