Transaction Lifecycle

This page traces the complete journey of a BTQ transaction from creation through confirmation, highlighting how Dilithium signatures change each step compared to a standard Bitcoin transaction.

Overview

A BTQ transaction follows the same fundamental flow as a Bitcoin transaction:

Create → Sign → Broadcast → Validate → Include in Block → Confirm

The key differences are in the signing step (Dilithium instead of ECDSA), the size of the resulting transaction, and how the script interpreter determines which signature algorithm to verify.

Step 1: UTXO Selection

Every transaction begins by selecting which unspent outputs (UTXOs) to spend. Each UTXO represents coins received in a previous transaction that have not yet been spent.

When constructing a transaction, the wallet:

1. Identifies UTXOs controlled by the user's keys (either ECDSA or Dilithium)
2. Selects enough UTXOs to cover the desired payment amount plus fees
3. Creates a "change" output returning any excess back to the sender

The UTXO selection process is identical to Bitcoin's. The wallet may optimize for fee efficiency by preferring fewer, larger UTXOs to minimize the number of inputs (and therefore signatures) needed.

Step 2: Transaction Construction

A BTQ transaction has the same structure as a Bitcoin SegWit transaction:

Transaction Components

The Witness Structure for Dilithium

For a Dilithium SegWit transaction (P2DWPKH), each input's witness contains two items:

Compare this to an ECDSA SegWit transaction (P2WPKH):

The witness data is the primary reason Dilithium transactions are larger. However, because witness data is segregated, it benefits from the witness discount and can be pruned by nodes that don't need historical signature data.

Step 3: Signing

Sighash Computation

Before signing, the wallet computes a sighash -- a hash of the transaction data that the signature commits to. BTQ uses the BIP-143 sighash algorithm (the same one Bitcoin uses for SegWit transactions), which hashes specific portions of the transaction depending on the sighash type.

Sighash Types

These types are identical to Bitcoin's. The sighash type byte is appended to the Dilithium signature, producing the final 2,421-byte signed value.

The Signing Process

1. The wallet computes the sighash for each input
2. For each Dilithium input, the wallet uses the private key to produce a 2,420-byte Dilithium signature over the 32-byte sighash
3. The sighash type byte is appended to the signature
4. The signature and public key are placed in the witness section

Deterministic Signatures

Dilithium signatures are deterministic: the same private key and message always produce the same signature. This eliminates an entire class of vulnerabilities related to random number generation during signing (a problem that has caused real-world ECDSA key compromises in the past).

Step 4: Broadcast

The signed transaction is broadcast to the peer-to-peer network using the standard Bitcoin P2P protocol:

1. The originating node sends an inventory message announcing the transaction by its hash
2. Peers that don't have the transaction request it with a getdata message
3. The originating node sends the full transaction
4. Each receiving peer validates the transaction independently before relaying it further

Dilithium transactions are larger, so they consume more bandwidth during propagation. However, the P2P protocol handles this transparently -- there is no special handling for Dilithium transactions at the network layer.

Step 5: Validation

When a node receives a transaction, it validates it before accepting it into its mempool (the pool of unconfirmed transactions). Validation involves several checks:

Input Validation

• Each referenced UTXO must exist in the current UTXO set
• Each UTXO must not have been previously spent
• The transaction's total input value must equal or exceed its total output value (the difference is the fee)

Script Execution

For each input, the node executes the script that locks the corresponding UTXO. This is where auto-detection occurs.

Auto-Detection: Dilithium vs ECDSA

The script interpreter examines the public key provided in the witness:

• If the public key is larger than 100 bytes, it is treated as a Dilithium public key and verified using Dilithium2 verification
• If the public key is 100 bytes or smaller, it is treated as an ECDSA public key and verified using standard ECDSA verification

This size-based detection works reliably because Dilithium public keys are 1,312 bytes and ECDSA compressed public keys are 33 bytes -- the two ranges don't overlap.

Signature Verification

For a Dilithium input, verification proceeds as follows:

1. Extract the 2,421-byte signature from the witness (2,420-byte Dilithium signature + 1-byte sighash type)
2. Extract the 1,312-byte Dilithium public key from the witness
3. Recompute the sighash using the same algorithm the signer used
4. Verify: does Dilithium2.Verify(public_key, sighash, signature) succeed?
5. Verify: does Hash160(public_key) match the key hash in the UTXO's scriptPubKey?

If all checks pass, the input is considered valid.

Mempool Policy

Beyond consensus validity, the mempool enforces additional policy rules:

These policy rules are configurable by node operators and are not part of consensus (blocks containing transactions that violate policy rules are still valid if they pass consensus checks).

Step 6: Block Inclusion

Miners select transactions from the mempool to include in the next block:

Transaction Selection

Miners typically prioritize transactions by fee rate (fee per unit of weight). Higher fee-rate transactions are more profitable to include. The miner assembles a candidate block that:

• Does not exceed the maximum block weight (8,000,000 weight units)
• Includes a coinbase transaction creating the block reward (5 BTQ + fees)
• Orders transactions so that any dependencies are satisfied

Weight Calculation

A transaction's weight determines how much block capacity it consumes:

This means the ~3,700 bytes of witness data in a Dilithium transaction contribute only ~3,700 weight units, while the ~100 bytes of non-witness data contribute ~1,600 weight units. The total weight (~5,300 WU) is far less than the raw size (~3,800 bytes) would suggest without the discount.

Witness Commitment

The miner includes a witness commitment in the coinbase transaction, which is a hash of all witness data in the block. This allows nodes to verify the integrity of witness data without including it in the block header's Merkle root.

Step 7: Confirmation

Once a block is mined and propagated:

1. Each node validates the block and all transactions within it
2. The block is added to the node's copy of the blockchain
3. UTXOs spent by transactions in the block are removed from the UTXO set
4. New UTXOs created by the block's transactions are added to the UTXO set
5. The transactions are removed from the mempool

Confirmation Depth

The transaction gains one confirmation when it is first included in a block. Each subsequent block adds another confirmation:

The probability of a transaction being reversed decreases exponentially with each additional confirmation, following the same security model as Bitcoin.

Transaction Size Breakdown

For a typical 1-input, 2-output Dilithium transaction:

Of this total, approximately 3,733 bytes (97%) is witness data that benefits from the weight discount.

Learn More

• Blockchain Basics - UTXO model and block structure fundamentals
• Dilithium Signatures - Detailed signature format and verification
• Scalability & Performance - Throughput and capacity analysis
• Wallet Basics - How to create and sign transactions