[Jossec101]

Why

Parties lose shares: a disk dies, a server or enclave gets replaced, a backup turns out to be bad. Today the only fix is a new DKG. That means a new key, new addresses, and moving every coin on chain. If enough parties lose their shares before that happens, the funds are gone.

Repair brings the lost party back under the same key, so nothing changes on chain.

The refresh is needed for two reasons:

• The rebuilt share has no pairwise OT setup, so it can't sign until a refresh runs.
• It gives every share new randomness, so any old share that leaked becomes useless.

What

• Each helper (at least t parties that still have a share) sends the lost party one masked term, to that party only. The masks cancel out, so the party learns its own share and nothing about the helpers' shares.
• The party adds up the terms and checks the result against its verifying share in the public key package. If they don't match, it stops.
• Signing refuses a share that has no OT state.
• A complete refresh across all n parties gives every share new randomness and new OT state. The group key stays the same.
• C API: tss_repair_helper_term, tss_repair_assemble, tss_refresh_new_dkls, plus Go bindings.
• secp256k1 only for now. Uses only DKLs23's public API, so DKLs23 needs no change.
• Tests in Rust, the FFI and Go. Spec pages updated.

Depends on

#7, for chain_code(). Review the last two commits.

[n0xena]

Is there any particular reason why this only works with secp256k1 and not with secp256r1/nist p256?

[canesin]

Placement: the repair protocol belongs in DKLs23, with libtss keeping the handle, C API and bindings. Target DKLs23 0.7.0.

Why:

• It is a cryptographic protocol, not orchestration. Here it builds Party { .. } field by field, reads zero_share.seeds, and models a hollow share as empty multiplication maps. That couples libtss to DKLs23 internals and limits it to secp256k1.
• In DKLs23 it becomes curve-generic, sits next to refresh, and is reviewed with the protocol.

Design reviewed; it is sound:

• Masked Lagrange terms with zero-sum masks from the pairwise zero-share seeds; the target learns only the sum.
• The assembled share must match the target's verifying share.
• A complete refresh across all n parties is required before the share can sign.

Required in the DKLs23 version:

• Target authorization is a hard contract. Repair hands party k's share to whoever is accepted as party k. If the real party k still exists, an impostor gains a second share, lowering the effective threshold by one. Document it as a precondition, and require the refresh before trusting the repaired share.
• ZeroShare::compute silently skips counterparties without a seed. You guard against this; DKLs23 should return an error instead.

Suggest keeping this as a draft. I will port the protocol into dkls23-core (protocols::repair) based on your design, with you as co-author; this PR then becomes the binding layer.

@Jossec101 : Another option I am thinking of is adding repair support as a new function instead of adding into ZeroShare and than doing another 0.6.x release together with other improvements, since nobody should be using 0.6.x so far (just pushed it) might not be worth it and instead we go straight into 0.7 with the ideal interfaces.