login
In some cases, transactions may be rejected by the network despite the fact that they successfully unlock their inputs, spend valid UTXOs, and do not conflict with other transactions.
That is, a node may receive the transaction and consider it valid, but it may choose not to relay it to its peers or reject it outright.
In particular, custom, or non-standard, transactions are often treated this way by the Bitcoin Cash network at large.
Custom transactions are defined as those which are not considered standard.
Standard transactions are those that:
((scriptLength + 60) / 43) SigChecksBe aware, however, that these rules may vary from node-to-node as they are often configurable.
Some nodes may also accept and relay non-standard transactions.
For this reason, among others, it is always wise to send transactions to multiple nodes.
The transaction input scriptSig limit must be less or equal to 1650 bytes to be considered standard. The rationale for the number 1650 byte limit was described in the code base as:
Biggest ‘standard’ txin is a 15-of-15 P2SH multisig with compressed
keys. (remember the 520 byte limit on redeemScript size) That works
out to a (15*(33+1))+3=513 byte redeemScript, 513+1+15*(73+1)+3=1627
bytes of scriptSig, which we round off to 1650 bytes for some minor
future-proofing. That’s also enough to spend a 20-of-20
CHECKMULTISIG scriptPubKey, though such a scriptPubKey is not
considered standard)
The data output size limit is calculated as follows:
OP_RETURN op codeIn HF-20210515 this size limit was kept the same but allowed to apply to any number of data outputs in the transaction, provided the total size of data output locking scripts does not exceed the limit.
For example, a transaction is now allowed to have three locking scripts that are each 74 bytes in length.
However, a transaction with two data outputs each with 112-byte locking scripts would be invalid as 112 * 2 = 224 exceeds the 223-byte limit.
In order to limit the propagation of transactions with limited utility, outputs that would be cost-prohibitive to spend are rejected as “dust.”
Dust is defined differently for different node implementations but in the simplest cases a threshold of 546 satoshis is used.
Outputs with fewer satoshis than the dust threshold are rejected, along with the transaction they are a part of.
The exception to this is provably unspendable outputs (e.g. data outputs), which always have a dust threshold of zero satoshis.
bchd provides the following comment regarding its dust calculation:
The output is considered dust if the cost to the network to spend the
coins is more than 1/3 of the minimum free transaction relay fee.
minFreeTxRelayFee is in Satoshi/KB, so multiply by 1000 to
convert to bytes.Using the typical values for a pay-to-pubkey-hash transaction from
the breakdown above and the default minimum free transaction relay
fee of 1000, this equates to values less than 546 satoshi being
considered dust.
Bitcoin ABC provides the following description of its dust threshold calculation:
“Dust” is defined in terms of dustRelayFee, which has units
satoshis-per-kilobyte. If you’d pay more than 1/3 in fees to spend
something, then we consider it dust. A typical spendable txout is 34
bytes big, and will need a CTxIn of at least 148 bytes to spend: so dust
is a spendable txout less than 546*dustRelayFee/1000 (in satoshis).
Bitcoin Unlimited uses a static threshold of 546 satoshis (except provably non-spendable outputs which are zero).
Bitcoin Verde performs a similar calculation to Bitcoin ABC but with two differences:
This is accompanied by the comment:
For the common default _satoshisPerByteFee (1), the dust threshold is 546 satoshis.