Block headersBlock headers - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work. are serialized in the 80-byte format described below and then hashed as part of the proof-of-work algorithm, making the serialized header format part of the consensus rulesconsensus rules - The block validation rules that full nodes follow to stay in consensus with other nodes..
|4||version||int32_t||The blockblock - One or more transactions prefaced by a block header and protected by proof of work. Blocks are the data stored on the block chain. version number indicates which set of block validation rules to follow. See the list of block versions below.|
|32||previous block header hash||char||An X11() 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||A SHA256(SHA256()) hash in internal byte order. The merkle root is derived from the hashes of all transactions included in this block, ensuring that none of those transactions can be modified without modifying the header. See the merkle trees section below.|
|4||time||uint32_t||The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than 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 less than or equal to 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.|
The hashes are in internal byte orderinternal byte order - The standard order in which hash digests are displayed as strings---the same format used in serialized blocks and transactions.; the other values are all in little-endian order.
An example headerheader - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work. in hex:
02000000 ........................... Block version: 2 b6ff0b1b1680a2862a30ca44d346d9e8 910d334beb48ca0c0000000000000000 ... Hash of previous block's header 9d10aa52ee949386ca9385695f04ede2 70dda20810decd12bc9b048aaab31471 ... Merkle root 24d95a54 ........................... Unix time: 1415239972 30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3) fe9f0864 ........................... Nonce
Version 1 was used by Dash for the genesis blockgenesis block - The first block in the Dash block chain. only.
Version 2 was introduced with the first block following the genesis blockgenesis block - The first block in the Dash block chain. (January 2014). As described in BIP34, valid version 2 blocks require a block heightblock height - The number of blocks preceding a particular block on a block chain. For example, the genesis block has a height of zero because zero block preceded it. parameter in the coinbase.
Version 3 blocks were introduced in Dash Core 0.11.2 (March 2015) as a
soft fork (Block 244,834 was the first version 3 block).
When the forkfork - When two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack. reached full enforcement, it required strict DER encoding of all ECDSA signaturesECDSA signatures - A value related to a public key which could only have reasonably been created by someone who has the private key that created that public key. Used in Dash to authorize spending duffs previously sent to a public key. in new blocks as described in BIP66. Transactions that do not use strict DER encoding had previously been non-standard since Dash Core 0.8.0.
Version 4 blocks specified in BIP65 and introduced in Bitcoin Core 0.11.2 (November 2015) as a soft forksoft fork - A softfork is a change to the dash protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognise the new blocks as valid, a softfork is backward-compatible. became active in December 2015. These blocks now support the new
OP_CHECKLOCKTIMEVERIFYopcodeopcode - Operation codes from the Dash Script language which push data or perform functions within a pubkey script or signature script. described in that BIP.
The mechanism used for the version 2, 3, and 4 upgrades is commonly called IsSuperMajority() after the function added to Dash Core to manage those soft forking changes. See BIP34 for a full description of this method.
As of this writing, a newer method called version bits is being designed to manage future soft forking changes, although it's not known whether version 4 will be the last soft fork to use the IsSuperMajority() function. Draft BIP9 describes the version bits design as of this writing, although it is still being actively edited and may substantially change while in the draft state.
The merkle rootmerkle root - The root node of a merkle tree, a descendant of all the hashed pairs in the tree. Block headers must include a valid merkle root descended from all transactions in that block. is constructed using all the TXIDsTXIDs - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction. of transactions in this block, but first the TXIDs are placed in order as required by the consensus rulesconsensus rules - The block validation rules that full nodes follow to stay in consensus with other nodes.:
The coinbase transactioncoinbase transaction - The first transaction in a block. Always created by a miner, it includes a single coinbase.'s TXIDTXID - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction. is always placed first.
Any inputinput - An input in a transaction which contains three fields: an outpoint, a signature script, and a sequence number. The outpoint references a previous output and the signature script allows spending it. within this block can spend an outputoutput - An output in a transaction which contains two fields: a value field for transferring zero or more duffs and a pubkey script for indicating what conditions must be fulfilled for those duffs to be further spent. 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 blockblock - One or more transactions prefaced by a block header and protected by proof of work. Blocks are the data stored on the block chain. 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 treemerkle tree - A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In Dash, the leaves are almost always transactions from a single block. 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 orderinternal byte order - The standard order in which hash digests are displayed as strings---the same format used in serialized blocks and transactions. when they're concatenated, and the resulting merkle root is also in internal byte order when it's placed in the block headerblock header - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work..
The target thresholdtarget threshold - The target is the threshold below which a block header hash must be in order for the block to be valid, and nBits is the encoded form of the target threshold as it appears in the block header. is a 256-bit unsigned integer which a headerheader - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work. hash must be equal to or below in order for that header to be a valid part of the block chainblock chain - A chain of blocks with each block referencing the block that preceded it. The most-difficult-to-recreate chain is the best block chain.. However, the header field nBitsnBits - The target is the threshold below which a block header hash must be in order for the block to be valid, and nBits is the encoded form of the target threshold as it appears in the block header. provides only 32 bits of space, so the targettarget - The target is the threshold below which a block header hash must be in order for the block to valid, and nBits is the encoded form of the target threshold as it appears in the block header. 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. Dash Core deals with this in two ways:
When parsing nBits, Dash 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, Dash 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 Dash Core test cases:
|0x04923456||-0x12345600||High bit set (0x80 in 0x92).|
|0x04123456||0x12345600||Inverse of above; no high bit.|
Difficulty 1, the minimum allowed difficultydifficulty - How difficult it is to find a block relative to the difficulty of finding the easiest possible block. The easiest possible block has a proof-of-work difficulty of 1., is represented on mainnetmainnet - The original and main network for Dash transactions, where duffs have real economic value. and the current testnettestnet - A global testing environment in which developers can obtain and spend duffs that have no real-world value on a network that is very similar to the Dash mainnet. by the nBits value 0x1e0ffff0. 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 regression test moderegression test mode - A local testing environment in which developers can almost instantly generate blocks on demand for testing events, and can create private duffs with no real-world value..
Updated over 1 year ago