Special Transactions

The Special TransactionsSpecial Transactions - Special Transactions provide a way to include non-financial, consensus-assisting metadata (e.g. masternode lists) on-chain. framework established by DIP2 enabled the implementation of new on-chain features and consensusconsensus - When several nodes (usually most nodes on the network) all have the same blocks in their locally-validated best block chain. mechanisms. These transactions provide the flexibility to expand beyond the financial uses of classical transactions. DIP2 transactions modified classical transactions by:

  1. Splitting the 32 bit version field into two 16 bit fields (version and type)
  2. Adding support for a generic extra payload following the lock_time field. The maximum allowed size for a transaction version 3 extra payload is 10000 bytes (MAX_TX_EXTRA_PAYLOAD).

Classical (financial) transactions have a type of 0 while special transactions have a type defined in the DIP describing them. A list of current special transaction types is maintained in the DIP repository.

Implemented Special Transactions

ReleaseTx VersionTx TypePayload JSONTx PurposePayload
v0.12.32-n/an/an/a
v0.13.030n/aStandard (Classical) Transactionn/a
v0.13.031ProRegTxMasternode Registrationhex
v0.13.032ProUpServTxUpdate Masternode Servicehex
v0.13.033ProUpRegTxUpdate Masternode Operatorhex
v0.13.034ProUpRevTxMasternode Operator Revocationhex
v0.13.035CbTxMasternode List Merkle Proofhex
v0.13.036QcTxLong-Living Masternode Quorum Commitmenthex

ProRegTx

Added in protocol version 70213 of Dash Core as described by DIP3

The 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. Registration (ProRegTx) special transaction is used to join the masternode list by proving ownership of the 1000 DASH necessary to create a masternode.

A ProRegTx is created and sent using the protx RPC. The ProRegTx must either include 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. with 1000 DASH (protx register) or refer to an existing unspent output holding 1000 DASH (protx fund_register). If the 1000 DASH is an output of the ProRegTx, the collateralOutpoint hash field should be null.

The special transaction type is 1 and the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16Provider transaction version number. Currently set to 1.
2typeuint_16Masternode type. Default set to 0.
2modeuint_16Masternode mode. Default set to 0.
36collateralOutpointCOutpointThe collateral outpoint.
Note: The hash will be null if the collateral is part of this transaction, otherwise it will reference an existing collateral.
16ipAddressbyte[]IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future)
2portuint_16Port (network byte order)
20KeyIdOwnerCKeyIDThe public key hash used for owner related signing (ProTx updates, governance voting)
48PubKeyOperatorCBLSPublicKeyThe BLS public key used for operational related signing (network messages, ProTx updates)
20KeyIdVotingCKeyIDThe public key hash used for voting.
2operatorRewarduint_16A value from 0 to 10000.
1-9scriptPayoutSizecompactSize uintSize of the Payee Script.
VariablescriptPayoutScriptPayee script (p2pkh/p2sh)
32inputsHashuint256Hash of all the outpoints of the transaction inputs
1-9payloadSigSizecompactSize uintSize of the Signature
VariablepayloadSigvectorSignature of the hash of the ProTx fields. Signed with the key corresponding to the collateral outpoint in case the collateral is not part of the ProRegTx itself, empty otherwise.

The following annotated hexdump shows a ProRegTx transaction referencing an existing collateral. (Parts of the classical transaction section have been omitted.)

0300 ....................................... Version (3)
0100 ....................................... Type (1 - ProRegTx)

[...] ...................................... Transaction inputs omitted
[...] ...................................... Transaction outputs omitted

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

fd1201 ..................................... Extra payload size (274)

