DA-04 · LESSON 03

Distributed key generation

KEY DEFINITIONS

Terms used in this lesson

DKG: Distributed key generation: participants create shares of a group key without one party learning the complete secret.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.

Participant-local DKG creates shares without any coordinator learning the group secret or plaintext participant shares.

55 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
REQUESTDistributed key generation
The Distributed key generation 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, Distributed key generation. The Distributed key generation 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

Use Dana, Eli, and Faye with threshold two and a separate modulo-19 polynomial g(x)=4+3x. Required practice uses another fixed group.

MECHANISM

The ceremony fixes participant identities, the required threshold, session context, and expected software or enclave measurements.

AFTER

Any identity or arithmetic failure blocks finalization and enters complaint, exclusion, or restart. Required practice uses a separate server-executed vector.

Text equivalent: Starting from Use Dana, Eli, and Faye with threshold two and a separate modulo-19 polynomial g(x)=4+3x. Required practice uses another fixed group. The mechanism begins when The ceremony fixes participant identities, the required threshold, session context, and expected software or enclave measurements. The resulting lesson is Any identity or arithmetic failure blocks finalization and enters complaint, exclusion, or restart. Required practice uses a separate server-executed vector.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Bind participants and threshold

The ceremony fixes participant identities, the required threshold, session context, and expected software or enclave measurements.

Complete path: 1. Bind participants and threshold: The ceremony fixes participant identities, the required threshold, session context, and expected software or enclave measurements. 2. Exchange commitments and encrypted shares: Participants prove consistency of secret polynomials and deliver only the intended share material to each peer. 3. Verify locally: Each participant checks received shares against public commitments before accepting its final key package. 4. Finalize inside custody boundary: The intended design seals the participant package without exposing plaintext shares to the coordinator.

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. The intended design seals the participant package without exposing plaintext shares to the coordinator.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It creates shares. No participant or coordinator should possess the complete group secret during normal operation.

Important distinction: DKG creates several backups of the complete Guardian private key. It creates shares. No participant or coordinator should possess the complete group secret during normal operation.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. The intended design seals the participant package without exposing plaintext shares to the coordinator. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It creates shares. No participant or coordinator should possess the complete group secret during normal operation.

Loading lesson visuals...

Learn the idea

Distributed key generation, or DKG, lets participants create shares of one group key without a coordinator ever receiving the complete private key. Every encrypted share must be bound to one ceremony identifier, one ordered participant set, one sender, and one intended recipient before its arithmetic is checked. Each accepted participant retains only its own final private key package, while everyone derives the same group public key.

GUIDED EXPLANATION1/4 ideas inspected

Bind participants and threshold

The ceremony fixes participant identities, the required threshold, session context, and expected software or enclave measurements.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“DKG creates several backups of the complete Guardian private key.”

It creates shares. No participant or coordinator should possess the complete group secret during normal operation.

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.