diff --git a/_autocrossref.yaml b/_autocrossref.yaml
index bd8eeb31..0069a014 100644
--- a/_autocrossref.yaml
+++ b/_autocrossref.yaml
@@ -43,6 +43,7 @@ child private and public keys: child key
child public key:
child public keys: child public key
coinbase: coinbase transaction
+coinbase block height:
coinbase transaction:
coinbase transactions: coinbase transaction
coinbase field:
@@ -68,6 +69,7 @@ double-spend: double spend
double spending: double spend
double-spent: double spend
ECDSA:
+epoch time: unix epoch time
escrow contract:
'`expires`': pp expires
extended key:
@@ -82,7 +84,6 @@ hard fork:
hard forks: hard fork
hardened extended private key:
HD protocol:
-header nonce:
high-priority transaction: high-priority transactions
high-priority transactions:
inputs: input
@@ -120,6 +121,7 @@ mining: mine
millibit: millibits
millibits:
multisig:
+nbits:
network:
null data:
'`op_checkmultisig`': op_checkmultisig
@@ -229,6 +231,8 @@ txid:
txids: txid
unconfirmed:
unconfirmed transactions:
+unix epoch time:
+unix time: unix epoch time
unique address: unique addresses
unique addresses:
utxo:
@@ -249,6 +253,7 @@ BIP32:
BIP34:
BIP39:
BIP50:
+BIP62:
BIP70:
BIP71:
BIP72:
@@ -333,3 +338,4 @@ CVE-2012-2459:
'`walletpassphrasechange`': rpc walletpassphrasechange
Bitcoin Core 0.9.3:
+Bitcoin Core 0.7.0:
diff --git a/_includes/ref_block_chain.md b/_includes/ref_block_chain.md
index ed826949..6ffea750 100644
--- a/_includes/ref_block_chain.md
+++ b/_includes/ref_block_chain.md
@@ -2,94 +2,214 @@
The following subsections briefly document core block details.
-### Block Contents
+### Block Headers
{% autocrossref %}
-This section describes [version 2 blocks][v2 block]{:#term-v2-block}{:.term}, which are any blocks with a
-block height greater than 227,835. (Version 1 and version 2 blocks were
-intermingled for some time before that point.) Future block versions may
-break compatibility with the information in this section. You can determine
-the version of any block by checking its `version` field using
-bitcoind RPC calls.
+Block headers are serialized in the 80-byte format described below and then
+hashed as part of Bitcoin's proof-of-work algorithm, making the
+serialized header format part of the consensus rules.
-As of version 2 blocks, each block consists of four root elements:
+| Bytes | Name | Data Type | Description
+|-------|---------------------|-----------|----------------
+| 4 | version | uint32_t | The [block version][]{:#term-block-version}{:.term} number indicates which set of block validation rules to follow. See the list of block versions below.
+| 32 | previous block hash | char[32] | A SHA256(SHA256()) hash in internal byte order of the previous block's header. This ensures no previous block can be changed without also changing this block's header.
+| 32 | merkle root hash | char[32] | A SHA256(SHA256()) hash in internal byte order. The merkle root is derived from hashes of all transaction included in this block, ensuring none of those transactions can be modified without modifying the header. See the [merkle trees section][section merkle trees] below.
+| 4 | time | uint32_t | The [block time][]{:#term-block-time}{:.term} is a Unix epoch time when the miner started hashing the header (according to the miner). Must be greater than or equal to the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
+| 4 | nBits | uint32_t | An encoded version of the target threshold this block's header hash must be less than or equal to. See the nBits format described below.
+| 4 | nonce | uint32_t | An arbitrary number miners change to modify the header hash in order to produce a hash below the target threshold. If all 32-bit values are tested, the time can be updated or the coinbase transaction can be changed and the merkle root updated.
-1. A [magic number][block header magic]{:#term-block-header-magic}{:.term} (0xd9b4bef9).
+The hashes are in internal byte order; the other values are all
+in little-endian order.
-2. A 4-byte unsigned integer indicating how many bytes follow until the
- end of the block. Although this field would suggest maximum block
- sizes of 4 GiB, max block size is currently capped at 1 MB and the
- default max block size (used by most miners) is 750 KB (although
- this will likely increase over time).
+An example header in hex:
-3. An 80-byte block header described in the section below.
+{% highlight text %}
+02000000 .......................... Block version: 2
-4. One or more transactions.
+b6ff0b1b1680a2862a30ca44d346d9e8
+910d334beb48ca0c0000000000000000 ... Hash of previous block's header
+9d10aa52ee949386ca9385695f04ede2
+70dda20810decd12bc9b048aaab31471 ... Merkle root
-The first transaction in a block must be a [coinbase transaction][]{:#term-coinbase-tx}{:.term} which should collect and
+24d95a54 ........................... Unix time: 1415239972
+30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3)
+fe9f0864 ........................... Nonce
+{% endhighlight %}
+
+{% endautocrossref %}
+
+#### Block Versions
+
+{% autocrossref %}
+
+* **Version 1** was introduced in the genesis block (January 2009).
+
+* **[Version 2][v2 block]{:#term-v2-block}{:.term}** was introduced in
+ Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in
+ BIP34, valid version 2 blocks require a [block height parameter in the
+ coinbase][coinbase block height]. Also described in BIP34 are rules
+ for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0
+ and later versions began to reject version 2 blocks without the block
+ height in coinbase at block height 224,412 (March 2013) and began to
+ reject new version 1 blocks three weeks later at block height 227,930.
+
+
+* **Version 3** blocks will likely be introduced in the near-future as
+ specified in draft BIP62. Possible changes include:
+
+ * Reject version 3 blocks that include any version 2 transactions
+ that don't adhere to any of the version 2 transaction rules.
+ These rules are not yet described in this documentation; see
+ BIP62 for details.
+
+ * A soft fork rollout of version 3 blocks identical to the rollout
+ used for version 2 blocks (described briefly in BIP62 and in more
+ detail in BIP34).
+
+{% endautocrossref %}
+
+#### Merkle Trees
+
+{% autocrossref %}
+
+*For an overview of merkle trees, see the [block chain guide][merkle
+tree].*
+
+The merkle root is constructed using all the TXIDs of transactions in
+this block, but first the TXIDs are placed in order as required by the
+consensus rules:
+
+* The coinbase transaction's TXID is always placed first.
+
+* Any input within this block can spend an output which also appears in
+ this block (assuming the spend is otherwise valid). However, the TXID
+ corresponding to the output must be placed at some point before the
+ TXID corresponding to the input. This ensures that any program parsing
+ block chain transactions linearly will encounter each output before it
+ is used as an input.
+
+If a block only has a coinbase transaction, the coinbase TXID is used as
+the merkle root hash.
+
+If a block only has a coinbase transaction and one other transaction,
+the TXIDs of those two transactions are placed in order, concatenated as
+64 raw bytes, and then SHA256(SHA256()) hashed together to form the
+merkle root.
+
+If a block has three or more transactions, intermediate merkle tree rows
+are formed. The TXIDs are placed in order and paired, starting with the
+coinbase transaction's TXID. Each pair is concatenated together as 64
+raw bytes and SHA256(SHA256()) hashed to form a second row of
+hashes. If there are an odd (non-even) number of TXIDs, the last TXID is
+concatenated with a copy of itself and hashed. If there are more than
+two hashes in the second row, the process is repeated to create a third
+row (and, if necessary, repeated further to create additional rows).
+Once a row is obtained with only two hashes, those hashes are concatenated and
+hashed to produce the merkle root.
+
+
+
+
+
+TXIDs and intermediate hashes are always in internal byte order when they're
+concatenated, and the resulting merkle root is also in internal byte
+order when it's placed in the block header.
+
+{% endautocrossref %}
+
+#### Target nBits
+
+{% autocrossref %}
+
+The target threshold is a 256-bit unsigned integer compared the 256-bit
+SHA256(SHA256()) header hash (treated also as an unsigned integer).
+However, the header field *nBits* provides only 32 bits of space, so the
+target number uses a less precise format called "compact" which works
+like a base-256 version of scientific notation:
+
+
+
+As a base-256 number, nBits can be quickly parsed as bytes the same way
+you might parse a decimal number in base-10 scientific notation:
+
+
+
+
+
+Although the target threshold should be an unsigned integer, the
+original nBits implementation inherits properties from a signed data
+class, allowing the target threshold to be negative if the high bit of
+the significand is set. This is useless---the header hash is
+treated as an unsigned number, so it can never be equal to or lower than a
+negative target threshold. Bitcoin Core deals with this in two ways:
+
+
+
+* When parsing nBits, Bitcoin Core converts a negative target
+ threshold into a target of zero, which the header hash can equal (in
+ theory, at least).
+
+* When creating a value for nBits, Bitcoin Core checks to see if it will
+ produce an nBits which will be interpreted as negative; if so, it
+ divides the significand by 256 and increases the exponent by 1 to
+ produce the same number with a different encoding.
+
+Some examples taken from the Bitcoin Core test cases:
+
+| nBits | Target | Notes
+|------------|------------------|----------------
+| 0x01003456 | 0x00 |
+| 0x01123456 | 0x12 |
+| 0x02008000 | 0x80 |
+| 0x05009234 | 0x92340000 |
+| 0x04923456 | -0x12345600 | High bit set (0x80 in 0x92).
+| 0x04123456 | 0x12345600 | Inverse of above; no high bit.
+
+Difficulty 1, the minimum allowed difficulty, is represented on mainnet
+and the current testnet by the nBits value 0x1d00ffff. Regtest mode uses
+a different difficulty 1 value---0x207fffff, the highest possible value
+below uint32_max which can be encoded; this allows near-instant building
+of blocks in regtest mode.
+
+{% endautocrossref %}
+
+
+### Serialized Blocks
+
+{% autocrossref %}
+
+Under current consensus rules, a block is not valid unless its
+serialized size is less than or equal to 1 MB. All fields described
+below are counted towards the serialized size.
+
+| Bytes | Name | Data Type | Description
+| 80 | block header | block_header | The block header in the format described in the [block header section][block header].
+| *Varies* | txn_count | compactSize uint | The total number of transactions in this block, including the coinbase transaction.
+| *Varies* | txns | raw transaction | Every transaction in this block, one after another, in raw transaction format. Transactions must appear in the data stream in the same order their TXIDs appeared in the first row of the merkle tree. See the [merkle tree section][section merkle trees] for details.
+
+The first transaction in a block must be a [coinbase
+transaction][]{:#term-coinbase-tx}{:.term} which should collect and
spend any transaction fees paid by transactions included in this block.
+
All blocks with a block height less than 6,930,000 are entitled to
-receive a [block reward][]{:#term-block-reward}{:.term} of newly created bitcoin value, which also
-should be spent in the coinbase transaction. (The block reward started
-at 50 bitcoins and is being halved every 210,000 blocks---approximately once every four years. As of
-June 2014, it's 25 bitcoins.) A coinbase transaction is invalid if it
-tries to spend more value than is available from the transaction
-fees and block reward.
+receive a block subsidy of newly created bitcoin value, which also
+should be spent in the coinbase transaction. (The block subsidy started
+at 50 bitcoins and is being halved every 210,000 blocks---approximately
+once every four years. As of November 2014, it's 25 bitcoins.)
-The coinbase transaction has the same basic format as any other
-transaction, but it references a single non-existent UTXO and a special
-[coinbase field][]{:#term-coinbase-field}{:.term} replaces the field that would normally hold a signature script and
-secp256k1 signature. In version 2 blocks, the coinbase parameter must begin with
-the current block's block height and may contain additional arbitrary
-data or a script up to a maximum total of 100 bytes.
+Together, the transaction fees and block subsidy are called the [block
+reward][]{:#term-block-reward}{:.term}. A coinbase transaction is
+invalid if it tries to spend more value than is available from the
+block reward.
{% endautocrossref %}
-### Block Header
-
-{% autocrossref %}
-
-The 80-byte block header contains the following six fields:
-
-| Field | Bytes | Format |
-|-------------------|--------|--------------------------------|
-| 1. Version | 4 | Unsigned Int |
-| 2. hashPrevBlock | 32 | Unsigned Int (SHA256 Hash) |
-| 3. hashMerkleRoot | 32 | Unsigned Int (SHA256 Hash) |
-| 4. Time | 4 | Unsigned Int (Epoch Time) |
-| 5. Bits | 4 | Internal Bitcoin Target Format |
-| 6. Nonce | 4 | (Arbitrary Data) |
-
-1. The *[block version][]{:#term-block-version}{:.term}* number indicates which set of block validation rules
- to follow so Bitcoin Core developers can add features or
- fix bugs. As of block height 227,836, all blocks use version number
- 2.
-
-2. The *hash of the previous block header* puts this block on the
- block chain and ensures no previous block can be changed without also
- changing this block's header.
-
-3. The *merkle root* is a hash derived from hashes of all the
- transactions included in this block. It ensures no transactions can
- be modified in this block without changing the block header hash.
-
-4. The *[block time][]{:#term-block-time}{:.term}* is the approximate time when this block was created in
- Unix Epoch time format (number of seconds elapsed since
- 1970-01-01T00:00 UTC). The time value must be greater than the
- median time of the previous 11 blocks. No peer will accept a block with a
- time currently more than two hours in the future according to the
- peer's clock.
-
-5. *Bits* translates into the target threshold value---the maximum allowed
- value for this block's hash. The bits value must match the network
- difficulty at the time the block was mined.
-
-6. The *[header nonce][]{:#term-header-nonce}{:.term}* is an arbitrary input that miners can change to test different
- hash values for the header until they find a hash value less than or
- equal to the target threshold. If all values within the nonce's four
- bytes are tested, the time can be updated or the
- coinbase transaction can be changed and the merkle
- root updated.
-
-{% endautocrossref %}
diff --git a/_includes/ref_transactions.md b/_includes/ref_transactions.md
index f64cc2fe..06256f6a 100644
--- a/_includes/ref_transactions.md
+++ b/_includes/ref_transactions.md
@@ -319,8 +319,8 @@ has the following format.
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
-| *Varies* (4) | height | script | The block height of this block as required by BIP34. Uses script language: starts with a data-pushing op code that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.
The data-pushing op code will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
-| *Varies* | coinbase script | *None* | Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
+| *Varies* (4) | height | script | The [block height][]{:#term-coinbase-block-height}{:.term} of this block as required by BIP34. Uses script language: starts with a data-pushing op code that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.
The data-pushing op code will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
+| *Varies* | coinbase script | *None* | The [coinbase field][]{:#term-coinbase-field}{:.term}: Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
| 4 | sequence | uint32_t | Sequence number; see [sequence number][].
Most (but not all) blocks prior to block height 227,836 used block
diff --git a/_includes/references.md b/_includes/references.md
index b8c0a6fb..52c318d1 100644
--- a/_includes/references.md
+++ b/_includes/references.md
@@ -9,8 +9,7 @@
[block]: /en/developer-guide#term-block "A block of transactions protected by proof of work"
[blocks]: /en/developer-guide#term-block "Blocks of transactions protected by proof of work"
[block chain]: /en/developer-guide#block-chain "A chain of blocks with each block linking to the block that preceded; the most-difficult-to-recreate chain is The Block Chain"
-[block header]: /en/developer-reference#block-header "An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work"
-[block header magic]: /en/developer-reference#term-block-header-magic "A magic number used to separate block data from transaction data on the P2P network"
+[block header]: /en/developer-reference#block-headers "An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work"
[block height]: /en/developer-guide#term-block-height "The number of chained blocks preceding this block"
[block reward]: /en/developer-reference#term-block-reward "New satoshis given to a miner for creating one of the first 6,929,999 blocks"
[block time]: /en/developer-reference#term-block-time "The time field in the block header"
@@ -24,6 +23,7 @@
[change output]: /en/developer-guide#term-change-output "An output used by a spender to send back to himself some of the satoshis from the inputs"
[child key]: /en/developer-guide#term-child-key "In HD wallets, a key derived from a parent key"
[child public key]: /en/developer-guide#term-child-public-key "In HD wallets, a public key derived from a parent public key or a corresponding child private key"
+[coinbase block height]: /en/developer-reference#term-coinbase-block-height "The current block's height encoded into the first bytes of the coinbase field"
[coinbase field]: /en/developer-reference#term-coinbase-field "A special input-like field for coinbase transactions"
[coinbase transaction]: /en/developer-reference#term-coinbase-tx "A special transaction which miners must create when they generate a block"
[compactsize unsigned integer]: /en/developer-reference#compactsize-unsigned-integers "A type of variable-length integer"
@@ -48,7 +48,6 @@
[hard fork]: /en/developer-guide#term-hard-fork "A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can't validate blocks created by upgraded nodes following newer consensus rules."
[hardened extended private key]: /en/developer-guide#term-hardened-extended-private-key "A private key whose corresponding public key cannot derive child keys"
[HD protocol]: /en/developer-guide#term-hd-protocol "The Hierarchical Deterministic (HD) key creation and transfer protocol"
-[header nonce]: /en/developer-reference#term-header-nonce "Four bytes of arbitrary data in a block header used to let miners create headers with different hashes for proof of work"
[high-priority transactions]: /en/developer-guide#term-high-priority-transactions "Transactions which don't pay a transaction fee; only transactions spending long-idle outputs are eligible"
[input]: /en/developer-guide#term-input "The input to a transaction linking to the output of a previous transaction which permits spending of satoshis"
[inputs]: /en/developer-guide#term-input "The input to a transaction linking to the output of a previous transaction which permits spending of satoshis"
@@ -74,6 +73,7 @@
[miners]: /en/developer-guide#term-miner "Creators of Bitcoin blocks who solve proof-of-work puzzles in exchange for block rewards and transaction fees"
[minimum fee]: /en/developer-guide#term-minimum-fee "The minimum fee a transaction must pay in must circumstances to be mined or broadcast by peers across the network"
[multisig]: /en/developer-guide#term-multisig "An pubkey script using OP_CHECKMULTISIG to check for multiple signatures"
+[nbits]: /en/developer-reference#target-nbits "The encoded form of the target threshold as it appears in the block header"
[network]: /en/developer-guide#term-network "The Bitcoin P2P network which broadcasts transactions and blocks"
[Null data]: /en/developer-guide#term-null-data "A standard transaction type which allows adding 40 bytes of arbitrary data to the block chain up to once per transaction"
[op_checkmultisig]: /en/developer-reference#term-op-checkmultisig "Op code which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n)"
@@ -243,6 +243,7 @@
[rpc walletpassphrasechange]: /en/developer-reference#walletpassphrasechange
+[Bitcoin Core 0.7.0]: /en/release/v0.7.0
[Bitcoin Core 0.9.3]: /en/release/v0.9.3
[bitcoin URI subsection]: /en/developer-guide#bitcoin-uri
[bitcoinpdf]: https://bitcoin.org/bitcoin.pdf
@@ -265,6 +266,7 @@
[RPCs]: /en/developer-reference#remote-procedure-calls-rpcs
[section detecting forks]: /en/developer-guide#detecting-forks
[section hash byte order]: /en/developer-reference#hash-byte-order
+[section merkle trees]: /en/developer-reference#merkle-trees
[section simple raw transaction]: /en/developer-examples#simple-raw-transaction
[section verifying payment]: /en/developer-guide#verifying-payment
[signature script modification warning]: /en/developer-reference#signature_script_modification_warning
@@ -281,6 +283,7 @@
[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
[BIP39]: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
+[BIP62]: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
[BIP70]: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
[BIP71]: https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki
[BIP72]: https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki
@@ -326,6 +329,7 @@
[python-blkmaker]: https://gitorious.org/bitcoin/python-blkmaker
[SHA256]: https://en.wikipedia.org/wiki/SHA-2
[Stratum mining protocol]: http://mining.bitcoin.cz/stratum-mining
+[unix epoch time]: https://en.wikipedia.org/wiki/Unix_time
[URI encoded]: https://tools.ietf.org/html/rfc3986
[wiki script]: https://en.bitcoin.it/wiki/Script
[x509]: https://en.wikipedia.org/wiki/X.509
diff --git a/img/dev/en-merkle-tree-construction.dot b/img/dev/en-merkle-tree-construction.dot
new file mode 100644
index 00000000..32f75cea
--- /dev/null
+++ b/img/dev/en-merkle-tree-construction.dot
@@ -0,0 +1,42 @@
+digraph {
+
+size=6.25;
+rankdir=TB
+//splines = ortho;
+ranksep = 0.2;
+nodesep = 0.3;
+
+edge [ penwidth = 1.75, fontname="Sans" ]
+node [ penwidth = 1.75, shape = "box", fontname="Sans", ]
+graph [ penwidth = 1.75, fontname="Sans" ]
+
+{
+ node [ shape = "none" ];
+ txids [ label = "Row 1: Transaction hashes (TXIDs)\n(A is coinbase; C can spend output from B)" ];
+ row2 [ label = "Row 2: Hashes of paired TXIDs" ];
+ rootrow [ label = "Merkle root" ];
+
+ txids -> row2 -> rootrow [ style = "invis" ];
+}
+
+txid_a [ label = "A" ];
+txid_b [ label = "B" ];
+txid_invis [ label = "C", style = "invis" ];
+txid_c [ label = "C" ];
+
+row2_ab [ label = "H(A|B)" ];
+row2_cc [ label = "H(C|C)" ];
+
+root [ label = "H(H(A|B)|H(C|C))" ];
+
+txid_a -> row2_ab [ weight = 1 ];
+txid_b -> row2_ab [ weight = 1 ];
+txid_c -> row2_cc;
+txid_invis -> row2_cc [ style = "invis" ];
+
+row2_ab -> root;
+row2_cc -> root;
+
+
+label = "\n Example Merkle Tree Construction [Hash function H() = SHA256(SHA256())]"
+}
diff --git a/img/dev/en-merkle-tree-construction.png b/img/dev/en-merkle-tree-construction.png
new file mode 100644
index 00000000..11d4e42d
Binary files /dev/null and b/img/dev/en-merkle-tree-construction.png differ
diff --git a/img/dev/en-merkle-tree-construction.svg b/img/dev/en-merkle-tree-construction.svg
new file mode 100644
index 00000000..93bcb738
--- /dev/null
+++ b/img/dev/en-merkle-tree-construction.svg
@@ -0,0 +1,86 @@
+
+
+
+
+
diff --git a/img/dev/en-nbits-overview.dot b/img/dev/en-nbits-overview.dot
new file mode 100644
index 00000000..b6023bab
--- /dev/null
+++ b/img/dev/en-nbits-overview.dot
@@ -0,0 +1,29 @@
+digraph {
+
+size=6.25;
+rankdir=TB
+//splines = ortho;
+ranksep = 0.0;
+nodesep = 0.0;
+
+edge [ penwidth = 1.75, fontname="Sans" ]
+node [ penwidth = 1.75, shape = "none", fontname="Sans", width = 0, height = 0]
+graph [ penwidth = 0, fontname="Sans" ]
+
+nbits [ label = "0x181bc330 → \n \nnBits In\nBig-Endian\nOrder" ];
+
+significand [ label = "0x1bc330\n \nSignificand\n(Mantissa)\n " ];
+times [ label = "*\n \n \n \n " ];
+
+base [ label = "256\n \nBase\n \n " ];
+exp [ label = "^\n \n \n \n " ];
+exponent [ label = "(0x18\n \nExponent\n \n " ];
+minus [ label = "-\n \n \n \n " ];
+negative [ label = "3)\n \nBytes\nIn\nSignificand" ];
+
+base -> result [ style = "invis" ];
+
+result [ label = "Result: 0x1bc330000000000000000000000000000000000000000000 " ];
+
+label = "Converting nBits Into A Target Threshold"
+}
diff --git a/img/dev/en-nbits-overview.png b/img/dev/en-nbits-overview.png
new file mode 100644
index 00000000..12741957
Binary files /dev/null and b/img/dev/en-nbits-overview.png differ
diff --git a/img/dev/en-nbits-overview.svg b/img/dev/en-nbits-overview.svg
new file mode 100644
index 00000000..1dc577aa
--- /dev/null
+++ b/img/dev/en-nbits-overview.svg
@@ -0,0 +1,83 @@
+
+
+
+
+
diff --git a/img/dev/en-nbits-quick-parse.dot b/img/dev/en-nbits-quick-parse.dot
new file mode 100644
index 00000000..425ade01
--- /dev/null
+++ b/img/dev/en-nbits-quick-parse.dot
@@ -0,0 +1,122 @@
+digraph {
+
+size=6.25;
+rankdir=TB
+//splines = ortho;
+ranksep = 0.0;
+nodesep = 0.0;
+
+edge [ penwidth = 1.75, fontname="Sans", style = "invis" ]
+node [ penwidth = 1.75, shape = "box", fontname="Sans", fontsize = 60, width = 1.3, height = 1.3 ]
+graph [ penwidth = 0, fontname="Sans", fontsize = 60 ]
+
+byte_length [ label = "Byte Length: 0x18 (Decimal 24)", shape = "none" ]
+
+
+subgraph cluster_n {
+node [ label = "0" ];
+ n24;
+ n23;
+ n22;
+ n21;
+ n20;
+ n19;
+ n18;
+ n17;
+ n16;
+ n15;
+ n14;
+ n13;
+ n12;
+ n11;
+ n10;
+ n9;
+ n8;
+ n7;
+ n6;
+ n5;
+ n4;
+ n1 [ label = "" ];
+ n2 [ label = "" ];
+ n3 [ label = "" ];
+}
+
+
+
+subgraph cluster_l {
+node [ shape = "none" ];
+l1 [ label = "1" ];
+l2 [ label = "2" ];
+l3 [ label = "3" ];
+l4 [ label = "4" ];
+l5 [ label = "5" ];
+l6 [ label = "6" ];
+l7 [ label = "7" ];
+l8 [ label = "8" ];
+l9 [ label = "9" ];
+l10 [ label = "10" ];
+l11 [ label = "11" ];
+l12 [ label = "12" ];
+l13 [ label = "13" ];
+l14 [ label = "14" ];
+l15 [ label = "15" ];
+l16 [ label = "16" ];
+l17 [ label = "17" ];
+l18 [ label = "18" ];
+l19 [ label = "19" ];
+l20 [ label = "20" ];
+l21 [ label = "21" ];
+l22 [ label = "22" ];
+l23 [ label = "23" ];
+l24 [ label = "24" ];
+}
+
+l1 -> n1;
+l2 -> n2;
+l3 -> n3;
+l4 -> n4;
+l5 -> n5;
+l6 -> n6;
+l7 -> n7;
+l8 -> n8;
+l9 -> n9;
+l10 -> n10;
+l11 -> n11;
+l12 -> n12;
+l13 -> n13;
+l14 -> n14;
+l15 -> n15;
+l16 -> n16;
+l17 -> n17;
+l18 -> n18;
+l19 -> n19;
+l20 -> n20;
+l21 -> n21;
+l22 -> n22;
+l23 -> n23;
+l24 -> n24;
+
+subgraph cluster_s {
+ node [ shape = "none" ];
+ edge [ style = "", dir="back", arrowsize = 3, minlen = 4 ];
+
+
+ significand [ label = "Most Significant Bytes (Significand)" ];
+ s3 [ label = "30" ];
+ s2 [ label = "c3" ];
+ s1 [ label = "1b" ];
+
+ n1 -> s1;
+ n2 -> s2;
+ n3 -> s3;
+}
+
+
+
+
+
+
+byte_length -> l19;
+
+label = " \nQuickly Converting nBits 0x181bc330 Into The Target\nThreshold 0x1bc330000000000000000000000000000000"
+}
diff --git a/img/dev/en-nbits-quick-parse.png b/img/dev/en-nbits-quick-parse.png
new file mode 100644
index 00000000..517d508b
Binary files /dev/null and b/img/dev/en-nbits-quick-parse.png differ
diff --git a/img/dev/en-nbits-quick-parse.svg b/img/dev/en-nbits-quick-parse.svg
new file mode 100644
index 00000000..e5e0f08f
--- /dev/null
+++ b/img/dev/en-nbits-quick-parse.svg
@@ -0,0 +1,298 @@
+
+
+
+
+