ProRegTx Payload
| 0100 ..................................... Version (1)
| 0000 ..................................... Type (0)
| 0000 ..................................... Mode (0)
|
| 4859747b0eb19bb2dae5a12ef7b6a69b
| 03712bfeded1174de0b6ab1334ab2e8b ......... Outpoint TXID
| 01000000 ................................. Outpoint index number: 1
|
| 00000000000000000000ffffc0000233 ......... IP Address: ::ffff:192.0.2.51
| 270f ..................................... Port: 9999
|
|
| 1636e84d02310b0b458f3eb51d8ea8b2e684b7ce . Owner pubkey hash (ECDSA)
| 88d719278eef605d9c19037366910b59bc28d437
| de4a8db4d76fda6d6985dbdf10404fb9bb5cd0e8
| c22f4a914a6c5566 ......................... Operator public key (BLS)
| 1636e84d02310b0b458f3eb51d8ea8b2e684b7ce . Voting pubkey hash (ECDSA)
|
| f401 ..................................... Operator reward (500 -> 5%)
|
| Payout script
| 19 ....................................... Bytes in pubkey script: 25
| | 76 ..................................... OP_DUP
| | a9 ..................................... OP_HASH160
| | 14 ..................................... Push 20 bytes as data
| | | fc136008111fcc7a05be6cec66f97568
| | | 727a9e51 ............................. PubKey hash
| | 88 ..................................... OP_EQUALVERIFY
| | ac ..................................... OP_CHECKSIG
|
| 0fcfb7d939078ba6a6b81ecf1dc2e05d
| e2776f49f7b503ac254798be6a672699 ......... Inputs hash
|
| Payload signature
| 41 ....................................... Signature Size (65)
| 200476f193b465764093014ba44bd4ff
| de2b3fc92794c4acda9cad6305ca172e
| 9e3d6b1cd6e30f86678dae8e6595e53d
| 2b30bc32141b6c0151eb58479121b3e6a4 ....... Signature

The following annotated hexdump shows a ProRegTx transaction creating a new collateral.

Note the presence of the output, a null Outpoint TXID and the absence of a signature (since it isn't referring to an existing collateral). (Parts of the classical transaction section have been omitted.)

0300 ....................................... Version (3)
0100 ....................................... Type (1 - ProRegTx)

[...] ...................................... Transaction inputs omitted

02 ......................................... Number of outputs
| [...] .................................... 1 output omitted
|
| Masternode collateral output
| | 00e8764817000000 ....................... Duffs (1000 DASH)
| | 1976a9149e648c7e4b61482aa3
| | 9bd10e0bf0b5268768005f88ac ............. Script

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

d1 ......................................... Extra payload size (209)

ProRegTx Payload
| 0100 ..................................... Version (1)
| 0000 ..................................... Type (0)
| 0000 ..................................... Mode (0)
|
| 00000000000000000000000000000000
| 00000000000000000000000000000000 ......... Outpoint TXID
| 01000000 ................................. Outpoint index number: 1
|
| 00000000000000000000ffffc0000233 ......... IP Address: ::ffff:192.0.2.51
| 270f ..................................... Port: 9999
|
| 757a2171bbf92517e358249f20c37a8ad2d7a5bc . Owner pubkey hash (ECDSA)
| 0e02146e9c34cfbcb3f3037574a1abb35525e2ca
| 0c3c6901dbf82ac591e30218d1711223b7ca956e
| df39f3d984d06d51 ......................... Operator public key (BLS)
| 757a2171bbf92517e358249f20c37a8ad2d7a5bc . Voting pubkey hash (ECDSA)
|
| f401 ..................................... Operator reward (500 -> 5%)
|
| Payout script
| 19 ....................................... Bytes in pubkey script: 25
| | 76 ..................................... OP_DUP
| | a9 ..................................... OP_HASH160
| | 14 ..................................... Push 20 bytes as data
| | | 9e648c7e4b61482aa39bd10e0bf0b526
| | | 8768005f ............................. PubKey hash
| | 88 ..................................... OP_EQUALVERIFY
| | ac ..................................... OP_CHECKSIG
|
| 57b115d681b9aff82824ff7e22af99d4
| ac4b39ad7be7cb70b662e9011827d589 ......... Inputs hash
|
| Payload signature
| 00 ....................................... Signature Size (0)
| .......................................... Signature (Empty)

ProUpServTx

Added in protocol version 70213 of Dash Core as described by DIP3

The 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. Provider Update Service (ProUpServTx) special transaction is used to update the IP Address and port of a masternode. If a non-zero operatorReward was set in the initial ProRegTx, the operator may also set the scriptOperatorPayout field in the ProUpServTx.

A ProUpServTx is only valid for masternodes in the registered masternodes subset. When processed, it updates the metadata of the masternode entry and revives the masternode if it was previously marked as PoSe-banned.

A ProUpServTx is created and sent using the protx update_service RPC.

The special transaction type used for ProUpServTx Transactions is 2 and the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16ProUpServTx version number. Currently set to 1.
32proTXHashuint256The hash of the initial ProRegTx
16ipAddressbyte[]IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future)
2portuint_16Port (network byte order)
1-9scriptOperator
PayoutSize
compactSize uintSize of the Operator Payee Script.
VariablescriptOperator
Payout
ScriptOperator Payee script (p2pkh/p2sh)
32inputsHashuint256Hash of all the outpoints of the transaction inputs
1-9payloadSigSizecompactSize uintSize of the Signature
Note: not present in BLS implementation
96payloadSigvectorBLS Signature of the hash of the ProUpServTx fields. Signed by the Operator.

