Bringing Zero Knowledge Proofs to Cashu: Arbitrary Spending Conditions

In this blog post, we explore how zero-knowledge proofs enable the exchange of ecash tokens with arbitrary spending conditions (specified by a Turing-complete programming language), without sacrificing privacy.

A Brief Overview of Cashu

The following is a high-level introduction of the protocol, for all the nuts and bolts of the cashu protocol, check out the official Cashu NUTs (Notation, Usage, and Terminology).

Cashu is a free and open source Chaumian ecash (Chaum, 1982) protocol allowing for nearly free, privacy-preserving Bitcoin transactions through digital tokens, which analogously to physical cash, are stored by users.

The Cashu protocol defines the interaction between three parties:

• The sender (Alice): transmitting their token to..
• The recepient (Carla): receiving it.
• The Mint (Bob): a third party with whom Alice and Carla can perform the following operations:
  • minting: creating cashu tokens from bitcoins sent over the lightning network
    • Alice signals to Bob that she wants to mint cashu tokens worth some amount.
    • Bob then creates a lightning invoice of that amount, which he transmits to Alice.
    • On reception of the payment, Bob blindly signs some secrets defined by Alice.
    • Alice can then create a cashu tokens by unblinding the signatures.
    • Alice can send those tokens, which are essentially the revealed secrets and their unblinded signatures to Carla.
  • swapping: creating cashu tokens from other cashu tokens
    • Carla signals to Bob that she wants to swap a tokens.
    • On verification of the token, Bob blindly signs some new secrets defined by Carla and invalidate the swapped tokens.
    • Additionally, like change for physical cash, Carla can request to split the swapped tokens to different amounts, i.e. get two blind signatures worth 16 sats each from a tokens worth 32 sats.
  • melting: getting bitcoins from cashu tokens
    • Alice signals to Bob that she would like to melt tokens.
    • She sends to Bob a lightning invoice and cashu tokens worth the requested amount.
    • On verification of the tokens, Bob pays the lightning invoice and invalidates the melted tokens.

Example: Alice sending 100 sats to Carla.

(The following example is illustrated on the cashu.me wallet.)

For a more concrete example, say Alice has a sufficiently funded cashu wallet and wants to send 100 sats worth of ecash to Carla.

1. On SEND, Alice's wallet will ensure that she posses at least 100 sats worth of tokens in her local storage. If she doesn't have change that amounts up to the target amount, then the wallet will perform a swap operation with the mint.
2. Alice then serializes the tokens.
3. Which she can send to Carla over their communication channel.
4. On RECEIVE, Carla swaps the received tokens. As stated above, the swap will have Bob invalidate the swapped tokens, and allow for the creation of new tokens with secrets defined by Carla, thus transfering the ownership of the tokens' value.

Spending Conditions

Alice may not want to send tokens that can be spent by anyone, but only to some owner of a public key. This introduces the concept of Spending Conditions.

A Spending Condition on a token allows for the swapping or the melting of that token only if a Witness satisfying the condition is provided. Meaning that if Bob provides a blind signature, then a Witness satisfying the pre-defined condition was provided.

To set a spending condition on cashu tokens, in the minting or swapping process, the secrets have to follow the Well-Known Secret format.

For example, if the condition is that Carla is the owner of some public key, then Alice's secret must follow the Pay-to-Public-Key (P2PK) Secret format.

Following our previous example, in the last step, if the deserialized token worth 100 sat contains a secrets that look like this:

then for Carla to RECEIVE, meaning swapping the tokens, she has to provide valid signatures of the secrets as a Witness. If Bob performs the swap, then all the signatures provided by Carla correctly verified with the public key specified in secret.data.

Currently only two kinds of Spending Conditions are supported in the Cashu specification (P2PK, HTLC). The implementation of new kinds of spending conditions requires the modification of a lot of moving parts, and can be quite cumbersome. To solve these issues, we introduce here a new kind of privacy-preserving, arbitrary Spending Conditions which we named Cairo Spending Conditions.

STARK-proven Computations

Cairo Spending Conditions allow for the valid execution of arbitrary Cairo programs to be set as Spending Conditions. The Witness provided by the spender is the zero-knowledge proof-of-execution of the set Cairo program with output matching the condition.

(Very) Short Introduction to Cairo, STARKs

STARK proofs are used to verify efficiently (much faster than the computation time) the correctness of a computation without revealing the input data (this property is called zero-knowledge).

Cairo is a programming language specifically designed to be used with STARK proofs, compiling human readable code to a set of polynomial evaluation constraints (the proof system works with polynomials over a large finite field Fp, the bytecode of a Cairo program is an array of values in Fp).

Let's take for example the following Cairo program fibonacci: Fp → Fp computing the n-th Fibonacci number modulo p:

Computing the following takes approximately 500ms:

We can then generate a STARK proof asserting the correctness of this computation using stwo-cairo.

Given fibonacci as bytecode, the output c, and the STARK proof, a separate verifier can assert the validity of the claim ∃n : fibonacci(n) = c without learning n nor having to run the computation, in only 50ms!

You can try the above example live at stwo-cairo.vercel.app

Now if we replace fibonacci by an implementation of the verification function for our favorite signature scheme, we get a custom P2PK condition! Let's see this it works in practice.

Cairo Spending Conditions

• Setting the condition (sender):
  When sending a token, a user can add a Cairo spending condition by specifying the hash of a compiled program and the hash of the output condition.
  The program (and potentially the output condition) has to be shared with the receiver via a separate channel.
• Spending the locked token (receiver):
  Any user who wants to spend this token will have to execute the program, match the a output condition and generate STARK proof of this computation which will be verified by the mint.

Note on Privacy

In the above setup, the mint learns about the program bytecode when a user spends a token (this is necessary for verifying the proof claim).

In situations where privacy is critical, we can make use of a bootloader together with the original program.

The bootloader is a Cairo program acting like a VM that will execute the original program and will output (program_hash, program_output).

We can now modify the spending condition as such:

• program_hash → bootloader_program_hash
• output_condition → (program_hash, output_condition)

Now the mint only needs to know the bytecode of the bootloader, and the original program is kept private from the mint at all times!

Our work

For more details, check out our NUT proposal and the typescript library we created for client-side proving of Cairo programs in the browser!

Demo Video