Network-Level Validation Rules
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:
- Only have outputs that use standard locking scripts
- Are below the maximum transaction size of 100,000 bytes
- Have a version 1 or version 2
- Have input scripts that only contain push operations
- Have input scripts with unlocking scripts less or equal to 1650 bytes in length (see scriptSig limit below)
- Have at most one data output
- For multisig outputs, must have at most 3 parties and at least 1 required party (i.e. 1-of-1 through 3-of-3).
- Have non-data outputs with amount above the dust threshold
Be 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 input scriptSig limit
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)
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:
- If the address used is uncompressed, the input size is increase to 180 bytes.
- The output length used is always 34 bytes, instead of serializing the output.
This is accompanied by the comment:
For the common default _satoshisPerByteFee (1), the dust threshold is 546 satoshis.