Integration Overview#

This documentation is also available as a PDF.

Dash Core is a fork of Bitcoin Core and shares many common functionalities. Key differences are found in existing JSON-RPC commands which have been customized to support unique functionalities such as InstantSend.

The Basics#

Dash is a Proof of Work network, and similar to Bitcoin, Dash has a mining network but uses a different block hashing algorithm. Dash serves as an improvement of Bitcoin's shortcomings by offering a robust solution for instant transactions, enhancing user privacy, and offering a self-sustainable decentralized governance model.

Notably, Dash InstantSend provides a mechanism for zero-confirmation transactions to be safely accepted and re-spent. InstantSend also provides enhanced security compared to the conventional practice of waiting for multiple block confirmations. Therefore, implementing InstantSend is the recommended best practice for all Dash integrations.

JSON-RPC Interface#

The majority of commands are unchanged from Bitcoin making integration into existing systems relatively straightforward. For a complete listing of RPC commands please refer to the ​Dash Developer Guide.

Note that the following commands have been modified to support InstantSend:

Special Transactions#

Dash Core v0.13.0 introduced the concept of “Special Transactions” as specified in DIP002. Special Transactions provide a more native way to implement additional features which do not fit into the original concept of transactions. Please see the Special Transactions section below for more information.

Block Hashing Algorithm#

Dash uses the X11 algorithm in place of SHA256 used in Bitcoin. It’s important to note, however, that this only affects the hashing of the block itself. All other internals utilize SHA256 hashes (transactions, merkle root, etc.), which allows for most existing libraries to work in the Dash ecosystem.

Special Transactions#

This documentation is also available as a PDF.

Dash 0.13.0 and higher implement DIP002 Special Transactions, which form a basis for new transaction types that provide on-chain metadata to assist various consensus mechanisms. The following special transaction types exist:

Phiên Bản

Type

Payload Size

Transaction Purpose / Example

3

0

n/a

Standard Transaction

3

1

variable

Masternode Registration

3

2

variable

Update Masternode Service

3

3

variable

Update Masternode Operator

3

4

variable

Masternode Revocation

3

5

variable

Masternode List Merkle Proof

3

6

variable

Quorum Commitment

Integration notes:

  1. DIP002 Special Transactions introduced a new Transaction Version and related “Payload” to the network.

  2. Integrated Systems must be able to serialize and deserialize these new Transaction Types to accurately encode and decode Raw Transaction data.

  3. From a backwards compatibility perspective, the 4 byte (32-bit) version field included in Classical Transactions was split into two fields: version and type (each consisting of 2 bytes).

  4. Refer to the Special Transactions section of the Dash developer reference for additional detail on these data types, e.g. <variable int>.

  5. InstantSend status and Payload JSON (e.g. proRegTx) is included in the JSON-RPC response, please note that this data is not part of the calculated hash and is provided for convenience.

See the transaction types integration documentation (PDF) for worked examples of each transaction type.

InstantSend#

This documentation is also available as a PDF.

InstantSend is a feature provided by the Dash network that allows for zero-confirmation transactions to be safely accepted and re-spent. The network attempts to lock the inputs of every valid transaction when it is broadcast to the network. Every secured transaction is included in a following block in accordance with standard blockchain principles. Transactions are typically locked by InstantSend within 3 seconds of being propagated to the network.

InstantSend is enabled by the Masternode Network which comprises several thousand masternode servers. These nodes are differentiated from standard nodes by having proven ownership of 1,000 Dash, making the network highly resistant to Sybil attacks. Masternodes form Long-Living Masternode Quorums (LLMQs), which are responsible for providing near-instant certainty to the transaction participants that the transaction inputs cannot be re-spent, and that the transaction will be included in a following block instead of a conflicting transaction.

This concept works as an extension to Nakamoto Consensus to provide additional security. InstantSend enables transacted funds to be immediately and securely re-spent by the recipient, even before the transaction is included in a block.

Nhận các giao dịch InstantSend#

Ghi chú

An "InstantSend Transaction" is simply a standard transaction that has been provided additional assurances by the masternode network. As a result, and from an integration perspective, the only technical difference is the InstantSend status.

Nhận một giao dịch InstantSend đứng trước hai yêu cầu:

  1. Khả năng xác định "Tình trạng InstantSend" của một giao dịch.

  2. Khả năng thay đổi "Tình trạng Xác nhận" một cách độc lập của xác thực khôi.

InstantSend Status is provided by the dash daemon, typically through a direct connection (e.g. RPC), ZMQ notification, or through the usage of an external wallet notification script.

Direct Connection#

InstantSend Status can be identified through direct connection with the Dash daemon using JSON-RPC protocol. The instantlock attribute of the JSON response reflects the status of the transaction and is included in the following commands:

ZMQ Notification#

Whenever a transaction enters the mempool and whenever a transaction is locked in the mempool, ZMQ notifications can be broadcast by the node. Refer to the list of possible ZMQ notifications for more details.

