// learn · season 02 · episode 08 · finale
MPC — signing without reassembly
Episode 7 explored how a threshold policy can reduce dependence on a single signer when keys and operations are sufficiently independent. This one explores threshold signing: parties use their shares to produce a signature without reconstructing the complete private key during signing. Whether a complete key existed during setup depends on how the shares were created.
01 · splitting a secret
Two points make a line
Before any of the clever protocols, one beautifully simple idea: you can cut a secret into pieces so that some of the pieces rebuild it and fewer than that reveal literally nothing. Hold shares, set them aside, and watch.
the secret — a 120-bit number (stand-in for a private key)
…
select at least one share above
With a threshold of 2, the polynomial is just a straight line: the secret is where it crosses x=0, and each share is a point on it. Two points fix the line; one doesn't. Raise the threshold to 3 and it becomes a curve needing three points — same idea, more dimensions. This is real Shamir's Secret Sharing, the mathematics behind “any 3 of our 5 executives”, backup share schemes, and how custody platforms shard key material across data centres.
02 · the catch
Splitting isn't signing
Shamir sharing alone provides secret reconstruction, not a signing protocol. An ordinary single-key signer must reconstruct the key before using it. The model below illustrates that exposure; the next section introduces protocols that sign with shares instead.
share 1
held apart, safely
share 2
held apart, safely
share 3
held apart, safely
complete key existed on one machine
a few seconds — every single time you sign
and how often is that?
For a business paying suppliers, dozens of times a week. Each one is a fresh chance for the jackpot to be sitting somewhere an attacker can reach.
So secret sharing solves storage and leaves usage wide open. That gap — not the splitting — is the problem MPC was built to close.
03 · the resolution
Signing without assembling
Multi-party computation asks an odd question: could several parties jointly compute a signature without any of them learning the others' secrets — without reassembling the key during signing? Threshold protocols make this possible. Distributed key generation can avoid assembling a complete key during setup too; a trusted-dealer setup has different exposure assumptions.
Setup and signing are separate protocol choices. See RFC 9591 (FROST) for a concrete threshold-signing specification, including its trusted-dealer setup appendix.
illustrative choreography
Real threshold signing (GG20, FROST and friends) is multi-round cryptography with its own security proofs, and this page does not implement it. What's accurate below is the shape of the protocol: who computes what, what actually travels between parties, and what each one ends up knowing at a conceptual level. This illustration assumes a secure distributed key generation setup; no real key shares or signature are generated here. It does not represent GamBit's architecture.
Party A
your phone
holds: share 1
Party B
your laptop
holds: share 2
Party C
the custodian's HSM
holds: share 3
04 · choosing
Multisig or MPC?
Compare where each approach enforces its policy, what the chain reveals, and what operators must maintain. The right choice depends on the application, supported protocols, and recovery requirements.
| multisig | MPC / threshold signing | |
|---|---|---|
| where the rule lives | In the chain — a Bitcoin script or a smart contract enforces it. | In mathematics, off-chain. The chain sees no policy at all. |
| on-chain footprint | Several signatures, and usually a visible “this is a vault” marker. | One ordinary signature. Indistinguishable from a single-key wallet. |
| chain support | Depends on the chain — scripts on Bitcoin, contracts on EVM, varies elsewhere. | Requires a compatible signature scheme, encoding, and chain rules; a matching curve alone is not enough. |
| changing who signs | Bitcoin: move the funds to a new address. EVM: send a transaction to the contract. | Supported protocols can refresh or redistribute shares while retaining the public key and address. |
| auditability | Public. Anyone can verify the policy and see who signed — a genuine strength. | Depends on the operator's logs. The chain can't show you what happened internally. |
| who runs it | You and your co-signers, with ordinary wallets. | Usually a vendor's infrastructure — which makes vendor risk a real part of your risk. |
what custody actually is
Neither of these is “custody”. They're both just the signing layer. Real custody is what surrounds it: hardware security modules, policy engines that encode who may approve what, approval workflows, monitoring, audits, insurance, and the people who follow the procedure at 2am when it's inconvenient. Both the cryptographic implementation and the surrounding operations need careful design, review, and testing. A signing protocol alone does not establish a complete custody service.
season 02 complete
From one number to institutional custody
Season 1 built the machine: hashes, blocks, consensus, keys. Season 2 asked the only question that matters once you own something on it — how do you keep it, and hand it on? You've now written a demonstration seed phrase, simulated an offline signing workflow, tested a threshold vault model, and explored signing with shares. These are educational building blocks, not a production custody system or a place to store real assets.
Across these episodes, cryptographic mechanisms help establish what was signed and which keys may act. Succession also needs a plan for authority, access, and recovery when people become unavailable. Technical design and the surrounding arrangements must work together.
Digital assets that outlive their owners need a succession plan — designed before it's needed, tested like any other system.
That's the problem I work on →← back to all episodes