mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 01:36:13 +00:00
1099 lines
47 KiB
Markdown
1099 lines
47 KiB
Markdown
{% comment %}
|
||
This file is licensed under the MIT License (MIT) available on
|
||
http://opensource.org/licenses/MIT.
|
||
{% endcomment %}
|
||
{% assign filename="_includes/devdoc/ref_transactions.md" %}
|
||
|
||
## Transactions
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
<!-- __ -->
|
||
|
||
The following subsections briefly document core transaction details.
|
||
|
||
#### OpCodes
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
The opcodes used in the pubkey scripts of standard transactions are:
|
||
|
||
* Various data pushing opcodes from 0x00 to 0x4e (1--78). These aren't
|
||
typically shown in examples, but they must be used to push
|
||
signatures and public keys onto the stack. See the link below this list
|
||
for a description.
|
||
|
||
* `OP_TRUE`/`OP_1` (0x51) and `OP_2` through `OP_16` (0x52--0x60), which
|
||
push the values 1 through 16 to the stack.
|
||
|
||
* [`OP_CHECKSIG`][op_checksig]{:#term-op-checksig}{:.term} (0xac) consumes a signature and a full public key, and pushes
|
||
true onto the stack if the transaction data specified by the SIGHASH flag was
|
||
converted into the signature using the same ECDSA private key that
|
||
generated the public key. Otherwise, it pushes false onto the stack.
|
||
|
||
* [`OP_DUP`][op_dup]{:#term-op-dup}{:.term} (0x76) pushes a copy of the topmost stack item on to the stack.
|
||
|
||
* [`OP_HASH160`][op_hash160]{:#term-op-hash160}{:.term} (0xa9) consumes the topmost item on the stack,
|
||
computes the RIPEMD160(SHA256()) hash of that item, and pushes that hash onto the stack.
|
||
|
||
* [`OP_EQUAL`][op_equal]{:#term-op-equal}{:.term} (0x87) consumes the top two items on the stack, compares them, and
|
||
pushes true onto the stack if they are the same, false if not.
|
||
|
||
* [`OP_VERIFY`][op_verify]{:#term-op-verify}{:.term} (0x69) consumes the topmost item on the stack.
|
||
If that item is zero (false) it terminates the script in failure.
|
||
|
||
* [`OP_EQUALVERIFY`][op_equalverify]{:#term-op-equalverify}{:.term} (0x88) runs `OP_EQUAL` and then `OP_VERIFY` in sequence.
|
||
|
||
* [`OP_CHECKMULTISIG`][op_checkmultisig]{:#term-op-checkmultisig}{:.term} (0xae) consumes the value (n) at the top of the stack,
|
||
consumes that many of the next stack levels (public keys), consumes
|
||
the value (m) now at the top of the stack, and consumes that many of
|
||
the next values (signatures) plus one extra value.
|
||
|
||
The "one extra value" it consumes is the result of an off-by-one
|
||
error in the Bitcoin Core implementation. This value is not used, so
|
||
signature scripts prefix the list of secp256k1 signatures with a
|
||
single OP_0 (0x00).
|
||
|
||
`OP_CHECKMULTISIG` compares the first signature against each public
|
||
key until it finds an ECDSA match. Starting with the subsequent
|
||
public key, it compares the second signature against each remaining
|
||
public key until it finds an ECDSA match. The process is repeated
|
||
until all signatures have been checked or not enough public keys
|
||
remain to produce a successful result.
|
||
|
||
Because public keys are not checked again if they fail any signature
|
||
comparison, signatures must be placed in the signature script using
|
||
the same order as their corresponding public keys were placed in
|
||
the pubkey script or redeem script. See the `OP_CHECKMULTISIG` warning
|
||
below for more details.
|
||
|
||
* [`OP_RETURN`][op_return]{:#term-op-return}{:.term} (0x6a) terminates the script in failure when executed.
|
||
|
||
A complete list of opcodes can be found on the Bitcoin Wiki [Script
|
||
Page][wiki script], with an authoritative list in the `opcodetype` enum
|
||
of the Dash Core [script header file][core script.h]
|
||
|
||
|
||
**<span id="signature_script_modification_warning">Signature script modification warning</span>:**
|
||
Signature scripts are not signed, so anyone can modify them. This
|
||
means signature scripts should only contain data and data-pushing opcodes
|
||
which can't be modified without causing the pubkey script to fail.
|
||
Placing non-data-pushing opcodes in the signature script currently
|
||
makes a transaction non-standard, and future consensus rules may forbid
|
||
such transactions altogether. (Non-data-pushing opcodes are already
|
||
forbidden in signature scripts when spending a P2SH pubkey script.)
|
||
|
||
|
||
**`OP_CHECKMULTISIG` warning:** The multisig verification process
|
||
described above requires that signatures in the signature script be
|
||
provided in the same order as their corresponding public keys in
|
||
the pubkey script or redeem script. For example, the following
|
||
combined signature and pubkey script will produce the stack and
|
||
comparisons shown:
|
||
|
||
{% highlight text %}
|
||
OP_0 <A sig> <B sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3
|
||
|
||
Sig Stack Pubkey Stack (Actually a single stack)
|
||
--------- ------------
|
||
B sig C pubkey
|
||
A sig B pubkey
|
||
OP_0 A pubkey
|
||
|
||
1. B sig compared to C pubkey (no match)
|
||
2. B sig compared to B pubkey (match #1)
|
||
3. A sig compared to A pubkey (match #2)
|
||
|
||
Success: two matches found
|
||
{% endhighlight %}
|
||
|
||
But reversing the order of the signatures with everything else the same
|
||
will fail, as shown below:
|
||
|
||
{% highlight text %}
|
||
OP_0 <B sig> <A sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3
|
||
|
||
Sig Stack Pubkey Stack (Actually a single stack)
|
||
--------- ------------
|
||
A sig C pubkey
|
||
B sig B pubkey
|
||
OP_0 A pubkey
|
||
|
||
1. A sig compared to C pubkey (no match)
|
||
2. A sig compared to B pubkey (no match)
|
||
|
||
Failure, aborted: two signature matches required but none found so
|
||
far, and there's only one pubkey remaining
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### Address Conversion
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
The hashes used in P2PKH and P2SH outputs are commonly encoded as Dash
|
||
addresses. This is the procedure to encode those hashes and decode the
|
||
addresses.
|
||
|
||
First, get your hash. For P2PKH, you RIPEMD-160(SHA256()) hash a ECDSA
|
||
public key derived from your 256-bit ECDSA private key (random data).
|
||
For P2SH, you RIPEMD-160(SHA256()) hash a redeem script serialized in the
|
||
format used in raw transactions (described in a [following
|
||
sub-section][raw transaction format]). Taking the resulting hash:
|
||
|
||
1. Add an address version byte in front of the hash. The version
|
||
bytes commonly used by Dash are:
|
||
|
||
* 0x4c for P2PKH addresses on the main Dash network (mainnet)
|
||
|
||
* 0x8c for P2PKH addresses on the Dash testing network (testnet)
|
||
|
||
* 0x10 for P2SH addresses on mainnet
|
||
|
||
* 0x13 for P2SH addresses on testnet
|
||
|
||
2. Create a copy of the version and hash; then hash that twice with SHA256: `SHA256(SHA256(version . hash))`
|
||
|
||
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.
|
||
|
||
4. Append the checksum to the version and hash, and encode it as a base58
|
||
string: <!--[-->`BASE58(version . hash . checksum)`<!--]-->
|
||
|
||
Dash's base58 encoding, called [Base58Check][/en/glossary/base58check]{:#term-base58check}{:.term} may not match other implementations. Tier
|
||
Nolan provided the following example encoding algorithm to the Bitcoin
|
||
Wiki [Base58Check
|
||
encoding](https://en.bitcoin.it/wiki/Base58Check_encoding) page under
|
||
the [Creative Commons Attribution 3.0 license][]:
|
||
|
||
{% highlight c %}
|
||
code_string = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
|
||
x = convert_bytes_to_big_integer(hash_result)
|
||
|
||
output_string = ""
|
||
|
||
while(x > 0)
|
||
{
|
||
(x, remainder) = divide(x, 58)
|
||
output_string.append(code_string[remainder])
|
||
}
|
||
|
||
repeat(number_of_leading_zero_bytes_in_hash)
|
||
{
|
||
output_string.append(code_string[0]);
|
||
}
|
||
|
||
output_string.reverse();
|
||
{% endhighlight %}
|
||
|
||
Dash's own code can be traced using the [base58 header
|
||
file][core base58.h].
|
||
|
||
To convert addresses back into hashes, reverse the base58 encoding, extract
|
||
the checksum, repeat the steps to create the checksum and compare it
|
||
against the extracted checksum, and then remove the version byte.
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### Raw Transaction Format
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
Dash transactions are broadcast between peers
|
||
in a serialized byte format, called [raw format][/en/glossary/serialized-transaction]{:#term-raw-format}{:.term}.
|
||
It is this form of a transaction which is SHA256(SHA256()) hashed to create
|
||
the TXID and, ultimately, the merkle root of a block containing the
|
||
transaction---making the transaction format part of the consensus rules.
|
||
|
||
Dash Core and many other tools print and accept raw transactions
|
||
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 chain are allowed to list a higher version
|
||
number to permit soft forks, 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](https://github.com/dashpay/dips/blob/master/dip-0002.md)
|
||
implementation. Details of the changes introduced by
|
||
this feature and currently implemented special transactions can be found in the
|
||
[Special Transactions section](#special-transactions) below as well as in the
|
||
[DIP](https://github.com/dashpay/dips/blob/master/dip-0002.md).
|
||
|
||
A raw transaction has the following top-level format:
|
||
|
||
| Bytes | Name | Data Type | Description
|
||
|----------|--------------|---------------------|-------------
|
||
| 2 | version | uint16_t | *Converted from 4 bytes to 2 bytes by DIP2 in v0.13.0*<br><br>Transaction version number; currently version 3. Programs creating transactions using newer consensus rules may use higher version numbers.
|
||
| 2 | type | uint16_t | *Added by DIP2 in v0.13.0. Uses 2 bytes that were previously part of `version`*<br><br>Transaction type number; 0 for classical transactions; Non-zero for DIP2 special transactions.
|
||
| *Varies* | tx_in count | compactSize uint | Number of inputs in this transaction.
|
||
| *Varies* | tx_in | txIn | Transaction inputs. See description of txIn below.
|
||
| *Varies* | tx_out count | compactSize uint | Number of outputs in this transaction.
|
||
| *Varies* | tx_out | txOut | Transaction outputs. See description of txOut below.
|
||
| 4 | lock_time | uint32_t | A time (Unix epoch time) or block number. See the [locktime parsing rules][].
|
||
| *Varies* | extra_payload size | compactSize uint | *Added by DIP2 in v0.13.0*<br><br>Variable number of bytes of extra payload for DIP2-based special transactions
|
||
| *Varies* | extra_payload | blob | *Added by DIP2 in v0.13.0*<br><br>Special transaction payload.
|
||
|
||
A transaction may have multiple inputs and outputs, so the txIn and
|
||
txOut structures may recur within a transaction. CompactSize unsigned
|
||
integers are a form of variable-length integers; they are described in
|
||
the [CompactSize section][section CompactSize unsigned integer].
|
||
|
||
##### JSON-RPC<!--noref--> Responses
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
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):
|
||
{% highlight json %}
|
||
{
|
||
"txid": <string>,
|
||
"size": <int>,
|
||
"version": 2,
|
||
"locktime": 0,
|
||
"vin": [ ],
|
||
"vout": [ ]
|
||
}
|
||
{% endhighlight %}
|
||
|
||
Version 3 Transaction Structure (Dash Core v0.13.0+ and activated DIP2):
|
||
{% highlight json %}
|
||
{
|
||
"txid": <string>,
|
||
"size": <int>,
|
||
"version": 3,
|
||
"type": <int>,
|
||
"locktime": 0,
|
||
"vin": [ ],
|
||
"vout": [ ],
|
||
"extraPayloadSize": <variable int>,
|
||
"extraPayload": …
|
||
}
|
||
{% endhighlight %}
|
||
|
||
For special transactions (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:
|
||
|
||
{% highlight json %}
|
||
{
|
||
"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
|
||
}
|
||
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
##### TxIn: A Transaction Input (Non-Coinbase) {#txin}
|
||
{:.no_toc}
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
Each non-coinbase input spends an outpoint from a previous transaction.
|
||
(Coinbase inputs are described separately after the example section below.)
|
||
|
||
| Bytes | Name | Data Type | Description
|
||
|----------|------------------|----------------------|--------------
|
||
| 36 | previous_output | outpoint | The previous outpoint being spent. See description of outpoint below.
|
||
| *Varies* | script bytes | compactSize uint | The number of bytes in the signature script. Maximum is 10,000 bytes.
|
||
| *Varies* | signature script | char[] | 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][].
|
||
| 4 | sequence | uint32_t | Sequence number. Default for Dash Core and almost all other programs is 0xffffffff.
|
||
|
||
{% endautocrossref %}
|
||
|
||
##### Outpoint: The Specific Part Of A Specific Output {#outpoint}
|
||
{:.no_toc}
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
Because a single transaction can include multiple outputs, the outpoint
|
||
structure includes both a TXID and an output index number to refer to
|
||
specific output.
|
||
|
||
| Bytes | Name | Data Type | Description
|
||
|-------|-------|-----------|--------------
|
||
| 32 | hash | char[32] | The TXID of the transaction holding the output to spend. The TXID is a hash provided here in internal byte order.
|
||
| 4 | index | uint32_t | The output index number of the specific output to spend from the transaction. The first output is 0x00000000.
|
||
|
||
{% endautocrossref %}
|
||
|
||
##### TxOut: A Transaction Output {#txout}
|
||
{:.no_toc}
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
Each output spends a certain number of duffs, placing them under
|
||
control of anyone who can satisfy the provided pubkey script.
|
||
|
||
| Bytes | Name | Data Type | Description
|
||
|----------|-----------------|------------------|--------------
|
||
| 8 | value | int64_t | Number 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 bytes | compactSize uint | Number of bytes in the pubkey script. Maximum is 10,000 bytes.
|
||
| *Varies* | pk_script | char[] | 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][section simple raw transaction] of the
|
||
Developer Examples. It spends a previous pay-to-pubkey output by paying
|
||
to a new pay-to-pubkey-hash (P2PKH) output.
|
||
|
||
{% highlight text %}
|
||
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)
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
##### Coinbase Input: The Input Of The First Transaction In A Block {#coinbase}
|
||
{:.no_toc}
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
The first transaction in a block, called the coinbase transaction, must
|
||
have exactly one input, called a coinbase. The coinbase input currently
|
||
has the following format.
|
||
|
||
| Bytes | Name | Data Type | Description
|
||
|----------|--------------------|----------------------|--------------
|
||
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
|
||
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
|
||
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
|
||
| *Varies* (4) | height | script | The [block height][/en/glossary/coinbase]{:#term-coinbase-block-height}{:.term} 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.<br/><br/> The data-pushing opcode will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
|
||
| *Varies* | coinbase script | *None* | The [coinbase field][/en/glossary/coinbase]{:#term-coinbase-field}{:.term}: 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.
|
||
| 4 | sequence | uint32_t | Sequence number.
|
||
|
||
<!--
|
||
Most (but not all) blocks prior to block height 227,836 used block
|
||
version 1 which did not require the height parameter to be prefixed to
|
||
the coinbase script. The block height parameter is now required.
|
||
-->
|
||
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 transaction:
|
||
|
||
{% highlight text %}
|
||
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
|
||
{% endhighlight %}
|
||
|
||
Note: currently the normal coinbase has 2 outputs (1 for the miner and 1 for
|
||
the selected masternode). Superblocks ([superblock example][superblock example])
|
||
have multiple outputs depending on the number of proposals being funded.
|
||
|
||
{% endautocrossref %}
|
||
|
||
### Special Transactions
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
The Special Transaction framework established by DIP2 enabled the implementation
|
||
of new on-chain features and consensus 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](https://github.com/dashpay/dips/blob/master/dip-0002-special-transactions.md).
|
||
|
||
**Implemented Special Transactions**
|
||
|
||
| Release | Tx Version | Tx Type | Payload Size | Payload | Payload JSON | Tx Purpose
|
||
| - | - | - | - | - | - |
|
||
| v0.12.3 | 2 | - | n/a | n/a | n/a |
|
||
| v0.13.0 | 3 | 0 | n/a | n/a | n/a | Standard (Classical) Transaction
|
||
| v0.13.0 | 3 | 1 | compactSize uint | hex | ProRegTx | Masternode Registration
|
||
| v0.13.0 | 3 | 2 | compactSize uint | hex | ProUpServTx | Update Masternode Service
|
||
| v0.13.0 | 3 | 3 | compactSize uint | hex | ProUpRegTx| Update Masternode Operator
|
||
| v0.13.0 | 3 | 4 | compactSize uint | hex | ProUpRevTx| Masternode Operator Revocation
|
||
| v0.13.0 | 3 | 5 | compactSize uint | hex | CbTx| Masternode List Merkle Proof
|
||
| v0.13.0 | 3 | 6 | compactSize uint | hex | QcTx| Long-Living Masternode Quorum Commitment
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### ProRegTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*Added in protocol version 70213 of Dash Core as described by DIP3*
|
||
|
||
The Masternode 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 output 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | Provider transaction version number. Currently set to 1.
|
||
| 2 | type | uint_16 | Masternode type. Default set to 0.
|
||
| 2 | mode | uint_16 | Masternode mode. Default set to 0.
|
||
| 36 | collateralOutpoint | COutpoint | The collateral outpoint.<br>**Note:** The hash will be null if the collateral is part of this transaction, otherwise it will reference an existing collateral.
|
||
| 16 | ipAddress | byte[] | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future)
|
||
| 2 | port | uint_16 | Port (network byte order)
|
||
| 20 | KeyIdOwner | CKeyID | The public key hash used for owner related signing (ProTx updates, governance voting)
|
||
| 48 | PubKeyOperator | CBLSPublicKey | The BLS public key used for operational related signing (network messages, ProTx updates)
|
||
| 20 | KeyIdVoting | CKeyID | The public key hash used for voting.
|
||
| 2 | operatorReward | uint_16 | A value from 0 to 10000.
|
||
| 1-9 | scriptPayoutSize | compactSize uint | Size of the Payee Script.
|
||
| Variable | scriptPayout | Script | Payee script (p2pkh/p2sh)
|
||
| 32 | inputsHash | uint256 | Hash of all the outpoints of the transaction inputs
|
||
| 1-9 | payloadSigSize |compactSize uint | Size of the Signature
|
||
| Variable | payloadSig | vector | Signature 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.)
|
||
|
||
{% highlight text %}
|
||
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
|
||
{% endhighlight %}
|
||
|
||
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.)
|
||
|
||
{% highlight text %}
|
||
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)
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### ProUpServTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*Added in protocol version 70213 of Dash Core as described by DIP3*
|
||
|
||
The Masternode 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | ProUpServTx version number. Currently set to 1.
|
||
| 32 | proTXHash | uint256 | The hash of the initial ProRegTx
|
||
| 16 | ipAddress | byte[] | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future)
|
||
| 2 | port | uint_16 | Port (network byte order)
|
||
| 1-9 | scriptOperator<br>PayoutSize | compactSize uint | Size of the Operator Payee Script.
|
||
| Variable | scriptOperator<br>Payout | Script | Operator Payee script (p2pkh/p2sh)
|
||
| 32 | inputsHash | uint256 | Hash of all the outpoints of the transaction inputs
|
||
| 1-9 | payloadSigSize |compactSize uint | Size of the Signature<br>**Note:** not present in BLS implementation
|
||
| 96 | payloadSig | vector | BLS 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.)
|
||
|
||
{% highlight text %}
|
||
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)
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### ProUpRegTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*Added in protocol version 70213 of Dash Core as described by DIP3*
|
||
|
||
The Masternode 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | Provider update registrar transaction version number. Currently set to 1.
|
||
| 32 | proTXHash | uint256 | The hash of the initial ProRegTx
|
||
| 2 | mode | uint_16 | Masternode mode. Default set to 0.
|
||
| 48 | PubKeyOperator | CBLSPublicKey | The BLS public key used for operational related signing (network messages, ProTx updates)
|
||
| 20 | KeyIdVoting | CKeyID | The public key hash used for voting.
|
||
| 1-9 | scriptPayoutSize | compactSize uint | Size of the Payee Script.
|
||
| Variable | scriptPayout | Script | Payee script (p2pkh/p2sh)
|
||
| 32 | inputsHash | uint256 | Hash of all the outpoints of the transaction inputs
|
||
| 1-9 | payloadSigSize |compactSize uint | Size of the Signature
|
||
| Variable | payloadSig | vector | Signature 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.)
|
||
|
||
<!--devnet-dashdocs getrawtransaction 702390ef06b10c174841ad7b863df23c166c27815e3be2438e2fee6f87882b91 true-->
|
||
|
||
{% highlight text %}
|
||
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
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### ProUpRevTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*Added in protocol version 70213 of Dash Core as described by DIP3*
|
||
|
||
The Masternode 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | ProUpRevTx version number. Currently set to 1.
|
||
| 32 | proTXHash | uint256 | The hash of the initial ProRegTx
|
||
| 2 | reason | uint_16 | The reason for revoking the key.<br>`0` - Not specified<br>`1` - Termination of Service<br>`2` - Compromised Key<br>`3` - Change of key
|
||
| 32 | inputsHash | uint256 | Hash of all the outpoints of the transaction inputs
|
||
| 1-9 | payloadSigSize |compactSize uint | Size of the Signature<br>**Note:** not present in BLS implementation
|
||
| 96 | payloadSig | vector | BLS 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.)
|
||
|
||
{% highlight text %}
|
||
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)
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### CbTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*Added in protocol version 70213 of Dash Core as described by DIP4*
|
||
|
||
The Coinbase (CbTx) special transaction adds information to the block’s coinbase
|
||
transaction that enables verification of the deterministic masternode list without
|
||
the full chain (e.g. from SPV clients). This allows light-clients to properly
|
||
verify InstantSend 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | CbTx version number. Currently set to 1.
|
||
| 4 | height | uint32_t | Height of the block
|
||
| 32 | merkleRootMNList | uint256 | Merkle root of the masternode list
|
||
| 32 | merkleRootQuorums | uint256 | *Added by CbTx version 2 in v0.14.0*<br><br>Merkle root of currently active LLMQs
|
||
|
||
Version History
|
||
|
||
| CbTx Version | First Supported Protocol Version | Dash Core Version | Notes |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 1 | 70213 | 0.13.0 | Enabled by activation of DIP3
|
||
| 2 | 70214 | 0.14.0 | Enabled by activation of DIP8
|
||
|
||
The following annotated hexdump shows a CbTx transaction.
|
||
|
||
<!--testnet getrawtransaction 1d009d4f47d217ed5fd14e6d8b56e1e61fc7c4e9a277e310d7ea14ddc64bb91c true-->
|
||
|
||
An itemized coinbase transaction:
|
||
|
||
{% highlight text %}
|
||
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
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
#### QcTx
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
*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 Quorum (LLMQ) Distributed Key Generation (DKG) session to
|
||
the chain.
|
||
|
||
Since this special transaction pays no fees, it is mandatory by consensus rules
|
||
to ensure that miners include it. Exactly one quorum commitment transaction MUST
|
||
be included in every block while in the mining phase of the LLMQ process until a
|
||
valid commitment is present in a block.
|
||
|
||
If a DKG failed or a miner 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:
|
||
|
||
| Bytes | Name | Data type | Description |
|
||
| ---------- | ----------- | -------- | -------- |
|
||
| 2 | version | uint_16 | Quorum Commitment version number. Currently set to 1.
|
||
| 4 | height | uint32_t | Height of the block
|
||
| Variable | commitment | qfcommit | The payload of the `qfcommit` message
|
||
|
||
The following annotated hexdump shows a QcTx transaction.
|
||
|
||
<!--getrawtransaction f218f2d5b8003bc530016dc510b3d982a5cf43ff76313b991ac5aa90a91065b7 true-->
|
||
|
||
An itemized quorum commitment transaction:
|
||
|
||
{% highlight text %}
|
||
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)
|
||
{% endhighlight %}
|
||
|
||
{% endautocrossref %}
|
||
|
||
### CompactSize Unsigned Integers
|
||
{% include helpers/subhead-links.md %}
|
||
|
||
{% autocrossref %}
|
||
|
||
The raw transaction format and several peer-to-peer network messages use
|
||
a type of variable-length integer to indicate the number of bytes in a
|
||
following piece of data.
|
||
|
||
Dash Core code and this document refers to these variable length
|
||
integers as compactSize. Many other documents refer to them as var_int
|
||
or varInt, but this risks conflation with other variable-length integer
|
||
encodings---such as the CVarInt class used in Dash Core for
|
||
serializing data to disk. Because it's used in the transaction format,
|
||
the format of compactSize unsigned integers is part of the consensus
|
||
rules.
|
||
|
||
For numbers from 0 to 252 (0xfc), compactSize unsigned integers look like
|
||
regular unsigned integers. For other numbers up to 0xffffffffffffffff, a
|
||
byte is prefixed to the number to indicate its length---but otherwise
|
||
the numbers look like regular unsigned integers in little-endian order.
|
||
|
||
| Value | Bytes Used | Format
|
||
|-----------------------------------------|------------|-----------------------------------------
|
||
| >= 0 && <= 0xfc (252) | 1 | uint8_t
|
||
| >= 0xfd (253) && <= 0xffff | 3 | 0xfd followed by the number as uint16_t
|
||
| >= 0x10000 && <= 0xffffffff | 5 | 0xfe followed by the number as uint32_t
|
||
| >= 0x100000000 && <= 0xffffffffffffffff | 9 | 0xff followed by the number as uint64_t
|
||
|
||
For example, the number 515 is encoded as 0xfd0302.
|
||
|
||
{% endautocrossref %}
|