Những thông báo sau là liên quan đến việc nhận dạng những giao dịch và các instantlocks tương ứng của chúng:

  • zmqpubhashtx

  • zmqpubhashtxlock

  • zmqpubrawtx

  • zmqpubrawtxlock

Wallet Notification#

The Dash Core Daemon can be configured to execute an external script whenever an InstantSend transaction relating to that wallet is observed. This is configured by adding the following line to the dash.conf file:

instantsendnotify=/path/to/concurrent/safe/handler %s

This is typically used with a wallet that has been populated with watch-only addresses.

Quảng bá về các giao dịch InstantSend#

Mẹo

Because all transactions on the Dash network are automatically InstantSend, no procedural changes are required to broadcast transactions as InstantSend.

Từ khi Dash v0.14.0 thiết lập LLMQ trên mạng lưới Dash, quorum bây giờ sẽ thử khoá mọi giao dịch hợp lệ nào một cách ngầm định mà không tính thêm phí bổ sung hoặc yêu cầu các hành động bổ sung từ phía ví hay người dùng. Một giao dịch được coi là hợp lệ cho InstantSend khi mỗi đầu vào của nó được xem như là đã được xác thực. Đây là trường hợp mà ít nhất một trong các điều kiện sau là đúng:

  • giao dịch trước đó được tham chiếu đên bởi đầu vào được xác nhận với 6 khối.

  • giao dịch trước đó được xác nhận thông qua một khoá InstantSend trước hơn

  • the block containing the previous transaction is ChainLocked

When checking the previous transaction for an InstantSend lock, it is important to do this on mempool (non-mined) transactions. This allows chained InstantSend locking.

Những tài nguyên bổ sung#

Những tài nguyên sau cung cấp thêm thông tin về InstantSend và có ý định giúp cung cấp sự hiểu biết đầy đủ về những công nghệ nền ở dưới.

ChainLocks#

ChainLocks là một tính năng được cung cấp bởi mạng lưới Dash nhằm cung cấp mức độ chắc chắn khi chấp nhận thanh toán. Công nghệ này, đặc biệt khi được sử dụng song song với InstantSend, tạo ra một môi trường trong đó các khoản thanh toán có thể được chấp nhận ngay tức thời mà không phải chịu rủi ro của "Các sự kiện tái tổ chức blockchain".

The risk of blockchain reorganization is typically addressed by requiring multiple confirmations before a transaction can be safely accepted as payment. This type of indirect security is effective, but at a cost of time and user experience. ChainLocks are a solution for this problem.

Receiving ChainLocks#

Ghi chú

Once a ChainLock is observed for a block, each transaction in that block and all previous blocks can be considered irreversibly and fully confirmed.

Receiving a ChainLock introduces two requirements:

  1. The ability to determine the “ChainLock Status” of a given block or transaction.

  2. Khả năng thay đổi "Tình trạng Xác nhận" một cách độc lập của xác thực khôi.

ChainLock status is provided by the dash daemon, typically through a direct connection (e.g. RPC) or by a ZMQ notification.

Direct Connection#

ChainLock status can be identified through direct connection with the Dash daemon using JSON-RPC protocol. The boolean chainlock attribute of the JSON response reflects the ChainLock status of the block or transaction and is included in the following commands:

ZMQ Notification#

ChainLock signatures are created shortly after the related block has been mined. As a result it is recommended that integrated clients use ZMQ (ZeroMQ) notifications in order to ensure that this information is received as promptly as possible. Refer to the list of possible ZMQ notifications for more details.

The following notifications are relevant for recognizing blocks and their corresponding ChainLocks:

  • zmqpubhashblock

  • zmqpubhashchainlock

  • zmqpubrawblock

  • zmqpubrawchainlock

  • zmqpubrawchainlocksig

This sample code uses the js-dashd-zmq library to listen for ChainLock ZMQ notifications and return the hash of blocks that receive a ChainLock.

Subscribe to ChainLock hash ZMQ notifications#
const { ChainLock } = require('@dashevo/dashcore-lib');
const ZMQClient = require('@dashevo/dashd-zmq');
const client = new ZMQClient({
   protocol: 'tcp',
   host: '0.0.0.0',
   port: '20009',
});

(async () => {
   await client.connect();
   client.subscribe(ZMQClient.TOPICS.hashchainlock);
   client.on(ZMQClient.TOPICS.hashchainlock, async (hashChainLockMessage) => {
      console.log(`ChainLock received for block ${hashChainLockMessage}`)
   });
})();

Wallet Notification#

The Dash Core daemon can be configured to execute an external script whenever a ChainLock is received. This is configured by adding the following line to the dash.conf file:

chainlocknotify=/path/to/concurrent/safe/handler %s

Những tài nguyên bổ sung#

Những tài nguyên sau cung cấp thêm thông tin về InstantSend và có ý định giúp cung cấp sự hiểu biết đầy đủ về những công nghệ nền ở dưới.