README
¶
mempool
Package mempool provides a policy-enforced pool of unmined kaspa transactions.
A key responsbility of the kaspa network is mining user-generated transactions into blocks. In order to facilitate this, the mining process relies on having a readily-available source of transactions to include in a block that is being solved.
At a high level, this package satisfies that requirement by providing an in-memory pool of fully validated transactions that can also optionally be further filtered based upon a configurable policy.
One of the policy configuration options controls whether or not "standard" transactions are accepted. In essence, a "standard" transaction is one that satisfies a fairly strict set of requirements that are largely intended to help provide fair use of the system to all users. It is important to note that what is considered a "standard" transaction changes over time. For some insight, at the time of this writing, an example of some of the criteria that are required for a transaction to be considered standard are that it is of the most-recently supported version, finalized, does not exceed a specific size, and only consists of specific script forms.
Since this package does not deal with other kaspa specifics such as network communication and transaction relay, it returns a list of transactions that were accepted which gives the caller a high level of flexibility in how they want to proceed. Typically, this will involve things such as relaying the transactions to other peers on the network and notifying the mining process that new transactions are available.
This package has intentionally been designed so it can be used as a standalone package for any projects needing the ability create an in-memory pool of bitcoin transactions that are not only valid by consensus rules, but also adhere to a configurable policy.
Feature Overview
The following is a quick overview of the major features. It is not intended to be an exhaustive list.
- Maintain a pool of fully validated transactions
- Reject non-fully-spent duplicate transactions
- Reject coinbase transactions
- Reject double spends (both from the DAG and other transactions in pool)
- Reject invalid transactions according to the network consensus rules
- Full script execution and validation with signature cache support
- Individual transaction query support
- Orphan transaction support (transactions that spend from unknown outputs)
- Configurable limits (see transaction acceptance policy)
- Automatic addition of orphan transactions that are no longer orphans as new transactions are added to the pool
- Individual orphan transaction query support
- Configurable transaction acceptance policy
- Option to accept or reject standard transactions
- Option to accept or reject transactions based on priority calculations
- Rate limiting of low-fee and free transactions
- Non-zero fee threshold
- Max signature operations per transaction
- Max orphan transaction size
- Max number of orphan transactions allowed
- Additional metadata tracking for each transaction
- Timestamp when the transaction was added to the pool
- Most recent block height when the transaction was added to the pool
- The fee the transaction pays
- The starting priority for the transaction
- Manual control of transaction removal
- Recursive removal of all dependent transactions
Documentation
¶
Overview ¶
Package mempool provides a policy-enforced pool of unmined kaspa transactions.
A key responsbility of the kaspa network is mining user-generated transactions into blocks. In order to facilitate this, the mining process relies on having a readily-available source of transactions to include in a block that is being solved.
At a high level, this package satisfies that requirement by providing an in-memory pool of fully validated transactions that can also optionally be further filtered based upon a configurable policy.
One of the policy configuration options controls whether or not "standard" transactions are accepted. In essence, a "standard" transaction is one that satisfies a fairly strict set of requirements that are largely intended to help provide fair use of the system to all users. It is important to note that what is considered a "standard" transaction changes over time. For some insight, at the time of this writing, an example of SOME of the criteria that are required for a transaction to be considered standard are that it is of the most-recently supported version, finalized, does not exceed a specific size, and only consists of specific script forms.
Since this package does not deal with other kaspa specifics such as network communication and transaction relay, it returns a list of transactions that were accepted which gives the caller a high level of flexibility in how they want to proceed. Typically, this will involve things such as relaying the transactions to other peers on the network and notifying the mining process that new transactions are available.
Feature Overview ¶
The following is a quick overview of the major features. It is not intended to be an exhaustive list.
- Maintain a pool of fully validated transactions
- Reject non-fully-spent duplicate transactions
- Reject coinbase transactions
- Reject double spends (both from the DAG and other transactions in pool)
- Reject invalid transactions according to the network consensus rules
- Full script execution and validation with signature cache support
- Individual transaction query support
- Orphan transaction support (transactions that spend from unknown outputs)
- Configurable limits (see transaction acceptance policy)
- Automatic addition of orphan transactions that are no longer orphans as new transactions are added to the pool
- Individual orphan transaction query support
- Configurable transaction acceptance policy
- Option to accept or reject standard transactions
- Option to accept or reject transactions based on priority calculations
- Max signature operations per transaction
- Max number of orphan transactions allowed
- Additional metadata tracking for each transaction
- Timestamp when the transaction was added to the pool
- The fee the transaction pays
- The starting priority for the transaction
- Manual control of transaction removal
- Recursive removal of all dependent transactions
Errors ¶
Errors returned by this package are either the raw errors provided by underlying calls or of type mempool.RuleError. Since there are two classes of rules (mempool acceptance rules and blockDAG (consensus) acceptance rules), the mempool.RuleError type contains a single Err field which will, in turn, either be a mempool.TxRuleError or a ruleerrors.RuleError. The first indicates a violation of mempool acceptance rules while the latter indicates a violation of consensus acceptance rules. This allows the caller to easily differentiate between unexpected errors, such as database errors, versus errors due to rule violations through type assertions. In addition, callers can programmatically determine the specific rule violation by type asserting the Err field to one of the aforementioned types and examining their underlying ErrorCode field.
Index ¶
Constants ¶
const ( // MaxStandardTxSize is the maximum size allowed for transactions that // are considered standard and will therefore be relayed and considered // for mining. MaxStandardTxSize = 100000 // DefaultMinRelayTxFee is the minimum fee in sompi that is required // for a transaction to be treated as free for relay and mining // purposes. It is also used to help determine if a transaction is // considered dust and as a base for calculating minimum required fees // for larger transactions. This value is in sompi/1000 bytes. DefaultMinRelayTxFee = util.Amount(1000) )
Variables ¶
This section is empty.
Functions ¶
func New ¶
func New(consensus consensusexternalapi.Consensus, acceptNonStd bool) miningmanagermodel.Mempool
New returns a new memory pool for validating and storing standalone transactions until they are mined into a block.
Types ¶
type RejectCode ¶
type RejectCode uint8
RejectCode represents a numeric value by which a remote peer indicates why a message was rejected.
const ( RejectMalformed RejectCode = 0x01 RejectInvalid RejectCode = 0x10 RejectObsolete RejectCode = 0x11 RejectDuplicate RejectCode = 0x12 RejectNotRequested RejectCode = 0x13 RejectNonstandard RejectCode = 0x40 RejectDust RejectCode = 0x41 RejectInsufficientFee RejectCode = 0x42 RejectFinality RejectCode = 0x43 RejectDifficulty RejectCode = 0x44 )
These constants define the various supported reject codes.
func (RejectCode) String ¶
func (code RejectCode) String() string
String returns the RejectCode in human-readable form.
type RuleError ¶
type RuleError struct {
Err error
}
RuleError identifies a rule violation. It is used to indicate that processing of a transaction failed due to one of the many validation rules. The caller can use type assertions to determine if a failure was specifically due to a rule violation and use the Err field to access the underlying error, which will be either a TxRuleError or a ruleerrors.RuleError.
type TxRuleError ¶
type TxRuleError struct {
RejectCode RejectCode // The code to send with reject messages
Description string // Human readable description of the issue
}
TxRuleError identifies a rule violation. It is used to indicate that processing of a transaction failed due to one of the many validation rules. The caller can use type assertions to determine if a failure was specifically due to a rule violation and access the ErrorCode field to ascertain the specific reason for the rule violation.
func (TxRuleError) Error ¶
func (e TxRuleError) Error() string
Error satisfies the error interface and prints human-readable errors.
Source Files