diff --git a/_autocrossref.yaml b/_autocrossref.yaml index a1fe539c..62eaffdc 100644 --- a/_autocrossref.yaml +++ b/_autocrossref.yaml @@ -48,6 +48,8 @@ confirmed: confirmation: confirmations: confirmed transactions: +consensus: +consensus rules: denomination: denominations: denomination DER format: der @@ -65,8 +67,11 @@ extended keys: extended key extended private key: extended public key: fiat: -fork: accidental fork +fork: +forks: fork genesis block: +hard fork: +hard forks: hard fork hardened extended private key: HD protocol: header nonce: @@ -76,6 +81,7 @@ inputs: input input: intermediate certificate: intermediate certificates: intermediate certificate +internal byte order: key index: key pair: '`label`': label @@ -165,6 +171,7 @@ root certificate: root seed: RPCs: rpc RPC: +RPC byte order: satoshi: satoshis: satoshi '`script`': pp script @@ -184,6 +191,8 @@ signature hash: signature script: signature scripts: signature script signatures: signature +soft fork: +soft forks: soft fork SPV: stack: stale block: @@ -217,10 +226,14 @@ wallet import format: x.509: x509 X509Certificates: -## BIPS in numerical order; don't use padding zeros (e.g. BIP70 not BIP0070) +## BIPs in numerical order; don't use padding zeros (e.g. BIP70 not BIP0070) +BIP16: BIP21: +BIP30: BIP32: +BIP34: BIP39: +BIP50: BIP70: BIP71: BIP72: diff --git a/_includes/guide_block_chain.md b/_includes/guide_block_chain.md index 12b010a5..1c7d3aa1 100644 --- a/_includes/guide_block_chain.md +++ b/_includes/guide_block_chain.md @@ -4,8 +4,15 @@ The block chain provides Bitcoin's public ledger, an ordered and timestamped record of transactions. This system is used to protect against double spending -and modification of previous transaction records, using proof of -work verified by the peer-to-peer network to maintain a global consensus. +and modification of previous transaction records. + +Each full node in the Bitcoin network independently stores a block chain +containing only blocks validated by that node. When several nodes all +have the same blocks in their block chain, they are considered to be in +[consensus][]{:#term-consensus}{:.term}. The validation rules these +nodes follow to maintain consensus are called [consensus +rules][]{:#term-consensus-rules}{:.term}. This section describes many of +the consensus rules used by Bitcoin Core. {% endautocrossref %} @@ -148,7 +155,7 @@ block 2016 is where difficulty could have first been adjusted. Multiple blocks can all have the same block height, as is common when two or more miners each produce a block at roughly the same time. This -creates an apparent [fork][accidental fork]{:#term-accidental-fork}{:.term} in the block chain, as shown in the +creates an apparent [fork][]{:#term-fork}{:.term} in the block chain, as shown in the illustration above. When miners produce simultaneous blocks at the end of the block chain, each @@ -244,3 +251,104 @@ Since it is impractical to have separate transactions with identical txids, this otherwise, a valid block with the duplicates eliminated could have the same merkle root and block hash, but be rejected by the cached invalid outcome, resulting in security bugs such as CVE-2012-2459. {% endautocrossref %} + +### Consensus Rule Changes + +{% autocrossref %} + +To maintain consensus, all full nodes validate blocks using the same +consensus rules. However, sometimes the consensus rules are changed to +introduce new features or prevent network abuse. When the new rules are +implemented, there will likely be a period of time when non-upgraded +nodes follow the old rules and upgraded nodes follow the new rules, +creating two possible ways consensus can break: + +1. A block following the new consensus rules is accepted by upgraded + nodes but rejected by non-upgraded nodes. For example, a new + transaction feature is used within a block: upgraded nodes understand + the feature and accept it, but non-upgraded nodes reject it because + it violates the old rules. + +2. A block violating the new consensus rules is rejected by upgraded + nodes but accepted by non-upgraded nodes. For example, an abusive + transaction feature is used within a block: upgraded nodes reject it + because it violates the new rules, but non-upgraded nodes accept it + because it follows the old rules. + +In the first case, rejection by non-upgraded nodes, mining software +which gets block chain data from those non-upgraded nodes refuses to +build on the same chain as mining software getting data from upgraded +nodes. This creates permanently divergent chains---one for non-upgraded +nodes and one for upgraded nodes---called a [hard +fork][]{:#term-hard-fork}{:.term}. + +![Hard Fork](/img/dev/en-hard-fork.svg) + +In the second case, rejection by upgraded nodes, it's possible to keep +the block chain from permanently diverging if upgraded nodes control a +majority of the hash rate. That's because, in this case, non-upgraded +nodes will accept as valid all the same blocks as upgraded nodes, so the +upgraded nodes can build a stronger chain that the non-upgraded nodes +will accept as the best valid block chain. This is called a [soft +fork][]{:#term-soft-fork}{:.term}. + +![Soft Fork](/img/dev/en-soft-fork.svg) + +Although a fork is an actual divergence in block chains, changes to the +consensus rules are often described by their potential to create either +a hard or soft fork. For example, "increasing the block size above 1 MB +requires a hard fork." In this example, an actual block chain fork is +not required---but it is a possible outcome. + +**Resources:** [BIP16][], [BIP30][], and [BIP34][] were implemented as +changes which might have lead to soft forks. [BIP50][] describes both an +accidental hard fork, resolved by temporary downgrading the capabilities +of upgraded nodes, and an intentional hard fork when the temporary +downgrade was removed. A document from Gavin Andresen outlines [how +future rule changes may be +implemented](https://gist.github.com/gavinandresen/2355445). + +{% endautocrossref %} + +#### Detecting Forks + +{% autocrossref %} + +Non-upgraded nodes may use and distribute incorrect information during +both types of forks, creating several situations which could lead to +financial loss. In particular, non-upgraded nodes may relay and accept +transactions that are considered invalid by upgraded nodes and so will +never become part of the universally-recognized best block chain. +Non-upgraded nodes may also refuse to relay blocks or transactions which +have already been added to the best block chain, or soon will be, and so +provide incomplete information. + + + +Bitcoin Core includes code that detects a hard fork by looking at block +chain proof of work. If a node receives block chain headers +demonstrating six blocks more proof of work than the best chain this +node considers valid, the node reports an error in the `getinfo` RPC +results and runs the `-alertnotify` command if set. + +Full nodes can also check block and transaction version numbers. If the +block or transaction version numbers seen in several recent blocks are +higher than the version numbers the node uses, it can assume it doesn't +use the current consensus rules. Future versions of Bitcoin Core +(>0.9.3) will likely report this situation through the `getinfo` RPC and +`-alertnotify` command if set. + +In either case, data should not be relied upon if it comes from a node +that apparently isn't using the current consensus rules. + +SPV clients which connect to full nodes can detect a likely hard fork by +connecting to several full nodes and ensuring that they're all on the +same chain with the same block height, plus or minus several blocks to +account for transmission delays and stale blocks. If there's a +divergence, the client can disconnect from nodes with weaker chains. + +SPV clients should also monitor for block and transaction version number +increases to ensure they process received transactions and create new +transactions using the current consensus rules. + +{% endautocrossref %} diff --git a/_includes/guide_payment_processing.md b/_includes/guide_payment_processing.md index 9ebce56b..76aa932a 100644 --- a/_includes/guide_payment_processing.md +++ b/_includes/guide_payment_processing.md @@ -488,7 +488,8 @@ estimate the amount of time until they're added to a block. Another example could be to detect a fork when multiple peers report differing block header hashes at the same block height. Your program can go into a safe mode if the fork extends for more than two blocks, indicating a possible problem with the -block chain. +block chain. For more details, see the [Detecting Forks +subsection][section detecting forks]. Another good source of double-spend protection can be human intelligence. For example, fraudsters may act differently from legitimate customers, letting diff --git a/_includes/ref_core_rpc_intro.md b/_includes/ref_core_rpc_intro.md new file mode 100644 index 00000000..e24c01ba --- /dev/null +++ b/_includes/ref_core_rpc_intro.md @@ -0,0 +1,92 @@ +### Hash Byte Order + +{% autocrossref %} + +Bitcoin Core RPCs accept and return hashes in the reverse of their +normal byte order. For example, the Unix `sha256sum` command would display the +SHA256(SHA256()) hash of Mainnet block 300,000's header as the +following string: + + 5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc820000000000000000 + +The string above is also how the hash appears in the +previous-header-hash part of block 300,001's header: + +
020000005472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc82000\
+0000000000000ab0aaa377ca3f49b1545e2ae6b0667a08f42e72d8c24ae\
+237140e28f14f3bb7c6bcc6d536c890019edd83ccf
+ +However Bitcoin RPCs use the reverse byte order for hashes, so if you +want to get information about block 300,000 using the `getblock` RPC, +you need to reverse the byte order: + + > bitcoin-cli getblock \ + 000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254 + +(Note: hex representation uses two characters to display each byte of +data, which is why the reversed string looks somewhat mangled.) + +The rational for the reversal is unknown, but it likely stems from +Bitcoin's use of hash digests (which are byte arrays in C++) as integers +for the purpose of determining whether the hash is below the network +target. Whatever the reason for reversing header hashes, the reversal +also extends to other hashes used in RPCs, such as TXIDs and merkle +roots. + +Off-site documentation such as the Bitcoin Wiki tends to use the terms +big endian and little endian as shown in the table below, but they +aren't always consistent. Worse, these two different ways of +representing a hash digest can confuse anyone who looks at the Bitcoin +Core source code and finds a so-called "big endian" value being stored +in a little-endian data type. + +As header hashes and TXIDs are widely used as global identifiers in +other Bitcoin software, this reversal of hashes has become the standard +way to refer to certain objects. The table below should make clear where +each byte order is used. + +
+ +|---------------+---------------------|-----------------| +| Data | Internal Byte Order ("Big Endian") | RPC Byte Order ("Little Endian") | +|---------------|---------------------|-----------------| +| Example: SHA256(SHA256(0x00)) | Hash: 1406...539a | Hash: 9a53...0614 | +|---------------|---------------------|-----------------| +| Header Hashes: SHA256(SHA256(block header)) | Used when constructing block headers | Used by RPCs such as `getblock`; widely used in block explorers | +|---------------|---------------------|-----------------| +| merkle Roots: SHA256(SHA256(TXIDs and merkle rows)) | Used when constructing block headers | Returned by RPCs such as `getblock` | +|---------------|---------------------|-----------------| +| TXIDs: SHA256(SHA256(transaction)) | Used in transaction inputs | Used by RPCs such as `gettransaction` and transaction data parts of `getblock`; widely used in wallet programs | +|---------------|---------------------|-----------------| +| P2PKH Hashes: RIPEMD160(SHA256(pubkey)) | Used in both addresses and pubkey scripts | **N/A:** RPCs use addresses which use internal byte order | +|---------------|---------------------|-----------------| +| P2SH Hashes: RIPEMD160(SHA256(redeem script)) | Used in both addresses and pubkey scripts | **N/A:** RPCs use addresses which use internal byte order | +|---------------|---------------------|-----------------| + +
+ +Note: RPCs which return raw results, such as `getrawtransaction` or the +raw mode of `getblock`, always display hashes as they appear in blocks +(internal byte order). + +The code below may help you check byte order by generating hashes +from raw hex. +{% endautocrossref %} + +{% highlight python %} +#!/usr/bin/env python + +from sys import byteorder +from hashlib import sha256 + +## You can put in $data an 80-byte block header to get its header hash, +## or a raw transaction to get its txid +data = "00".decode("hex") +hash = sha256(sha256(data).digest()).digest() + +print "Warning: this code only tested on a little-endian x86_64 arch" +print +print "System byte order:", byteorder +print "Internal-Byte-Order Hash: ", hash.encode('hex_codec') +print "RPC-Byte-Order Hash: ", hash[::-1].encode('hex_codec') +{% endhighlight %} diff --git a/_includes/ref_core_rpcs-abcdefg.md b/_includes/ref_core_rpcs-abcdefg.md index 0ca49970..c8b028f1 100644 --- a/_includes/ref_core_rpcs-abcdefg.md +++ b/_includes/ref_core_rpcs-abcdefg.md @@ -1542,8 +1542,7 @@ An array of *transactions* in [transaction object format][]{:#term-transaction-o {% autocrossref %} Each object in the array contains the -rawtransaction *data* in hex and the *hash* of the data in little-endian -hex. +rawtransaction *data* in hex and the *hash* of the data in RPC byte order. {% endautocrossref %} diff --git a/_includes/ref_transactions.md b/_includes/ref_transactions.md index 819dcbf0..1260ed70 100644 --- a/_includes/ref_transactions.md +++ b/_includes/ref_transactions.md @@ -89,7 +89,7 @@ bytes commonly used by Bitcoin are: 2. Create a copy of the version and hash; then hash that twice with SHA256: `SHA256(SHA256(version . hash))` -3. Extract the four most significant bytes from the double-hashed copy. +3. Extract the first four bytes from the double-hashed copy. These are used as a checksum to ensure the base hash gets transmitted correctly. @@ -138,6 +138,10 @@ Bitcoin transactions are broadcast between peers and stored in the block chain in a serialized byte format, called [raw format][]{:#term-raw-format}{:.term}. Bitcoin Core and many other tools print and accept raw transactions encoded as hex. +The binary form of a raw transaction is SHA256(SHA256()) hashed to create +its TXID. Bitcoin Core RPCs use a reversed byte order for hashes; see the [subsection about hash byte +order][section hash byte order] for details. + A sample raw transaction is the first non-coinbase transaction, made in [block 170][block170]. To get the transaction, use the `getrawtransaction` RPC with that transaction's txid (provided below): @@ -145,7 +149,7 @@ that transaction's txid (provided below): {% endautocrossref %} ~~~ -> getrawtransaction \ +> bitcoin-cli getrawtransaction \ f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 0100000001c997a5e56e104102fa209c6a852dd90660a20b2d9c352423e\ diff --git a/_includes/references.md b/_includes/references.md index 1155fdb4..e40a40c8 100644 --- a/_includes/references.md +++ b/_includes/references.md @@ -1,5 +1,4 @@ [51 percent attack]: /en/developer-guide#term-51-attack "The ability of someone controlling a majority of hashing power to revise transactions history and prevent new transactions from confirming" -[accidental fork]: /en/developer-guide#term-accidental-fork "When two or more blocks have the same block height, forking the block chain. Happens occasionally by accident" [addresses]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address" [address]: /en/developer-guide#term-address "A 20-byte hash formatted as a P2PKH or P2SH Bitcoin Address" [base58Check]: /en/developer-reference#term-base58check "The method used in Bitcoin for converting 160-bit hashes into Bitcoin addresses" @@ -30,6 +29,8 @@ [confirmed transactions]: /en/developer-guide#term-confirmation "Transactions included in a block currently on the block chain" [confirmation]: /en/developer-guide#term-confirmation "The number of blocks which would need to be modified to remove or modify a transaction" [confirmations]: /en/developer-guide#term-confirmation "The number of blocks which would need to be modified to remove or modify a transaction" +[consensus]: /en/developer-guide#term-consensus "When several nodes (usually most nodes on the network) all have the same blocks in their locally-validated block chain." +[consensus rules]: /en/developer-guide#term-consensus-rules "The block validation rules that full nodes follow to stay in consensus with other nodes." [denomination]: /en/developer-guide#term-denomination "bitcoins (BTC), bitcents (cBTC), millibits (mBTC), microbits (uBTC), or satoshis" [difficulty]: /en/developer-guide#term-difficulty "A number corresponding to the target threshold which indicates how difficult it will be to find the next block" [double spend]: /en/developer-guide#term-double-spend "Attempting to spend the same satoshis which were spent in a previous transaction" @@ -38,7 +39,9 @@ [extended public key]: /en/developer-guide#term-extended-public-key "A public key extended with the chain code so that it can derive child public keys" [escrow contract]: /en/developer-guide#term-escrow-contract "A contract in which the spender and receiver store satoshis in a multisig output until both parties agree to release the satoshis" [fiat]: /en/developer-guide#term-fiat "National currencies such as the dollar or euro" +[fork]: /en/developer-guide#term-fork "When two or more blocks have the same block height, forking the block chain." [genesis block]: /en/developer-guide#term-genesis-block "The first block created; also called block 0" +[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" @@ -46,6 +49,7 @@ [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" [intermediate certificate]: /en/developer-examples#term-intermediate-certificate "A intermediate certificate authority certificate which helps connect a leaf (receiver) certificate to a root certificate authority" +[internal byte order]: /en/developer-reference#hash-byte-order "The standard order in which hash digests are displayed as strings---the same format used in blocks" [key index]: /en/developer-guide#term-key-index "An index number used in the HD wallet formula to generate child keys from a parent key" [key pair]: /en/developer-guide#term-key-pair "A private key and its derived public key" [label]: /en/developer-guide#term-label "The label parameter of a bitcoin: URI which provides the spender with the receiver's name (unauthenticated)" @@ -118,6 +122,7 @@ [regression test mode]: /en/developer-examples#regtest-mode "A local testing environment in which developers can control blocks" [root certificate]: /en/developer-examples#term-root-certificate "A certificate belonging to a certificate authority (CA)" [root seed]: /en/developer-guide#term-root-seed "A potentially-short value used as a seed to generate a master private key and master chain code for an HD wallet" +[RPC byte order]: /en/developer-reference#hash-byte-order "A hash digest displayed with the byte order reversed; used in Bitcoin Core RPCs and other software." [satoshi]: /en/developer-guide#term-satoshi "The smallest unit of Bitcoin value; 0.00000001 bitcoins. Also used generically for any value of bitcoins" [satoshis]: /en/developer-guide#term-satoshi "The smallest unit of Bitcoin value; 0.00000001 bitcoins. Also used generically for any value of bitcoins" [sequence number]: /en/developer-guide#term-sequence-number "A number intended to allow time locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction" @@ -132,6 +137,7 @@ [signature]: /en/developer-guide#term-signature "The result of combining a private key and some data in an ECDSA signature operation which allows anyone with the corresponding public key to verify the signature" [signature hash]: /en/developer-guide#term-signature-hash "A byte appended onto signatures generated in Bitcoin which allows the signer to specify what data was signed, allowing modification of the unsigned data" [signature script]: /en/developer-guide#term-signature-script "Data generated by a spender which is almost always used as variables to satisfy a pubkey script" +[soft fork]: /en/developer-guide#term-soft-fork "A temporary fork in the block chain which commonly occurs when miners using non-upgraded nodes violate a new consensus rule their nodes don't know about." [spv]: /en/developer-guide#simplified-payment-verification-spv "A method for verifying particular transactions were included in blocks without downloading the entire contents of the block chain" [ssl signature]: /en/developer-examples#term-ssl-signature "Signatures created and recognized by major SSL implementations such as OpenSSL" [stack]: /en/developer-guide#term-stack "An evaluation stack used in Bitcoin's script language" @@ -160,9 +166,13 @@ [X509Certificates]: /en/developer-examples#term-x509certificates [BFGMiner]: https://github.com/luke-jr/bfgminer +[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki [BIP21]: https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki +[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki [BIP32]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki +[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 [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 @@ -283,7 +293,9 @@ [RPCs]: /en/developer-reference#remote-procedure-calls-rpcs [secp256k1]: http://perso.univ-rennes1.fr/sylvain.duquesne/master/standards/sec2_final.pdf +[section hash byte order]: /en/developer-reference#hash-byte-order [section verifying payment]: /en/developer-guide#verifying-payment +[section detecting forks]: /en/developer-guide#detecting-forks [bitcoin URI subsection]: /en/developer-guide#bitcoin-uri [SHA256]: https://en.wikipedia.org/wiki/SHA-2 [Stratum mining protocol]: http://mining.bitcoin.cz/stratum-mining diff --git a/en/developer-reference.md b/en/developer-reference.md index 9ef2905e..01801548 100644 --- a/en/developer-reference.md +++ b/en/developer-reference.md @@ -37,6 +37,8 @@ title: "Developer Reference - Bitcoin" -- * https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) --> +{% include ref_core_rpc_intro.md %} + ### Remote Procedure Calls (RPCs) **Warning:** the block chain and memory pool can include arbitrary data diff --git a/img/dev/en-hard-fork.dot b/img/dev/en-hard-fork.dot new file mode 100644 index 00000000..b485f501 --- /dev/null +++ b/img/dev/en-hard-fork.dot @@ -0,0 +1,49 @@ +digraph { + +size=6.25; +rankdir=LR +//splines = ortho; +ranksep = 0.2; +nodesep = 0.1; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "box", fontname="Sans", label = "", width=0.3, height=0.3 ] +graph [ penwidth = 1.75, fontname="Sans" ] + +invis1 [ shape = "none", label = "Blocks\nFrom\nUpgraded\nNodes" ] +invis0 [ shape = "none", label = "Blocks\nFrom Non-\nUpgraded\nNodes" ]; + +subgraph cluster_honest { +block0 [ label = "Follows\nOld\nRules" ]; +block1 [ label = "Follows\nOld\nRules" ]; +block2_1 [ label = "Follows\nOld\nRules" ]; +block3_1 [ label = "Follows\nOld\nRules" ]; +//block2_1 -> block4 [ style = "invis", minlen = 2 ]; + + +style = "invis"; +} + + +subgraph cluster_attack { +block2 [ label = "Follows\nNew\nRules" ]; +block3 [ label = "Follows\nNew\nRules" ]; +block4 [ label = "Follows\nNew\nRules" ]; +block5 [ label = "Follows\nNew\nRules" ]; + +style = "invis" +} + + + +invis0 -> block0 [ minlen = 2, style = "dashed" ]; +block2_1 -> block3_1; + +block0 -> block1 -> block2 -> block3 -> block4 -> block5; + +block1 -> block2_1 + + + +label = "A Hard Fork: Non-Upgraded Nodes Reject The New Rules, Diverging The Chain" +} diff --git a/img/dev/en-hard-fork.png b/img/dev/en-hard-fork.png new file mode 100644 index 00000000..beb3a020 Binary files /dev/null and b/img/dev/en-hard-fork.png differ diff --git a/img/dev/en-hard-fork.svg b/img/dev/en-hard-fork.svg new file mode 100644 index 00000000..36a7bb6e --- /dev/null +++ b/img/dev/en-hard-fork.svg @@ -0,0 +1,128 @@ + + + + + + +_anonymous_0 + +A Hard Fork:  Non-Upgraded Nodes Reject The New Rules, Diverging The Chain +cluster_honest + +cluster_attack + + +invis1 +Blocks +From +Upgraded +Nodes + + +invis0 +Blocks +From Non- +Upgraded +Nodes + + +block0 + +Follows +Old +Rules + + +invis0->block0 + + + + +block1 + +Follows +Old +Rules + + +block0->block1 + + + + +block2_1 + +Follows +Old +Rules + + +block1->block2_1 + + + + +block2 + +Follows +New +Rules + + +block1->block2 + + + + +block3_1 + +Follows +Old +Rules + + +block2_1->block3_1 + + + + +block3 + +Follows +New +Rules + + +block2->block3 + + + + +block4 + +Follows +New +Rules + + +block3->block4 + + + + +block5 + +Follows +New +Rules + + +block4->block5 + + + + + diff --git a/img/dev/en-soft-fork.dot b/img/dev/en-soft-fork.dot new file mode 100644 index 00000000..830a4a9d --- /dev/null +++ b/img/dev/en-soft-fork.dot @@ -0,0 +1,47 @@ +digraph { + +size=6.25; +rankdir=LR +//splines = ortho; +ranksep = 0.2; +nodesep = 0.1; + +edge [ penwidth = 1.75, fontname="Sans" ] +node [ penwidth = 1.75, shape = "box", fontname="Sans", label = "", width=0.3, height=0.3 ] +graph [ penwidth = 1.75, fontname="Sans" ] + +invis1 [ shape = "none", label = "Blocks\nFrom\nUpgraded\nNodes" ] +invis0 [ shape = "none", label = "Blocks\nFrom Non-\nUpgraded\nNodes" ]; + +subgraph cluster_honest { +block0 [ label = "Follows\nOld\nRules" ]; +block1 [ label = "Follows\nOld\nRules" ]; +block2_1 [ label = "Follows Old Rules\nBut Violates\nNew Rules", style = "filled" ]; + +block2_1 -> block4 [ style = "invis", minlen = 2 ]; + +block4 [ label = "Follows\nOld\nRules" ]; + +style = "invis"; +} + + +subgraph cluster_attack { +block2 [ label = "Follows\nOld & New\nRules" ]; +block3 [ label = "Follows\nOld & New\nRules" ]; + +style = "invis" +} + + + +invis0 -> block0 [ minlen = 2, style = "dashed" ]; + +block0 -> block1 -> block2 -> block3 -> block4; + +block1 -> block2_1 + + + +label = "A Soft Fork: Blocks Violating New Rules Are Made Stale By The Upgraded Mining Majority" +} diff --git a/img/dev/en-soft-fork.png b/img/dev/en-soft-fork.png new file mode 100644 index 00000000..335c8300 Binary files /dev/null and b/img/dev/en-soft-fork.png differ diff --git a/img/dev/en-soft-fork.svg b/img/dev/en-soft-fork.svg new file mode 100644 index 00000000..48bc07f5 --- /dev/null +++ b/img/dev/en-soft-fork.svg @@ -0,0 +1,105 @@ + + + + + + +_anonymous_0 + +A Soft Fork:  Blocks Violating New Rules Are Made Stale By The Upgraded Mining Majority +cluster_honest + +cluster_attack + + +invis1 +Blocks +From +Upgraded +Nodes + + +invis0 +Blocks +From Non- +Upgraded +Nodes + + +block0 + +Follows +Old +Rules + + +invis0->block0 + + + + +block1 + +Follows +Old +Rules + + +block0->block1 + + + + +block2_1 + +Follows Old Rules +But Violates +New Rules + + +block1->block2_1 + + + + +block2 + +Follows +Old & New +Rules + + +block1->block2 + + + + +block4 + +Follows +Old +Rules + + + +block3 + +Follows +Old & New +Rules + + +block2->block3 + + + + +block3->block4 + + + + +