The following annotated hexdump shows a ProUpServTx transaction. (Parts of the
classical transaction section have been omitted.)

0300 ....................................... Version (3)
0200 ....................................... Type (2 - ProUpServTx)

[...] ...................................... Transaction inputs omitted
[...] ...................................... Transaction outputs omitted

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

b5 ......................................... Extra payload size (181)

ProUpServTx Payload
| 0100 ..................................... Version (1)
|
| db60b8cecae691a3d078a2341d460b06
| b2914f6b092f1906b5c815589399b0ff ......... ProRegTx Hash
|
| 00000000000000000000ffffc0000233 ......... IP Address: ::ffff:192.0.2.51
| 270f ..................................... Port: 9999
|
| 00 ....................................... Operator payout script size (0)
| .......................................... Operator payout script (Empty)
|
| a9569d037b0eacc8bca05c5829c95283
| 4ac27d1c7e7df610500b7ba70fd46507 ......... Inputs hash
|
| Payload signature (BLS)
| 0267702ef85d186ef7fa32dc40c65f2f
| eca0a7465715eb7c30f81beb69e35ee4
| 1f6ff7f292b82a9caebb5aa961b0f915
| 02501becf629e93c0a01c76162d56a6c
| 65a9675c3ca9d5297f053e68f91393dd
| 789beed8ef7e8839695a334c2e1bd37c ......... BLS Signature (96 bytes)

ProUpRegTx

Added in protocol version 70213 of Dash Core as described by DIP3

The 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. Provider Update Registrar (ProUpRegTx) special transaction is used by a masternode owner to update masternode metadata (e.g. operator/voting key details or the payout script).

A ProUpRegTx is created and sent using the protx update_registrar RPC.

The special transaction type is 3 and the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16Provider update registrar transaction version number. Currently set to 1.
32proTXHashuint256The hash of the initial ProRegTx
2modeuint_16Masternode mode. Default set to 0.
48PubKeyOperatorCBLSPublicKeyThe BLS public key used for operational related signing (network messages, ProTx updates)
20KeyIdVotingCKeyIDThe public key hash used for voting.
1-9scriptPayoutSizecompactSize uintSize of the Payee Script.
VariablescriptPayoutScriptPayee script (p2pkh/p2sh)
32inputsHashuint256Hash of all the outpoints of the transaction inputs
1-9payloadSigSizecompactSize uintSize of the Signature
VariablepayloadSigvectorSignature of the hash of the ProTx fields. Signed with the key corresponding to the collateral outpoint in case the collateral is not part of the ProRegTx itself, empty otherwise.

The following annotated hexdump shows a ProUpRegTx transaction referencing an
existing collateral. (Parts of the classical transaction section have been omitted.)

0300 ....................................... Version (3)
0300 ....................................... Type (3 - ProUpRegTx)

[...] ...................................... Transaction inputs omitted
[...] ...................................... Transaction outputs omitted

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

e4 ......................................... Extra payload size (228)

ProRegTx Payload
| 0100 ..................................... Version (1)
|
| ddaf13bf1b02de39711de911e646c63e
| f089b6cee786a1b776086ae130331bba ......... ProRegTx Hash
|
| 0000 ..................................... Mode (0)
|
| 0e02146e9c34cfbcb3f3037574a1abb35525e2ca
| 0c3c6901dbf82ac591e30218d1711223b7ca956e
| df39f3d984d06d51 ......................... Operator public key (BLS)
| 757a2171bbf92517e358249f20c37a8ad2d7a5bc . Voting pubkey hash (ECDSA)
|
| Payout script
| 19 ....................................... Bytes in pubkey script: 25
| | 76 ..................................... OP_DUP
| | a9 ..................................... OP_HASH160
| | 14 ..................................... Push 20 bytes as data
| | | 9e648c7e4b61482aa39bd10e0bf0b526
| | | 8768005f ............................. PubKey hash
| | 88 ..................................... OP_EQUALVERIFY
| | ac ..................................... OP_CHECKSIG
|
| 50b50b24193b2b16f0383125c1f4426e
| 883d256eeadee96d500f8c08b0e0f9e4 ......... Inputs hash
|
| Payload signature
| 41 ....................................... Signature Size (65)
| 1ffa8a27ae0301e414176d4c876cff2e
| 20b810683a68ab7dcea95de1f8f36441
| 4c56368f189a3ef7a59b83bd77f22431
| a73d347841a58768b94c771819dc2bbce3 ....... Signature

