by Kiara Bickers

What is Federated E-Cash?

An E-Cash Federation is an entity consisting of independent members that come together to create a multi-sig wallet for the purpose of being a blind, distributed custodian by acting as an e-cash mint. E-Cash was first introduced several years before Bitcoin, in David Chaum’s 1983 paper, “On Blind Signatures for Untraceable Payments”. The underlying coins of the E-Cash Federation are held in a Bitcoin multi-sig wallet, assuming sufficient honest members in the federation this means depositors’ funds can not be stolen, frozen, or otherwise controlled except by the rules of the federation.

Although the entity resembles a bank, this idea is not re-creating the financial monoliths that exist today, rather it’s enabling individuals to come together to form trust-minimized and blind custody agreements, using blind signatures in such a way that improves the privacy and usability for bitcoin.

What are the privacy properties of Federated E-Cash?

The mint accepts deposits and blindly issues an IOU or redeem receipt that can then be exchanged for bitcoin at the mint. These receipts can also be traded between mint users. The issuance (i.e. signing) is “blind”, meaning that the mint can not tell to whom a redeem receipt was issued when it is spent again. The use of blind signatures in an E-Cash Mint grants users strong privacy properties. When correctly implemented, the mint operators do not know the identities of their users, their balances, or transaction histories.

How do blind signatures work?

The aim of this blind signature scheme is to allow the user to acquire a signature on a message without revealing said message to the signer. Leveraging homomorphic encryption-like mechanisms, the signature can be made on obscured data without requiring access to a secret (decryption) key.

Message data is obscured with a blinding key by the user, and the resulting blind data is given to the signer (1). This signer then generates a blind signature for the data and returns it to the user (2).

Due to the homomorphic properties of the blind signature scheme the user can now unblind the received blind signature to receive a valid signature for the original message (3). Because a signature is only valid in relation to a message, the signature proves that the user sent a message to the signer, without the signer knowing the contents of the message. The user can now pass on their unblinded message with the signature to any validator to prove they have a valid signature for their message (4).

But this explanation is only presenting the general case for blind signatures. The goal is to use blind signatures as a tool for blindly depositing bitcoin with a federation.

How are blind signatures applied to Federated E-Cash?

For the minting to be blind all redeem receipts have to be indistinguishable. But naively embedding the value being sent in the receipt would destroy the blindness property since unique values would become distinguishable. Instead, blindly-signed receipts of equal value could be used, using multiple receipts to represent larger values. Assuming a value of 1sat per signature this would mean the mint must sign 10 messages in exchange for receiving 10sats. But this clearly is not scalable. Issuing 1 BTC worth of redeem receipts would mean generating 100’000’000 signatures.

This problem is solved by introducing multiple amount tiers, meaning the mint can issue tokens worth different amounts with different keys. While this technically reduces the anonymity set it should not be a problem for a mint with sufficient users. A more elegant solution would be embedding blinded amounts in the tokens, but this appears to be an open research problem in the federated setting.

The main three types of transactions that are possible inside the mint are:

• Deposits/Issuance: The user sends money to the federation and receives the equivalent amount of redeem receipts in return.
• Withdrawals/Redeems: The user sends redeem receipts and a bitcoin address to the mint and asks it to send the corresponding amount to the address.
• Internal Transactions: A payer gives a redeem receipt to the payee. The payee sends these to the mint, validating that the payer is not attempting to double spend them. If the receipts are unspent the mint issues new ones to the payee.

Deposits to the Federated Mint

When deposits are made to the federation, the mint returns a redeem receipt. Each such redeem receipt consists of a nonce and a signature. At the beginning of the issuance protocol, the user generates a random nonce (1), the only requirement of which is to not have been used before since nonces are used to track spending, and re-using a nonce would make the newly issued receipt worthless.

Since the user wants to acquire a signature on the nonce without showing it to the mint it initiates a run of the blind signature protocol explained above, encrypting the nonce (2) and decrypting the blind signature received from the mint (6). At the end of the protocol, the user has a unique and random nonce signed by the mint, a.k.a. a redeem receipt (7), without the mint being able to connect the issuance operation to it.

Withdrawals from the Federated Mint

To withdraw bitcoin the user submits their redeem receipt to the mint which checks the nonce provided against the federations ledger of spent nonces (1). If the redeem receipt is valid, and the nonce hasn’t been spent, the user’s nonce is entered into the mints existing list of nonces and the value deposited can be used to fund transaction outputs to withdraw the BTC (2).

Due to the blindness property of the signing protocol used to issue the receipts, each such transaction is disconnected from the preceding one.

Internal Transactions

It is also possible to combine a redemption transaction with an issuing transaction, leading to an entirely internal transfer. In the beginning, such a transaction works a lot like a withdrawal, the user gives redeem receipts (they e.g. received as payment) to the mint which checks them against the nonce ledger for validity. But instead of requesting bitcoin in exchange, the user chooses to request new redeem receipts. The only observation the mint is able to make is the size of the transaction (not even that if the payment is split). Since both the spent receipts as well as the newly issued ones were issued blindly the transaction graph is completely hidden.

How does Federated E-Cash help scale Bitcoin?

It is still early days for Bitcoin: scaling solutions like the Lightning network and federated sidechains make paths for large-scale adoption of Bitcoin all the more possible. Federated blind mints are a natural complement to these existing scaling solutions.

One exciting possibility is integrating Lightning into federated mints, making them interoperable with each other and the wider ecosystem. This would make a mint a trust-minimized and private Lightning wallet for users not able or willing to run their own Lightning node.

One could imagine the emergence of community-run federations, where users have a natural trust in the federation members, which isn’t the case with traditional custodians. For the larger number of Bitcoin users who rely on custodial wallets to store their bitcoin, switching to an E-Cash Federation, reduces the trust profile and increases the privacy guarantee for these users.

MiniMint is an experimental implementation of a Federated E-Cash scheme in development. The project lives under the FediMint repository, where individuals working on similar concepts can collaboratively build and discuss Federated E-Cash on Bitcoin.

Note: This blog was originally posted at https://medium.com/blockstream/blockstream-sponsors-federated-e-cash-as-a-bitcoin-scaling-technology-637ba05de7b3