Merge branch 'master' into develop

pull/531/head second_edition_print3
Andreas M. Antonopoulos 6 years ago
commit f8b883dcd4

@ -565,24 +565,24 @@ 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]
----
IF
IF
2
ELSE
<30 days> CHECKSEQUENCEVERIFY DROP
<Abdul the Lawyer's Pubkey> CHECKSIGVERIFY
1
ENDIF
<Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 CHECKMULTISIG
ELSE
<90 days> CHECKSEQUENCEVERIFY DROP
<Abdul the Lawyer's Pubkey> CHECKSIG
ENDIF
01 IF
02 IF
03 2
04 ELSE
05 <30 days> CHECKSEQUENCEVERIFY DROP
06 <Abdul the Lawyer's Pubkey> CHECKSIGVERIFY
07 1
08 ENDIF
09 <Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 CHECKMULTISIG
10 ELSE
11 <90 days> CHECKSEQUENCEVERIFY DROP
12 <Abdul the Lawyer's Pubkey> CHECKSIG
13 ENDIF
----
Mohammed's script implements three execution paths using nested +IF...ELSE+ flow control clauses.

@ -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*(exponent3))^
++++
<ul class="simplelist">
<li>target = coefficient * 2<sup>(8*(exponent3))</sup></li>
</ul>
++++
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^
++++
<ul class="simplelist">
<li>target = 0x03a30c * 2<sup>0x08*(0x19-0x03)</sup></li>
<li>=> target = 0x03a30c * 2<sup>(0x08*0x16)</sup></li>
<li>=> target = 0x03a30c * 2<sup>0xB0</sup></li>
</ul>
++++
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
++++
<ul class="simplelist">
<li>=> target = 238,348 * 2<sup>176</sup></li>
<li>=> target = <br/>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
</ul>
++++
switching back to hexadecimal:
=> target = 0x0000000000000003A30C00000000000000000000000000000000000000000000
++++
<ul class="simplelist">
<li>=> target = <br/>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
</ul>
++++
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.
@ -869,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
++++
<ul class="simplelist">
<li>P = (14 * 10<sup>12</sup> / 3 * 10<sup>18</sup>) * 210240 = 0.98</li>
</ul>
++++
...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.

@ -34,6 +34,7 @@
<ul class="releases">
<li><span class="revdate">2017-06-01:</span> First Release</li>
<li><span class="revdate">2017-07-21:</span> Second Release</li>
<li><span class="revdate">2018-03-23:</span> Third Release</li>
</ul>
</div>

@ -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 dont 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 cant 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 dont know about.
Not to be confused with fork, hard fork, software fork or Git fork.
Stale Block::
Block which was successfully mined but which isnt 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 isnt 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.

@ -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 youre 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 OReilly 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 products 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 (OReilly). 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 (OReilly). 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.

Loading…
Cancel
Save