Transaction Size and Fees

Tidecoin fee estimation must account for post-quantum public keys and signatures. The fee rule is still Bitcoin-like: pay by virtual size. The difference is that the witness stack is much larger, especially for ML-DSA schemes.

This page is an integration guide. The canonical transaction layout is Transactions, and the canonical signature layout is Signature Encoding.

Core formula

Use the standard weight and virtual-size model:

weight = stripped_size * 4 + witness_size
vbytes = ceil(weight / 4)
fee = vbytes * feerate_per_vbyte

Do not estimate Tidecoin transactions by copying Bitcoin ECDSA input sizes. Calculate from the actual script and witness stack.

Signature and public-key sizes

Only Falcon-512 is mainnet-active before AuxPoW. Other schemes are built but mainnet-gated by AuxPoW activation.

Approximate witness-v0 key-hash input sizes

For a witness-v0 key-hash style spend with stack:

<signature+sighash> <prefixed_pq_public_key>

Approximate per-input size is:

These numbers assume a 41-byte stripped input component and compact-size length prefixes for the two witness stack items. They are sizing aids, not a substitute for calculating the final signed transaction.

Output sizes

Output amounts and CompactSize prefixes add their normal serialized overhead. Final transaction size must include version, marker/flag where witness is present, input count, output count, locktime, and all scripts.

Relay policy constants

Default policy values:

Operators can change some policy values locally. Integrations should query their own node state and handle sendrawtransaction rejection messages rather than assuming every peer has identical policy.

Dust

Dust is calculated from the cost to spend an output at the node’s dustrelayfee. Tidecoin uses the same policy concept as Bitcoin Core, but PQ public keys and signatures can raise spend costs for outputs that require PQ material to spend.

Use the node or wallet to construct and test transactions when possible. For custom systems, mirror GetDustThreshold() and IsDust() from ../tidecoin/src/policy/policy.cpp.

Recommended integration workflow

1. Build the transaction with the wallet or signing stack that will actually sign it.
2. Sign or simulate signatures using the intended scheme.
3. Compute the final virtual size from the signed transaction.
4. Query estimatesmartfee for the target confirmation window.
5. Compare against local minimum relay and mempool minimum fees.
6. Run testmempoolaccept before broadcast for externally built raw transactions.
7. Broadcast with sendrawtransaction, setting maxfeerate explicitly if your transaction is intentionally large.

Worked fee example

For one Falcon-512 witness-v0 key-hash input and two witness-v0 key-hash outputs, a rough sizing model is:

base transaction overhead: about 12 vB
1 input: about 434 vB
2 outputs: about 2 * 31 vB
estimated total: about 508 vB

At 2 atoms/vB, that transaction needs about 1,016 atoms in fees. At 10 atoms/vB, it needs about 5,080 atoms. Always replace this estimate with the final signed virtual size before broadcast.

Source of truth

See also: Learn / Fees and Transaction Sizes, Exchange Integration, Protocol / Transactions.