ProUpRevTx

Added in protocol version 70213 of Dash Core as described by DIP3

The 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. Operator Revocation (ProUpRevTx) special transaction allows an operator to revoke their key in case of compromise or if they wish to terminate service. If a masternode's operator key is revoked, the masternode becomes ineligible for payment until the owner provides a new operator key (via a ProUpRegTx).

A ProUpRevTx is created and sent using the protx revoke RPC.

The special transaction type used for ProUpServTx Transactions is 4 and the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16ProUpRevTx version number. Currently set to 1.
32proTXHashuint256The hash of the initial ProRegTx
2reasonuint_16The reason for revoking the key.
0 - Not specified
1 - Termination of Service
2 - Compromised Key
3 - Change of key
32inputsHashuint256Hash of all the outpoints of the transaction inputs
1-9payloadSigSizecompactSize uintSize of the Signature
Note: not present in BLS implementation
96payloadSigvectorBLS Signature of the hash of the ProUpServTx fields. Signed by the Operator.

The following annotated hexdump shows a ProUpRevTx transaction. (Parts of the classical transaction section have been omitted.)

0300 ....................................... Version (3)
0400 ....................................... Type (4 - ProUpRevTx)

[...] ...................................... Transaction inputs omitted
[...] ...................................... Transaction outputs omitted

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

a4 ......................................... Extra payload size (164)

ProUpRevTx Payload
| 0100 ..................................... Version (1)
|
| ddaf13bf1b02de39711de911e646c63e
| f089b6cee786a1b776086ae130331bba ......... ProRegTx Hash
|
| 0000 ..................................... Reason: 0 (Not specified)
|
| cb0dfe113c87f8e9cde2c5d18aae12fc
| 8d0617c42c34ca5c2f2f6ab4b1dae164 ......... Inputs hash
|
| Payload signature (BLS)
| 0adaef4bf1a904308f1b0efbdfaffc93
| 864f9e047fd83415c831589180303711
| 0f0d8adb312ab43ddd7f8086042d3f5b
| 09029a6a16c341c9d2a62789b495fef4
| e068da711dac28106ff354db7249ae88
| 05877d82ff7d1af00ae2d303dea5eb3b ......... BLS Signature (96 bytes)

CbTx

Added in protocol version 70213 of Dash Core as described by DIP4

The Coinbase (CbTx) special transaction adds information to 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. coinbase transactioncoinbase transaction - The first transaction in a block. Always created by a miner, it includes a single coinbase. that enables verification of the deterministic masternode list without the full chain (e.g. from SPVSPV - 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. clients). This allows light-clients to properly verify InstantSendInstantSend - InstantSend is a service that allows for near-instant transactions. Through this system, inputs can be locked to specific transactions and verified by consensus of the masternode network. transactions and support additional deterministic masternode list functionality in the future.

The special transaction type used for CbTx Transactions is 5 and the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16CbTx version number. Currently set to 1.
4heightuint32_tHeight of the block
32merkleRootMNListuint256Merkle root of the masternode list
32merkleRootQuorumsuint256Added by CbTx version 2 in v0.14.0

Merkle root of currently active LLMQs

Version History

CbTx VersionFirst Supported Protocol VersionDash Core VersionNotes
1702130.13.0Enabled by activation of DIP3
2702140.14.0Enabled by activation of DIP8

The following annotated hexdump shows a CbTx transaction.

An itemized coinbase transaction:

0300 ....................................... Version (3)
0500 ....................................... Type (5 - Coinbase)

01 ......................................... Number of inputs
| 00000000000000000000000000000000
| 00000000000000000000000000000000 ......... Previous outpoint TXID
| ffffffff ................................. Previous outpoint index
|
| 4c ....................................... Bytes in coinbase: 76
| |
| | 03 ..................................... Bytes in height
| | | 393d01 ............................... Height: 81209
| |
| | 04b9...6d2f ............................ Arbitrary data (truncated)
| 00000000 ................................. Sequence

02 ......................................... Output count
| Transaction Output 1
| | 40230e4300000000 ....................... Duffs (11.25 DASH)
| | 1976a914b7ce0ea9ce2010f58ba4aaa6
| | caa76671c438e89088ac ................... Script
|
| Transaction Output 2
| | 40230e4300000000 ....................... Duffs (11.25 DASH)
| | 1976a91405ea03a6c9dfa67e1837b3c1
| | 4965ba3cb53bce7288ac ................... P2PKH script

