From b16467a4f2185c7b4ad946bd2d1ba86cba83a751 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:24:47 -0700 Subject: [PATCH 01/11] Edited preface.asciidoc with Atlas code editor --- preface.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/preface.asciidoc b/preface.asciidoc index b4c91835..11370838 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -63,7 +63,7 @@ All the code snippets use real values and calculations where possible, so that y 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. -((("attribution")))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 2018 Andreas M. Antonopoulos, 978-1-491-95438-6.” +((("attribution")))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 2017 Andreas M. Antonopoulos, 978-1-491-95438-6.” ((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply. From 9cd4be7e552c2e5be6e6e581146d571325966e02 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:25:34 -0700 Subject: [PATCH 02/11] Edited glossary.asciidoc with Atlas code editor --- glossary.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/glossary.asciidoc b/glossary.asciidoc index 8a9dbaee..e5add549 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -146,7 +146,7 @@ OP_RETURN:: OP_RETURN transaction:: 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:: +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:: @@ -226,8 +226,8 @@ 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 was 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. +stale block:: + Block that was successfully mined but that 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. From a68ca9165fe72462334686c355a63b0816e43a70 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:42:38 -0700 Subject: [PATCH 03/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 48 +++++++++++++++++++++++------------------------- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 34b54b0e..4e9ebe3d 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -605,40 +605,38 @@ As you can see, there are a lot of zeros at the beginning of that target, meanin The formula to calculate the difficulty target from this representation is: - -target = coefficient * 2^(8*(exponent–3))^ - +++++ +
    +
  • target = coefficient * 2(8*(exponent–3))
    • +
+++++ Using that formula, and the difficulty bits value 0x1903a30c, we get: - - -target = 0x03a30c * 2^0x08*(0x19-0x03)^ - - -=> target = 0x03a30c * 2^(0x08*0x16)^ - - -=> target = 0x03a30c * 2^0xB0^ - +++++ +
    +
  • target = 0x03a30c * 20x08*(0x19-0x03)
    • +
  • => target = 0x03a30c * 2(0x08*0x16)
    • +
  • => target = 0x03a30c * 20xB0
    • +
+++++ which in decimal is: - - -=> target = 238,348 * 2^176^ - - -=> target = 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328 - +++++ +
    +
  • => target = 238,348 * 2176
    • +
  • => target = 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
    • +
+++++ switching back to hexadecimal: - - -=> target = 0x0000000000000003A30C00000000000000000000000000000000000000000000 - - +++++ +
    +
  • => target = 0x0000000000000003A30C00000000000000000000000000000000000000000000
    • +
+++++ 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 must have more than 60 leading bits set to zero. With this level of difficulty, a single miner processing 1 trillion hashes per second (1 terahash per second or 1 TH/sec) would only find a solution once every 8,496 blocks or once every 59 days, on average. From 9fc3bc24244b5c280ecc65eaf8ca61593b3c87f6 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:45:57 -0700 Subject: [PATCH 04/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 4e9ebe3d..7a31359e 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -867,10 +867,13 @@ In the last two years, the ASIC mining chips have become increasingly denser, ap ((("mining pools", id="MACoverpool10")))((("mining pools", "benefits of")))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 hydroelectric powerstations. 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. -Let's look at a specific example. Assume a miner has purchased mining hardware with a combined hashing rate of 14,000 gigahashes per second (GH/s), or 14 TH/s. In 2017 this equipment costs approximately $2,500 USD. The hardware consumes 1375 watts (1.3 kW) of electricity when running, 33 kW-hours a day, at a cost of $1 to $2 per day at very low electricity rates. At current bitcoin difficulty, the miner will be able to solo mine a block approximately once every 4 years. How do we work out that probability? It is based on a network-wide hashing rate of 3 EH/sec (in 2017), and the miners rate of 14 TH/sec: +Let's look at a specific example. Assume a miner has purchased mining hardware with a combined hashing rate of 14,000 gigahashes per second (GH/s), or 14 TH/s. In 2017 this equipment costs approximately $2,500 USD. The hardware consumes 1375 watts (1.3 kW) of electricity when running, 33 kW-hours a day, at a cost of $1 to $2 per day at very low electricity rates. At current bitcoin difficulty, the miner will be able to solo mine a block approximately once every 4 years. How do we work out that probability? It is based on a network-wide hashing rate of 3 EH/sec (in 2017), and the miner's rate of 14 TH/sec: - -P = (14 * 10^12^ / 3 * 10^18^) * 210240 = 0.98 +++++ +
    +
  • P = (14 * 1012 / 3 * 1018) * 210240 = 0.98
    • +
+++++ ...where 21240 is the number of blocks in four years. The miner has a 98% probability of finding a block over four years, based on the global hash rate at the beginning of the period. From 0e9a423f41fc943abffffdf3897583211c32bb05 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:51:34 -0700 Subject: [PATCH 05/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 7a31359e..894f16f8 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -626,7 +626,7 @@ which in decimal is: ++++
  • => target = 238,348 * 2176
    • -
  • => target = 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
    • +
  • => target = 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,​575,715,328
++++ @@ -634,7 +634,7 @@ switching back to hexadecimal: ++++
    -
  • => target = 0x0000000000000003A30C00000000000000000000000000000000000000000000
    • +
  • => target = 0x0000000000000003A30C000000000000000000000000​00000000000000000000
++++ From 33d62ab6362d6e2961310661600966b3b22cd1eb Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:55:39 -0700 Subject: [PATCH 06/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 894f16f8..7a96e672 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -626,7 +626,7 @@ which in decimal is: ++++
  • => target = 238,348 * 2176
    • -
  • => target = 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,​575,715,328
    • +
  • => target = ​22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
++++ @@ -634,7 +634,7 @@ switching back to hexadecimal: ++++
    -
  • => target = 0x0000000000000003A30C000000000000000000000000​00000000000000000000
    • +
  • => target = ​0x0000000000000003A30C00000000000000000000000000000000000000000000
++++ From cd2d1d6c1aeb62067ac3bc991137503b2155b6cb Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:58:18 -0700 Subject: [PATCH 07/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 7a96e672..ed098212 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -626,7 +626,7 @@ which in decimal is: ++++
  • => target = 238,348 * 2176
    • -
  • => target = ​22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
    • +
  • => target =
    22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
++++ @@ -634,7 +634,7 @@ switching back to hexadecimal: ++++
    -
  • => target = ​0x0000000000000003A30C00000000000000000000000000000000000000000000
    • +
  • => target =
    0x0000000000000003A30C00000000000000000000000000000000000000000000
++++ From ff3472c3ebed8a849e4916d89398b37fbe8ce6b4 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 10:59:23 -0700 Subject: [PATCH 08/11] Edited ch10.asciidoc with Atlas code editor --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index ed098212..47028166 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -634,7 +634,7 @@ switching back to hexadecimal: ++++
    -
  • => target =
    0x0000000000000003A30C00000000000000000000000000000000000000000000
    • +
  • => target =
    0x0000000000000003A30C00000000000000000000000000000000000000000000
++++ From 02cf61ecefac93c2ae2ac7c92fd82815e4146fcd Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 11:18:44 -0700 Subject: [PATCH 09/11] Edited ch07.asciidoc with Atlas code editor --- ch07.asciidoc | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index b86d6da6..60246b84 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -570,19 +570,19 @@ Here's the redeem script that Mohammed designs to achieve this: .Variable Multi-Signature with Timelock [source,linenum] ---- -IF - IF - 2 - ELSE - <30 days> CHECKSEQUENCEVERIFY DROP - CHECKSIGVERIFY - 1 - ENDIF - 3 CHECKMULTISIG -ELSE - <90 days> CHECKSEQUENCEVERIFY DROP - CHECKSIG -ENDIF +01 IF +02 IF +03 2 +04 ELSE +05 <30 days> CHECKSEQUENCEVERIFY DROP +06 CHECKSIGVERIFY +07 1 +08 ENDIF +09 3 CHECKMULTISIG +10 ELSE +11 <90 days> CHECKSEQUENCEVERIFY DROP +12 CHECKSIG +13 ENDIF ---- Mohammed's script implements three execution paths using nested +IF...ELSE+ flow control clauses. From b58b8194112e61d98f23933eb1e4599706fadeeb Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 11:19:15 -0700 Subject: [PATCH 10/11] Edited copyright.html with Atlas code editor --- copyright.html | 1 + 1 file changed, 1 insertion(+) diff --git a/copyright.html b/copyright.html index 74cd3170..f21721ce 100644 --- a/copyright.html +++ b/copyright.html @@ -34,6 +34,7 @@
  • 2017-06-01: First Release
  • 2017-07-21: Second Release
    • +
  • 2018-03-23: Third Release
From 6486a74a8603eeb9f82f75184a253498a97b8d79 Mon Sep 17 00:00:00 2001 From: "kristen@oreilly.com" Date: Wed, 14 Mar 2018 11:20:39 -0700 Subject: [PATCH 11/11] Edited ch07.asciidoc with Atlas code editor --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index 60246b84..f92c7384 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -565,7 +565,7 @@ Using this construct, we can build redeem scripts with tens or hundreds of execu ((("transactions", "advanced", "multisignature scripts")))((("scripting", "multisignature scripts", "import/export example")))((("multisignature scripts")))In this example, Mohammed wishes to construct a company capital account with flexible rules. The scheme he creates requires different levels of authorization depending on timelocks. The participants in the multisig scheme are Mohammed, his two partners Saeed and Zaira, and their company lawyer Abdul. The three partners make decisions based on a majority rule, so two of the three must agree. However, in the case of a problem with their keys, they want their lawyer to be able to recover the funds with one of the three partner signatures. Finally, if all partners are unavailable or incapacitated for a while, they want the lawyer to be able to manage the account directly. -Here's the redeem script that Mohammed designs to achieve this: +Here's the redeem script that Mohammed designs to achieve this (line number prefix as XX): .Variable Multi-Signature with Timelock [source,linenum]