You've already forked specification
tomFlowee
8e6f78b559
In order to allow the specification to be read on a mobile phone it helps to use the standard quoting standard (staring with '>') for those paragraphs as that means they can still change their content-width and a reader doesn't end up with a paragraph wider than screen.
94 lines
4.7 KiB
Markdown
94 lines
4.7 KiB
Markdown
# 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
|
|
|
|
Standard transactions are those that:
|
|
|
|
- Only have outputs that use [standard locking scripts](/protocol/blockchain/transaction/locking-script#standard-scripts)
|
|
- Are below the maximum transaction size of 100,000 bytes
|
|
- Have a version 1 or [version 2](/protocol/forks/bip-0068/)
|
|
- 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](/protocol/blockchain/transaction/locking-script#data-output), with a script no longer than 223 bytes (see [data output size limit](#data-output-size-limit) below)
|
|
- For [multisig](/protocol/blockchain/transaction/locking-script#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](#dust) threshold
|
|
|
|
\* 223 bytes was chosen to allow for the `OP_RETURN` operation (1 byte), a push operations (2 bytes), and 220 bytes of pushed data.
|
|
|
|
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)
|
|
|
|
### Data Output Size Limit
|
|
|
|
The data output size limit is calculated as follows:
|
|
|
|
* 1 byte for the `OP_RETURN` [op code](/protocol/blockchain/script#operation-codes-opcodes)
|
|
* 2 bytes for a push operation
|
|
* Up to 220 bytes of data to be "pushed"
|
|
|
|
## Dust
|
|
|
|
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.
|
|
|
|
### Node-Specific Behavior
|
|
|
|
#### bchd
|
|
|
|
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 Cash Node
|
|
|
|
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
|
|
|
|
Bitcoin Unlimited uses a static threshold of 546 satoshis (except provably non-spendable outputs which are zero).
|
|
|
|
#### Bitcoin Verde
|
|
|
|
Bitcoin Verde performs a similar calculation to Bitcoin ABC but with two differences:
|
|
|
|
1. If the address used is uncompressed, the input size is increase to 180 bytes.
|
|
2. 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.
|