Pattern · Experimental

Threshold keys

Give each app role one FROST group key. Any t of n members can sign for the role. The chain sees one usual spend signature.

Problem

An Orchard-protocol spend examines one signature under one key ak. Thus, shared control of a note must be inside the key.

An app often has roles: a treasury, a registry or a guard. One person with one key is a weak point for each role. The person can lose the key, a thief can take it, or the person can be away when the app must sign.

Zcash applies nLockTime only to transactions with transparent inputs. Thus, for a shielded note, the structure of the signers is the only path to liveness.

Mechanism

members 1, 2, 3 ── 2-of-3 ──→ group key A_G
                                  │
object id ──→ public tweak t ─────┤
                                  ▼
                       object group key A_G + [t]G ─┐
                                                    ├─ 2-of-2 ──→ ak ──→ address of the object
owner share A_O ────────────────────────────────────┘

1. One group key for each role

1. The n members of a role make a FROST key over RedPallas (ZIP 312). Use a distributed key generation (DKG). Then no person holds the full secret.
2. The group key is the ak of the role account. Each role has its own ak, nullifier key and commit-ivk randomness.
3. To spend, a coordinator makes a PCZT. Each member examines the transaction on its own and calculates the sighash.
4. Any t members sign in two rounds. The PCZT gives the randomizer α, so the signature verifies under rk = ak + [α]G.

The coordinator holds zero shares. The role continues while t members are available. A share refresh changes the members and keeps the group key.

2. A public tweak for each object

Some apps need one key for each object: each title, each deed, each account. A public tweak gives each object its own key:

t          = ToScalar(BLAKE2b-512(domain, object id))
object key = A_G + [t]G

• Anyone can calculate the object key from the group key and the object ID.
• The members stay offline when the app registers a new object.
• Each object has its own address. Outsiders see unrelated shielded addresses.
• To sign for an object, the group adds t to its secret. The coordinator adds the public term one time.

3. A group inside a 2-of-2 key

An object can need two parties: an owner and a group. For example, the owner moves the object, and the group examines each move for the rules of the app. Make a FROST 2-of-2 key. The owner is identifier 1. The group is identifier 2:

ak = ±([2]A_O − (A_G + [t]G))

The coefficients 2 and −1 come from Lagrange interpolation at zero over identifiers 1 and 2. Orchard requires an ak with sign bit 0. When the sign bit is 1, both sides negate their shares.

The group signs as one participant of the outer round:

1. Each chosen member sends the hash of its nonce commitments. Then each member shows its commitments.
2. The outer commitment of the group is the sum of the member commitments.
3. Each member calculates its answer from the outer round:

   z_j = d_j + ρ₂·e_j + λ₂·c·(±μ_j·σ_j)

   ρ₂, c and λ₂ are the binding factor, the challenge and the Lagrange coefficient of identifier 2. μ_j is the Lagrange coefficient of the member in the group. σ_j is the share of the member.
4. The coordinator examines each answer against the verifying share of the member. A bad answer identifies its member.
5. The coordinator adds the answers and the public term λ₂·c·(±t + α). The result is the share of identifier 2.
6. The owner signs as identifier 1. A usual FROST aggregate makes the spend signature.

The owner must prove possession of its share. A dishonest owner can choose A_O from the group key, and then know the full secret of ak. The proof of possession stops this attack.

Cost

• Chain. Zero. The spend has one usual RedPallas signature. To outsiders, it looks like a spend with one key.
• Rounds. Two FROST rounds. A nested group adds one hash round before the commitments.
• Liveness. t members must be online for each spend.
• Keygen. One DKG for each role. A new object uses its public tweak, with zero keygen.

Limits

• Audit. FROST on the Ironwood pool is unaudited. ZIP 312 is a draft. The nested construction follows the recipe of the frostito crate, and it needs review.
• Trust. A group is one unit of trust. t bad members are a bad role.
• Refusal. If all members refuse, the object stays frozen. The remedy is outside the chain, for example in law.
• Coordinator. Each member must examine the request on its own. Each member must also sign the set of commitments that it saw, so that the coordinator shows the same set to each member.

Spec

ZIP 312 specifies FROST for spend authorization. This page is a design note for the tweak and the nested group, for experiments only.

Demo: a deed with a guard group

A toy registry gives each deed its own key. The owner holds one side. A guard group of three members holds the other side, and any two of them sign. The demo uses the reddsa crate (RedPallas FROST), compiled to WebAssembly. A trusted dealer makes the demo keys from a random seed. A real group uses a DKG.