# StarkNut 🐺 🥜 - STARK proofs for Cashu protocol.

*Particular thanks to [Calle](https://x.com/callebtc) for insightful discussions on the current state of Cashu (mainly concerning it's trust assumptions) and also brainstorming on potential applications of STARK proofs to improve it.*

Hey fellow cypherpunks and Bitcoin enthusiasts! Today, I want to dive into an exciting idea that's been bouncing around in my head lately - using STARK proofs to potentially improve the Cashu protocol. But before we get into the nitty-gritty, let's set the stage a bit.

## The Cashu Lowdown

Cashu is a free and open-source Chaumian ecash protocol built for Bitcoin. It's starting to get some decent traction in the Bitcoin landscape.
BTW, I really love the back story of the creation of blind ecash scheme as described in this [Gist by Ruben Somsen](https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406).
Basically he explains that he came with this idea by digging a [cypherpunk mailing list post by David Wagner from 1996](https://cypherpunks.venona.com/date/1996/03/msg01848.html).


I find this extremely based. Cypherpunk spirit FTW!

Anyway, afer seeing more people in the Bitcoin ecosystem talking about it, I wanted to test it and I have to admit that I really liked the experience from a user point of view.
It's smooth and very fast.
I used [Cashu.me](https://wallet.cashu.me/) wallet and the experience was very pleasant.
However, we cannot deny the fact that Cashu comes with very serious and problematic trust assumptions.

## The Trust Tightrope

Here's the deal: at its core, Cashu is a custodial system with some nifty privacy features. The mint (the entity issuing the ecash) holds all the Bitcoin, which means users are putting a lot of trust in that mint. Sure, the mint can't distinguish between users, which is great for privacy and prevents censorship. But security-wise, it's an all-or-nothing game - the mint could potentially steal Bitcoin from all users or none at all.

**Core Protocol:**
- Cashu is fundamentally a classical Chaumian E-cash protocol.
- The mint holds complete control over the Bitcoin, rendering Cashu a custodial system with privacy features.

**Privacy and Security:**
- The mint issues ecash to its users and maintains privacy by not being able to distinguish between users. This inability ensures non-discrimination and prevents censorship of individual users.
- Security-wise, the mint has the capability to either steal Bitcoin from all users or from none.

**Ecash Management and Transaction Process:**
- Users receive old ecash swapped for new blind signatures, which they convert into ecash through a process called unblinding.
- Ecash enables users to conduct irreversible peer-to-peer transactions.
- Transactions are executed off-band, meaning they occur directly between users without interference from the mint, which cannot prevent any ecash transfers between users.

## Enter STARK Proofs


This is where things get exciting. What if we could create a mint that could be penalized if it doesn't play by the rules? That's where STARK proofs come in.

The ultimate goal for enhancing the Cashu system is to create a mint that can be penalized if it fails to act according to user expectations. This raises the possibility of integrating a STARK proof into the swap operation as well. In such a setup, a user would input a Cashu token and request another blind signature in return. Incorporating a proof system into Cashu’s cryptographic framework, or at least exploring the feasibility of adding STARK proofs, could ensure that the mint remains accountable and possibly subject to penalties, thereby encouraging honest behavior. If feasible, this integration could mark a significant leap forward, transforming the reliability and security of the protocol.

Before implementation, thorough research must be conducted to assess the feasibility of integrating STARK proofs into Cashu. This research should focus on:

- Feasibility Studies: Examining the technical and cryptographic challenges associated with integrating STARK proofs.
- Impact Analysis: Understanding how these proofs could affect transaction speed, user privacy, and overall system scalability.
- Retro compatibility / Breaking changes: Analysing the potential breaking changes for the Cashu ecosystem and tooling. See how versioning can be handled and how to seemlessly integrate STARK proofs into the mix with minimal changes.

It's of course early to determine precisely a design that would reduce trust assumptions of Cashu protocol using STARK proofs, but it feels that it's worth exploring more this idea and collectively brainstorm around it.

## Bonus: Making Cashu ZK-Friendly

Let say we could change the Cashu protocol to consider making it more ZK friendly. In this section I want to think about what changes could make the protocol more efficient and practical in a ZK context.

### Using ZK friendly hash functions

The Cashu protocol uses heavily SHA256 hash function. While it's nowadays possible to generate quite efficient proofs for this hash function, it could be interesting to think about potentially moving to ZK friendly hash functions like Poseidon for example. This would enable faster and cheaper generation of proofs.

### Rework the ways data are formatted / serialised

Potentially reworking the ways the points and data are used on the protocol could greatly improve the efficiency on a ZK context.
For example, there is some use of string format for public keys in some parts of the BDHKE scheme.

Example in the `hash_e` function from Nutshell implementation.


In this example we can see that public keys are serialised and concatenated together, then the result of the concatenation is UTF-8 encoded and then hashed.
Maybe we should consider using raw points coordinates and avoid passing through string representation for greater efficiency of proof generation.

Anyway, those are honestly details at this point and not very important.

Let's adopt a: `Make It Work, Make It Right, Make It Fast` approach.

Also, as [Calle](https://x.com/callebtc) pointed out, since the whole logic happen offchain, the efficiency does not have to be the utmost priority.

## BDHKE in Cairo proof of concept

I've actually started tinkering with implementing the BDHKE scheme (the backbone of Cashu's cryptography) in Cairo. It's just a proof of concept for now, but it's a start! If you're curious, you can check out the code [here](https://github.com/AbdelStark/bdhke-cairo).
So far, I've got the first step of the protocol working - blinding secret messages. It's fully compatible with the Nutshell reference implementation, which is pretty cool. Next up, I'm thinking about implementing the full scheme and running some benchmarks.


Look, I know this is all pretty theoretical right now. But I can't help but get excited about the possibilities. Integrating STARK proofs into Cashu could potentially address some of its biggest weaknesses while preserving its strengths.
What do you think? Is this something worth exploring further? I'd love to hear your thoughts and maybe even collaborate on this.

Stay cypherpunk, my friends!

My Nostr public key: `npub1hr6v96g0phtxwys4x0tm3khawuuykz6s28uzwtj5j0zc7lunu99snw2e29`



## Resources

- [NUTS - Cashu Protocol Specifications](https://github.com/cashubtc/nuts)
- [Cashu documentation](https://docs.cashu.space/)
- [Cashu presentation by Gandalf](https://lconf.gandlaf.com/)
- [BDHKE in Cairo Github repository](https://github.com/AbdelStark/bdhke-cairo)