00000000 ................................... Locktime

46 ......................................... Extra payload size (38)

Coinbase Transaction Payload
| 0200 ..................................... Version (2)
|
| 393d0100 ................................. Block height: 81209
|
| e2dd012c5b0b1753cef0e32f978917ef
| e7a484c5080b31b4e3f966ccc0e0f8dd ......... MN List merkle root
|
| 2ef709f55fa42cb53d29d75dad77d212
| fb0bd72a47ecfe0e8aa6f660fb96396e ......... Active LLMQ merkle root

QcTx

Added in protocol version 70213 of Dash Core as described by DIP6

🚧

Note

This special transaction has no inputs and no outputs and thus also pays no fee

The Quorum Commitment (QcTx) special transaction adds the best final commitment from a Long-Living Masternode QuorumLong-Living Masternode Quorum - Long-Living Masternode Quorums (LLMQs) are a Dash innovation that enable masternodes to perform threshold signing of consensus-related messages (e.g. InstantSend transactions). LLMQs provide a more scalable, general use quorum system than the ephemeral ones used prior to Dash Core version 0.14. (LLMQ) Distributed Key Generation (DKG) session to the chain.

Since this special transaction pays no fees, it is mandatory by consensus rulesconsensus rules - The block validation rules that full nodes follow to stay in consensus with other nodes. to ensure that miners include it. Exactly one quorum commitment transaction MUST be included in 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. while in the mining phase of the LLMQ process until a valid commitment is present in a block.

If a DKG failed or 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. did not receive a final commitment in-time, a null commitment has to be included in the special transaction payload. A null commitment must have the signers and validMembers bitsets set to the quorumSize and all bits set to zero. All other fields must be set to the null representation of the field’s types.

The special transaction type used for Quorum Commitment Transactions is 6 and
the extra payload consists of the following data:

BytesNameData typeDescription
2versionuint_16Quorum Commitment version number. Currently set to 1.
4heightuint32_tHeight of the block
VariablecommitmentqfcommitThe payload of the qfcommit message

The following annotated hexdump shows a QcTx transaction.

An itemized quorum commitment transaction:

0300 ....................................... Version (3)
0600 ....................................... Type (6 - Quorum Commitment)

00 ......................................... Number of inputs
00 ......................................... Number of outputs

00000000 ................................... Locktime

fd4901 ..................................... Extra payload size (329)

Quorum Commitment Transaction Payload
| 0100 ..................................... Version (1)
|
| 934c0100 ................................. Block height: 85139
|
| Payload from the qfcommit message
| | 0100 ................................... Version (1)
| |
| | 01 ..................................... LLMQ Type (1)
| |
| | 6b2fd2c61cea32d939ee7fe185c7abc5
| | 01aa7001d973379f46b9200500000000 ....... Quorum hash
| |
| | 32 ..................................... Number of signers (50)
| | bfffffffffff03 ......................... Aggregrated signers bitvector
| |
| | 32 ..................................... Number of valid members (50)
| | bfffffffffff03 ......................... Valid members bitvector
| |
| | 9450e90f61a24a4205c92572666ed068
| | 40f617ac11a26d650c88769675e81197
| | 993858d8b695f120f0af7dd38c17a67e ....... Quorum public key (BLS)
| |
| | 912507814fe204c59e14720bc961c09f
| | f88a4fd1f15e9c2efd4e4f112720967d ....... Quorum verification vector hash
| |
| | Quorum threshold signature (BLS)
| | 0281c321090c2d2e59a0d3754dcfbc11
| | d76c26a152b50885d826915af4d95a73
| | 120d0e1ba7e96d89f40252e24109c323
| | 0971dda1f554d331985ca570c76b9a1a
| | ec699ec132838ae097c767d65d0a51d7
| | 017c62e062270b60b854ae912bc07437 ....... BLS Signatures (96 bytes)
| |
| | Aggregated signatures from all commitments (BLS)
| | 91f878a0ae620e2178bff06c3a3967d7
| | 433d4b82e7879bb927dd5cb605423c84
| | 0641fcddf3731da80d0515a172ff3666
| | 0f4eac88ee8fd7779e32e4f0be704078
| | df31601b87b95374cebb4b304afc543e
| | e0d4f461a2ba0e32a711197ca559dacf ....... BLS Signature (96 bytes)

Did this page help you?