DA-03 · LESSON 08

Fees, signature checks, and control blocks

KEY DEFINITIONS

Terms used in this lesson

Control block: Proof data showing that a revealed script was committed inside a Taproot output.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
Taptree: The Merkle tree of alternative scripts committed inside a Taproot output.
Preimage: The original secret data whose hash equals a previously committed value.
Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.
Taproot: A Bitcoin output and spending design that can combine a public-key path with privately committed alternative scripts.
Outpoint: A transaction ID plus output number that identifies one exact prior output.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.

Ducat estimates transaction weight from inputs, outputs, witnesses, signatures, price commitments, and taptree depth.

65 min Difficulty 4/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · ducat vaultA Ducat action moves one Bitcoin-anchored vault state to a successorSelect any state to inspect its exact role.

RELATIONSHIP MAPInputs, rule, and outputs

01
PREDECESSORCurrent vault outpoint
The current Bitcoin output anchors collateral and identifies the state being spent.
02
REQUESTFees, signature checks, and control blocks
The Fees, signature checks, and control blocks workflow proposes one exact action and successor state.
03
POLICYProfile, oracle, signatures
Applicable policy, price evidence, authorization, and transaction shape are checked.
04
BITCOIN SPENDScript-valid transaction
Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules.
05
SUCCESSORNew outpoint and state
Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

Rule shown: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state.

STAGE 1 OF 5PREDECESSOR: Current vault outpoint

The current Bitcoin output anchors collateral and identifies the state being spent.

Governing relationship: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state. Complete path: 1. PREDECESSOR, Current vault outpoint. The current Bitcoin output anchors collateral and identifies the state being spent. 2. REQUEST, Fees, signature checks, and control blocks. The Fees, signature checks, and control blocks workflow proposes one exact action and successor state. 3. POLICY, Profile, oracle, signatures. Applicable policy, price evidence, authorization, and transaction shape are checked. 4. BITCOIN SPEND, Script-valid transaction. Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules. 5. SUCCESSOR, New outpoint and state. Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

1. State transitionWhat exists, what changes, and what results

BEFORE

Compare 280-vB key-path and 390-vB script-path spends at 11 sat/vB. Required practice derives different sizes.

MECHANISM

Version, locktime, input outpoints, sequences, and outputs contribute non-witness bytes at full weight.

AFTER

Only unused leaves stay hidden; the chosen path's complete serialized witness affects weight. Required practice uses a separate server-executed vector.

Text equivalent: Starting from Compare 280-vB key-path and 390-vB script-path spends at 11 sat/vB. Required practice derives different sizes. The mechanism begins when Version, locktime, input outpoints, sequences, and outputs contribute non-witness bytes at full weight. The resulting lesson is Only unused leaves stay hidden; the chosen path's complete serialized witness affects weight. Required practice uses a separate server-executed vector.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Count base transaction weight

Version, locktime, input outpoints, sequences, and outputs contribute non-witness bytes at full weight.

Complete path: 1. Count base transaction weight: Version, locktime, input outpoints, sequences, and outputs contribute non-witness bytes at full weight. 2. Add witness components: Wallet and Guardian signatures, scripts, preimages, and control blocks contribute discounted witness weight. 3. Price the full package: Multiply target satoshis per virtual byte by estimated virtual size, include both parent and child when applicable, and round any fractional result up to a whole satoshi. 4. Recheck policy: Actual serialized size, relay minimums, ancestor policy, and changing mempool conditions can invalidate a stale estimate.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The worked case executes the named inputs and checks in the displayed order. Actual serialized size, relay minimums, ancestor policy, and changing mempool conditions can invalidate a stale estimate.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Only unused leaves stay hidden. The chosen path's signatures, script, control block, and other witness items still affect weight.

Important distinction: Taproot makes every Ducat action the same size because unused script leaves stay hidden. Only unused leaves stay hidden. The chosen path's signatures, script, control block, and other witness items still affect weight.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Actual serialized size, relay minimums, ancestor policy, and changing mempool conditions can invalidate a stale estimate. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Only unused leaves stay hidden. The chosen path's signatures, script, control block, and other witness items still affect weight.

Loading lesson visuals...

Learn the idea

Transaction fees equal input value minus output value. Bitcoin weight counts each non-witness byte as four weight units and each witness byte as one. Virtual size is weight divided by four and rounded up; one virtual byte is the resulting fee-pricing unit. A target fee in satoshis is virtual size multiplied by satoshis per virtual byte and rounded up again to a whole satoshi. Signature checks and Taproot control blocks add witness weight, so Ducat builders estimate the complete action rather than counting only ordinary inputs and outputs.

GUIDED EXPLANATION1/4 ideas inspected

Count base transaction weight

Version, locktime, input outpoints, sequences, and outputs contribute non-witness bytes at full weight.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Taproot makes every Ducat action the same size because unused script leaves stay hidden.”

Only unused leaves stay hidden. The chosen path's signatures, script, control block, and other witness items still affect weight.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.