Raw Transaction Format

Dash transactions are broadcast between peerspeers - A computer that connects to the Dash network. in a serialized byte format, called raw formatraw format - 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.. It is this form of a transaction which is SHA256(SHA256()) hashed to create the TXIDTXID - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction. and, ultimately, 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. of 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. containing the transaction---making the transaction format part of the consensus rulesconsensus rules - The block validation rules that full nodes follow to stay in consensus with other nodes..

Dash Core and many other tools print and accept raw transactionsraw transactions - 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. encoded as hex.

Transactions prior to protocol version 70209 defaulted to version 1. Transaction version 2 was the default in protocol versions => 70209 and < 70213. Version 2 transactions have the same format, but the lock_time parameter was redefined by BIP68 to enable relative lock-times. (Note: transactions in 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. are allowed to list a higher version number to permit soft forkssoft forks - 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., but they are treated as version 2 transactions by current software.)

Dash Core 0.13.0 (protocol version 70213) introduced transaction version 3 as part of the DIP2 - Special Transactions implementation. Details of the changes introduced by this feature and currently implemented special transactionsspecial transactions - Special Transactions provide a way to include non-financial, consensus-assisting metadata (e.g. masternode lists) on-chain. can be found in the Special Transactions section below as well as in the DIP.

A raw transaction has the following top-level format:

BytesNameData TypeDescription
2versionuint16_tConverted from 4 bytes to 2 bytes by DIP2 in v0.13.0

Transaction version number; currently version 3. Programs creating transactions using newer consensus rules may use higher version numbers.
2typeuint16_tAdded by DIP2 in v0.13.0. Uses 2 bytes that were previously part of version

Transaction type number; 0 for classical transactions; Non-zero for DIP2 special transactions.
Variestx_in countcompactSize uintNumber of inputs in this transaction.
Variestx_intxInTransaction inputs. See description of txIn below.
Variestx_out countcompactSize uintNumber of outputs in this transaction.
Variestx_outtxOutTransaction outputs. See description of txOut below.
4lock_timeuint32_tA time (Unix epoch time) or block number. See the locktime parsing rules.
Variesextra_payload sizecompactSize uintAdded by DIP2 in v0.13.0

Variable number of bytes of extra payload for DIP2-based special transactions
Variesextra_payloadblobAdded by DIP2 in v0.13.0

Special transaction payload.

A transaction may have multiple inputsinputs - 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. and outputsoutputs - 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., so the txIn and txOut structures may recur within a transaction. CompactSize unsigned integersCompactSize unsigned integers - A type of variable-length integer commonly used in the Dash P2P protocol and Dash serialized data structures. are a form of variable-length integers; they are described in the CompactSize section.

JSON-RPC Responses

When retrieving transaction data via Dash Core RPCs (e.g. the getrawtransaction RPC), the transaction data is returned in the following format.

Version 1 and 2 Transaction Structure (prior to DIP2 activation in Dash Core v0.13.0):

{
  "txid": <string>,
  "size": <int>,
  "version": 2,
  "locktime": 0,
  "vin": [ ],
  "vout": [ ]
}

Version 3 Transaction Structure (Dash Core v0.13.0+ and activated DIP2):

{
  "txid": <string>,
  "size": <int>,
  "version": 3,
  "type": <int>,
  "locktime": 0,
  "vin": [ ],
  "vout": [ ],
  "extraPayloadSize": <variable int>,
  "extraPayload": …
}

For special transactionsspecial transactions - Special Transactions provide a way to include non-financial, consensus-assisting metadata (e.g. masternode lists) on-chain. (those using the extraPayload fields), JSON-RPC responses contain a parsed JSON representation of the Transaction Payload.

The sample transaction below shows the response for a quorum commitment special transaction:

{
  "txid": "592a09d08348d970b4d9ba216246a23dac866717b460d3f369a86293b9839eea",
  "size": 342,
  "version": 3,
  "type": 6,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
  ],
  "extraPayloadSize": 329,
  "extraPayload": "0100841b0000010001211cd3e4230b2bc47530e200447e998a38e960d4ed5f5251e26892130c000000320000000000000032000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "qcTx": {
    "version": 1,
    "height": 7044,
    "commitment": {
      "version": 1,
      "llmqType": 1,
      "quorumHash": "0000000c139268e251525fedd460e9388a997e4400e23075c42b0b23e4d31c21",
      "signersCount": 0,
      "validMembersCount": 0,
      "quorumPublicKey": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    }
  },
  "instantlock": false
}

TxIn: A Transaction Input (Non-Coinbase)

Each non- coinbasecoinbase - A special field used as the sole input for coinbase transactions. The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data. 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. spends an outpoint from a previous transaction. (Coinbase inputs are described separately after the example section below.)

BytesNameData TypeDescription
36previous_outputoutpointoutpoint - The data structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout).The previous outpoint being spent. See description of outpoint below.
Variesscript bytescompactSize uintThe number of bytes in the signature script. Maximum is 10,000 bytes.
Variessignature scriptchar[]A script-language script which satisfies the conditions placed in the outpoint's pubkey script. Should only contain data pushes; see the signature script modification warning.
4sequenceuint32_tSequence number. Default for Dash Core and almost all other programs is 0xffffffff.

Outpoint: The Specific Part Of A Specific Output

Because a single transaction can include multiple outputsoutputs - 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., the outpointoutpoint - The data structure used to refer to a particular transaction output, consisting of a 32-byte TXID and a 4-byte output index number (vout). structure includes both a TXIDTXID - An identifier used to uniquely identify a particular transaction; specifically, the sha256d hash of the transaction. and an output index number to refer to specific output.

