Using Taproot And FROST To Improve Bitcoin Privacy

A group of developers in Malaysia are working to incorporate FROST and Taproot to create federated Chaumian mints with the Fedimint protocol.

This is an opinion editorial by Dan Gould and Nick Farrow. Gould is a developer who worked on TumbleBit, PayJoin and Chaincase App and has been sponsored by Human Rights Foundation and Geyser Grants. Farrow is an Australian Bitcoin engineer best known for his open source payment processor SatSale.

“Hey, I just got an invite to this hackathon in Malaysia,” said Evan Lin, interrupting my flow over my laptop in the Taipei Hackerspace. “That sounds magic,” I snapped back. “Can I come?”

I’d been smacking my head on the desk for weeks. Lin had been tearing apart my idea of what bitcoin privacy was. “It’s a private event, not your typical hackathon. I can ask.”

One flight, two weeks, and six minutes of voice message logistics later, we were walking down durian-lined streets of Kuala Lumpur, Malaysia, with Lloyd Fournier, ruminating over a shared passion to make bitcoin privacy stick. Now we were a team. We set out to upgrade Fedimint using half-polished cryptography, some scribbled-down notes, and then demo it at the first-ever Malaysian BitDevs meetup five days later.

Fournier had joined Nick Farrow to develop FROST, a new threshold cryptography that takes advantage of Taproot, in the months prior. Being a fountain of Bitcoin human resources, Fournier had also been working closely with Lin who is a Bitcoin Dev Kit (BDK) contributor. He and I had spent the last few weeks upgrading PayJoin privacy under fluorescent lights during the wee hours in Taipei, Taiwan, so we’d established trust to jump in the deep end on a project together. Fournier’s invitation was a step to the edge. To demonstrate the cutting edge cryptography to the world, we had to put FROST in an app. Fedimint had everyone’s eyeballs for its new threshold custody model. It was fit for the quest.

Self-custody is a novel, scary concept for most people. So many people store bitcoin in third-party custody on exchanges, leaving them exposed to censorship and indecent surveillance. Federated mints offer a third way: A federation of known guardians keep community funds safe. So how does it work?

Anyone can send bitcoin to a Fedimint in exchange for E-cash tokens. The guardians share custody of the community’s bitcoin in a multisignature wallet. The E-cash tokens are just some data: blind signatures redeemable for some amount of bitcoin later. They’re superpowered banknotes. Submit a Lightning invoice and your E-cash tokens to “peg out.” You could get E-cash in a text and have the federation reissue signatures so nobody else can take it. The signatures are blinded, so it can be redeemed in total anonymity. Anyone can send E-cash to a Fedimint to get bitcoin.

In order to share custody between guardians, Fedimint uses legacy Bitcoin Script-based multisignature addresses. A threshold number of guardians sign in order to transfer funds. These funds are easy to spot on the blockchain since Script multisig writes the number of signers and the total number of guardians to the blockchain for anyone to see. Even though E-cash is anonymous, surveillance companies could identify peg-ins, peg-outs and cluster community funds. By harnessing Bitcoin’s latest upgrade, Taproot, our team solved this privacy issue by switching Script multisig to FROST.

Enter FROST

FROST (Flexible Round Optimized Schnorr Threshold) is a powerful new kind of multisig that aggregates the key shares of federation members into a joint FROST key. To spend under this key, a threshold number of members must each produce a signature share. The shares are then combined to form a single signature that is valid under the joint FROST key. Members coordinate off chain. FROST transactions are indistinguishable from regular single-party Taproot spends, and so stop the creepy surveillance. On top of that, FROST allows for flexible federations, allowing new guardians to join without coordinating every member of the federation to generate new keys again.

Our first step was to understand how the federation reached a consensus each signing round. Fedimint’s consensus algorithm can tolerate bad behavior for up to a third of the federation and still reach consensus. It took a day on the white board to decode the consensus algorithm and another to configure the initial FROST key generation.

We cheated key generation by doing it all in a single trusted device’s memory. In best practice, a two-round ceremony keeps an individual’s secret shares of the joint FROST key which only ever exists on that individual’s device. The overall secret is never reconstructed.

Coming To Consensus (Signatures)

We tested a peg-in transaction before we modified Fedimint wallet code and got perplexed. Because of a limitation of blind signatures, Fedimint E-cash tokens (akin to CoinJoin outputs), are limited to preset denominations so that each E-cash token transfer has an anonymity set. Waiting and waiting and waiting, Lin laughed that we must have messed something up.

Turns out, standard note denominations we set required the mint to generate around 300,000 signatures to issue enough E-cash to cover the peg-in amount. There are proposals to fix this by using anonymous credentials instead. We reset the mint to use much higher default denominations since we were just testing. Hackathons are for hacks, after all.

In a stroke of good luck, Bitcoiner Malaysia had just formed and was primed for their first event. Between the four of us hackers, a host of the largest Chinese bitcoin podcast and the scholar on track to earn the first Bitcoin Ph.D. in Malaysia, we planned to show our proof-of-work at BitDevs at the end of the week.

Our hardest task remained ahead of us: federated signatures. To produce a FROST share, signers must agree to common randomness, called nonces. In the case of Fedimint, the signers use consensus to agree on a unique nonce for each federation member joining a signing session. Then signing participants aggregate shares into a complete signature.

While we drafted our live demo for the meetup, we managed to get some nonce sharing semi-working and fixed some fee bugs too. Despite our hard work, dinner rolled around before our code worked. We crossed the threshold into the deepest hackathon territory huddled around the TV for triple-paired programming in Farrow’s hotel room.

An Unreal Experience

With our tapwaters ready and Unreal Tournament soundboard cranked up, Fournier sat at the keyboard, while we hurled bug fixes, variable names and commands from the back seat. 1:30 a.m. rolled around and our eyelids were heavy. A few taps later, just like magic, the peg-out worked. Each signer would receive signature shares from the others and redeem anon’s E-cash in exchange for bitcoin. “Flawless Victory” rang out of the soundboard. We cheered in disbelief.

Except it did not work. The next day we ran the code and saw problems straight away. We only got lucky the night before. It worked only once out of three or four attempts. We combed over hackathon-quality code for hours. Well after lunch, we still worried we’d have to cram in another late night. To our avail, we found the problem: a classic indexing error. At 5:00 p.m. FROSTimint was ready to present.

Once we circled up for BitDevs, locals took a self-described “support group” format for introductions. Fournier brought us back to reality with the technical. The inaugural meetup deliberated the future and foibles of custodians with delight. How would we choose guardians? Can they hold fractional reserves? Most importantly, how can my laksa noodle soup shop transcend fiat by using Fedimint?

This is a guest post by Dan Gould and Nick Farrow. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.