Transaction Data

Every 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. must include one or more transactionstransactions - A transaction spending satoshis.. The first one of these transactions must be a coinbase transactioncoinbase transaction - The first transaction in a block. Always created by a miner, it includes a single coinbase., also called a generation transaction, which should collect and spend the block rewardblock reward - The amount that miners may claim as a reward for creating a block. Equal to the sum of the block subsidy (newly available duffs) plus the transactions fees paid by transactions included in the block. (comprised of a block subsidy and any transaction fees paid by transactions included in this block).

The UTXO of a coinbase transaction has the special condition that it cannot be spent (used as an input) for at least 100 blocks. This temporarily prevents a minerminer - Mining is the act of creating valid Dash blocks, which requires demonstrating proof of work, and miners are devices that mine or people who own those devices. from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain 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..

Blocks are not required to include any non-coinbase transactions, but miners almost always do include additional transactions in order to collect their transaction fees.

All transactions, including the coinbase transaction, are encoded into blocks in binary raw transactionraw transaction - Complete transactions in their binary format; often represented using hexadecimal. Sometimes called raw format because of the various Dash Core commands with "raw" in their names. format.

The rawtransaction format is hashed to create the transaction identifier (TXIDTXID - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction.). From these txids, the 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. is constructed by pairing each txid with one other txid and then hashing them together. If there are an odd number of txids, the txid without a partner is hashed with a copy of itself.

The resulting hashes themselves are each paired with one other hash and hashed together. Any hash without a partner is hashed with itself. The process repeats until only one hash remains, 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..

For example, if transactions were merely joined (not hashed), a five-transaction merkle tree would look like the following text diagram:

       ABCDEEEE .......Merkle root
      /        \
   ABCD        EEEE
  /    \      /
 AB    CD    EE .......E is paired with itself
/  \  /  \  /
A  B  C  D  E .........Transactions

As discussed in the Simplified Payment VerificationSimplified Payment Verification - A method for verifying if particular transactions are included in a block without downloading the entire block. The method is used by some lightweight clients. (SPV) subsection, the merkle tree allows clients to verify for themselves that a transaction was included in a block by obtaining the merkle root from a block headerblock header - An 80-byte header belonging to a single block which is hashed repeatedly to create proof of work. and a list of the intermediate hashes from a full peerpeer - A computer that connects to the Dash network.. The full peer does not need to be trusted: it is expensive to fake block headers and the intermediate hashes cannot be faked or the verification will fail.

For example, to verify transaction D was added to the block, an SPV client only needs a copy of the C, AB, and EEEE hashes in addition to the merkle root; the client doesn't need to know anything about any of the other transactions. If the five transactions in this block were all at the maximum size, downloading the entire block would require over 500,000 bytes---but downloading three hashes plus the block header requires only 140 bytes.

Note: If identical txids are found within the same block, there is a possibility that the merkle tree may collide with a block with some or all duplicates removed due to how unbalanced merkle trees are implemented (duplicating the lone hash). Since it is impractical to have separate transactions with identical txids, this does not impose a burden on honest software, but must be checked if the invalid status of a block is to be cached; 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.


Did this page help you?