Dash Core

Dash Core Developer Documentation

Welcome to the Dash Core developer documentation. You'll find guides and documentation to help you start working with Dash Core as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

Transaction Broadcasting

In order to send a transactiontransaction - A transaction spending satoshis. to a peerpeer - A computer that connects to the Dash network., an inv message is sent. If a getdata message is received in reply, the transaction is sent using a tx message. If it is a valid transaction, the peer receiving the transaction also forwards the transaction to its peers.

Memory Pool

Full peers may keep track of unconfirmed transactions which are eligible to be included in the next 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.. This is essential for miners who will actually mine some or all of those transactions, but it's also useful for any peer who wants to keep track of unconfirmed transactions, such as peers serving unconfirmed transaction information to SPV clients.

Because unconfirmed transactions have no permanent status in Dash, Dash Core stores them in non-persistent memory, calling them a memory pool or mempool. When a peer shuts down, its memory pool is lost except for any transactions stored by its wallet. This means that never-mined unconfirmed transactions tend to slowly disappear from the network as peers restart or as they purge some transactions to make room in memory for others.

Transactions which are mined into blocks that later become stale blocksstale blocks - Blocks which were successfully mined but which aren't included on the current best block chain, likely because some other block at the same height had its chain extended first. may be added back into the memory pool. These re-added transactions may be re-removed from the pool almost immediately if the replacement blocks include them. This is the case in Dash Core, which removes stale blocks from the chain one by one, starting with the tip (highest block). As each block is removed, its transactions are added back to the memory pool. After all of the stale blocks are removed, the replacement blocks are added to the chain one by one, ending with the new tip. As each block is added, any transactions it confirms are removed from the memory pool.

SPV clients don't have a memory pool for the same reason they don't relay transactions. They can't independently verify that a transaction hasn't yet been included in a block and that it only spends UTXOs, so they can't know which transactions are eligible to be included in the next block.

Updated about a year ago



Transaction Broadcasting


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.