federating ecash — Calle | bitcoin++ Berlin, payments edition

Summary

Calle presents a design for federated Cashu eCash: replacing a single mint operator with a group of operators that jointly issue and manage eCash. He also introduces Nutroot, a Taproot-inspired way to express spending conditions for Cashu tokens.

The talk’s central lesson is that splitting signing keys among operators is not enough. A federation also needs consensus to prevent conflicting spends, and its Bitcoin reserves must be controlled under matching rules.

1. Why federate an eCash mint?

• In a conventional Cashu setup, users rely on one operator for the system’s security, even if they do not need to trust that operator with their privacy.
• A federation divides responsibility among multiple members. A chosen quorum can keep the system operating if enough members remain available and honest.
• Federation size and threshold are design choices; larger groups can be more difficult to coordinate.
• Calle argues that “we’ll decentralize later” is often a warning sign: projects that begin centralized may never make the transition.

2. Blind and threshold signatures

• Cashu uses blind signatures so a mint can authorize eCash without learning the secret underlying the token.
• Calle explains the basic idea with an envelope analogy: the wallet blinds a secret, the mint signs the blinded item, and the wallet removes the blinding factor to obtain a signature on the original secret.
• He contrasts Cashu’s existing blind Diffie–Hellman-based approach with a proposed BLS-based blind threshold signature scheme:
  • BLS signatures can be verified publicly using a public key.
  • Federation members can each produce a partial signature, which the wallet combines into one final signature.
  • The trade-off is additional computation. Calle says BLS is substantially slower—roughly 100 times slower than the existing method—but still usable.

3. Why consensus is necessary

• Threshold signatures alone do not prevent a user from presenting conflicting spends to different federation members.
• For example, a user could ask separate members to sign different sets of outputs for the same eCash input. If the members do not coordinate, their signatures might collectively authorize more value than was deposited.
• Consensus prevents this by making every member process transactions in the same agreed order. Once one spend is accepted, conflicting later spends are rejected.
• The proposed system uses AlephBFT for consensus and transaction ordering. In response to a question about reliable broadcast, Calle says that delivery alone does not establish a shared order, so consensus is still needed.

4. Sharing keys without exposing the group key

• Shamir secret sharing provides the intuition for dividing a private key into shares: a sufficient threshold of shares can reconstruct or act on the secret, while fewer shares cannot.
• However, creating a group key and then dividing it would require someone to know the full key, giving that party the power to control the federation.
• The proposed solution is distributed key generation (DKG):
  • Each member independently creates secret material.
  • Members exchange appropriate shares or points.
  • Combining these contributions produces consistent shares of a group key, without any member learning the complete private key.
• Members then use their shares to generate threshold signatures.

5. Resilience and Bitcoin reserves

• A federation can continue operating when a member goes offline, provided the remaining members meet the required threshold.
• A returning member can catch up and resynchronize with the group.
• Bitcoin backing the eCash must be protected under rules comparable to those governing eCash issuance. Otherwise, one operator might be able to run off with the reserves even if eCash issuance itself is federated.
• Calle proposes FROST, a threshold-signature system for Schnorr keys, to secure the federation’s Bitcoin wallet.
• The design includes:
  • A FROST-managed on-chain wallet using a BDK backend.
  • Bark as a Lightning backend.
  • Potential future use with other systems that support Schnorr signatures, including Taproot-based Lightning applications.

6. Nutroot: Taproot-inspired Cashu spending conditions

• Cashu tokens can carry spending conditions, such as requiring a particular public-key signature. These conditions are currently represented in a relatively simple serialized format.
• Calle proposes Nutroot, which borrows the idea of Taproot’s script tree:
  • A token’s secret is represented using a key and a commitment to possible spending conditions.
  • The conditions are organized into a Merkle-tree-like structure.
  • When spending, the user reveals the applicable condition and the proof for that path, rather than exposing every possible condition.
• Possible conditions include threshold signatures, hashlocks, and timelocks. These can support patterns such as multisignature spending or HTLC-like arrangements.
• Calle describes the Cashu structure as a static lock rather than a general-purpose stateful script system.

7. Offline transfers

• A token can be locked to a recipient’s public key before an offline transfer.
• The recipient can then possess the token and know that only they can spend it, even while disconnected.
• Later, the recipient contacts the mint and provides the required proof to unlock or redeem it. The token carries the instructions needed to determine how it can be spent.

8. Development process and readiness

• Calle says the work was built primarily with the Rust Cashu Development Kit (CDK), drawing on Cashu team specifications and cryptographic work, as well as lessons from the Fedimint team.
• He describes an AI-assisted workflow:
  • Explain the project to an AI agent, often by speaking through a microphone.
  • Turn the discussion into a detailed implementation plan with milestones and success criteria.
  • Have the AI implement the plan while he reviews, redirects, and checks its work.
  • Follow the initial build with cleanup, debugging, and optimization.
• Calle says the initial build took about seven days, followed by roughly another seven days focused on cleanup. He attributes much of the construction to GPT-5.5 and “GPT 5.6 Soul,” with Astra and “Oppos” also reviewing it.
• The federation is not ready for production, although Calle says it works.
• In response to a security question, he says he does not yet know when it will be safe to recommend handling real money. His view that AI-generated code may eventually be safer than human-written code is explicitly presented as an unvalidated assumption.

Speakers and sources featured

• Calle — main presenter; also thanked as “Kalle” at the end of the subtitles.
• Audience questioners — several attendees ask questions; their names are not given.
• Renee — thanked for an earlier chat, but not otherwise identified as a speaker in this excerpt.
• Cited project teams and contributors: the Cashu team, the CDK team, and the Fedimint team. Calle also references Eric’s discussion of federation resilience.
• AI tools named by Calle: GPT-5.5, “GPT 5.6 Soul,” Astra, and “Oppos.”