BytesNameData TypeDescription
32hashchar[32]The TXID of the transaction holding the output to spend. The TXID is a hash provided here in internal byte order.
4indexuint32_tThe output index number of the specific output to spend from the transaction. The first output is 0x00000000.

TxOut: A Transaction Output

Each 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. spends a certain number of duffsduffs - Denominations of Dash value, usually measured in fractions of a dash but sometimes measured in multiples of a duff. One dash equals 100,000,000 duffs., placing them under control of anyone who can satisfy the provided pubkey scriptpubkey script - A script included in outputs which sets the conditions that must be fulfilled for those duffs to be spent. Data for fulfilling the conditions can be provided in a signature script. Pubkey Scripts are called a scriptPubKey in code..

BytesNameData TypeDescription
8valueint64_tNumber of duffs to spend. May be zero; the sum of all outputs may not exceed the sum of duffs previously spent to the outpoints provided in the input section. (Exception: coinbase transactions spend the block subsidy and collected transaction fees.)
1+pk_script bytescompactSize uintNumber of bytes in the pubkey script. Maximum is 10,000 bytes.
Variespk_scriptchar[]Defines the conditions which must be satisfied to spend this output.

Example

The sample raw transaction itemized below is the one created in the Simple Raw Transaction section of the Developer Examples. It spends a previous pay-to-pubkey output by paying to a new pay-to-pubkey-hash (P2PKH) output.

01000000 ................................... Version

01 ......................................... Number of inputs
|
| 7b1eabe0209b1fe794124575ef807057
| c77ada2138ae4fa8d6c4de0398a14f3f ......... Outpoint TXID
| 00000000 ................................. Outpoint index number: 0
|
| 49 ....................................... Bytes in sig. script: 73
| | 48 ..................................... Push 72 bytes as data
| | | 30450221008949f0cb400094ad2b5eb3
| | | 99d59d01c14d73d8fe6e96df1a7150de
| | | b388ab8935022079656090d7f6bac4c9
| | | a94e0aad311a4268e082a725f8aeae05
| | | 73fb12ff866a5f01 ..................... Secp256k1 signature
|
| ffffffff ................................. Sequence number: UINT32_MAX

01 ......................................... Number of outputs
| f0ca052a01000000 ......................... Duffs (49.99990000 Dash)
|
| 19 ....................................... Bytes in pubkey script: 25
| | 76 ..................................... OP_DUP
| | a9 ..................................... OP_HASH160
| | 14 ..................................... Push 20 bytes as data
| | | cbc20a7664f2f69e5355aa427045bc15
| | | e7c6c772 ............................. PubKey hash
| | 88 ..................................... OP_EQUALVERIFY
| | ac ..................................... OP_CHECKSIG

00000000 ................................... locktime: 0 (a block height)

Coinbase Input: The Input Of The First Transaction In A Block

The first transaction in 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., called the coinbase transactioncoinbase transaction - The first transaction in a block. Always created by a miner, it includes a single coinbase., must have exactly one input, called a coinbasecoinbase - A special field used as the sole input for coinbase transactions. The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.. The coinbase 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. currently has the following format.

BytesNameData TypeDescription
32hash (null)char[32]A 32-byte null, as a coinbase has no previous outpoint.
4index (UINT32_MAX)uint32_t0xffffffff, as a coinbase has no previous outpoint.
Variesscript bytescompactSize uintThe number of bytes in the coinbase script, up to a maximum of 100 bytes.
Varies (4)heightscriptThe 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. of this block as required by BIP34. Uses script language: starts with a data-pushing opcode 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 opcode will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
Variescoinbase scriptNoneThe coinbase fieldcoinbase field - A special field used as the sole input for coinbase transactions. The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.: 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.
4sequenceuint32_tSequence number.

Although the coinbase script is arbitrary data, if it includes the bytes used by any signature-checking operations such as OP_CHECKSIG, those signature checks will be counted as signature operations (sigops) towards the block's sigop limit. To avoid this, you can prefix all data with the appropriate push operation.

An itemized coinbase transactioncoinbase transaction - The first transaction in a block. Always created by a miner, it includes a single coinbase.:

01000000 .............................. Version

01 .................................... Number of inputs
| 00000000000000000000000000000000
| 00000000000000000000000000000000 ...  Previous outpoint TXID
| ffffffff ............................ Previous outpoint index
|
| 18 .................................. Bytes in coinbase: 24
| |
| | 03 ................................ Bytes in height
| | | b8240b .......................... Height: 730296
| |
| | 03b8240b049d29aa59080400077efa95
| | 0000052f6d70682f .................. Arbitrary data
| 00000000 ............................ Sequence

02 .................................... Output count
| Transaction Output 1
| | f20cbe0a00000000 .................... Duffs (1.80227314 Dash)
| | 1976a9142cd46be3ceeacca983e0fea3
| | b88f26b08a26c29b88ac ................ P2PKH script
|
| Transaction Output 2
| | eb0cbe0a00000000 .................... Duffs (1.80227307 Dash)
| | 1976a914868180414905937a68fadeb0
| | f33e64d102c9591a88ac ................ P2PKH script
|
| 00000000 ............................ Locktime

Note: currently the normal coinbase has 2 outputs (1 for the 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. and 1 for the selected masternodemasternode - A computer that provides second-tier Dash functionality (InstantSend, PrivateSend, decentralized governance). Masternodes are incentivized by receiving part of the block reward, but must hold 1000 Dash as collateral to prevent sybil attacks.). Superblocks (superblock example) have multiple outputs depending on the number of proposals being funded.


Did this page help you?