3875a16c
Sep 3, 2023

ENHANCED PRIVACY: CASHU FOR BITCOIN USING CHAUMIAN ECASH SECURITY

Cashu is a privacy-enhancing protocol that utilizes Chaumian eCash principles for Bitcoin transactions. It allows secure and anonymous handling of Bitcoin through cryptographic tokens, ensuring transactions are extremely private.
  • ORIGINAL SPEECH TITLE: CASHU: A CHAUMIAN ECASH PROTOCOL
  • SPEAKER: CALLEBTC
  • CONFERENCE: BALTIC HONEYBADGER 2023

INTRODUCTION TO CASHU FOR BITCOIN

I’m Calle, and I work on a Chaumian ecash protocol called Cashu. I want to begin by giving an introduction on Cashu for Bitcoin. I will skim over the basics of how this whole system works, and then I will point you towards some of the projects that we’ve been working on.

WHAT IS CASHU AND CHAUMIAN ECASH?

Cashu for Bitcoin is a Chaumian ecash project, and basically, the problem that we’re trying to solve is one of these two custodial risk problems:

  1. The first one is that you can be rugged (custodial risk)
  2. The second one is that you basically have no privacy (custodial risk)

The way every custodial service is built is that they must know your activity; otherwise, there is no other concept of building that service with privacy in mind unless you are using Chaumian ecash. We make use of Chaumian ecash in order to construct custodial systems that are fully unaware of what you’re doing.

OVERVIEW OF HOW CHAUMIAN ECASH WORKS

Referring to the slide above, we have our three actors: Alice, Carol, and Bob. The two users are Alice and Carol, and Bob is the Chaumian ecash mint. Alice has some ecash in her database (stored as a piece of data using a blind signature and a secret) and she wants to send money to Carol. Alice will pull up this stored ecash data from her database and just send over the ecash (using any medium).

However, to ensure the ecash isn’t double spent, Carol sends the ecash she received from Alice to Bob, the Chaumian ecash mint, for verification. Upon verifying that Alice’s original token has never been used before, Bob, the Chaumian ecash mint, issues a new token back to Carol. Carol then stores this new token in her own database, completing the transaction.

PROPERTIES OF ECASH

The essential properties of ecash and why it’s interesting is that it is basically untraceable. Returning to the earlier example, Alice sends Carol the original ecash transaction. Carol then verifies with Bob the mint that the ecash hasn’t been double spent. After verifying that Alice’s ecash sent to Carol was not double spent, Bob issues/mints new ecash to Carol in the same amount Alice originally sent. This process ‘breaks’ the transaction chain, anonymizing the sender and recipient of the ecash.

As data, Chaumian ecash is also a bearer token, meaning that since you now have a piece of data that is money (ecash), you can now do what you like with it, such as embed it into data packages, put it into requests, put it into onions, and otherwise do things with it that you are typically unable to do in a ledger-based system.

OTHER USES FOR CHAUMIAN ECASH

Some other things you can do with Chaumian ecash that you cannot do with a key-based system is push UX; imagine you take a piece of data (ecash) and you send it to your friends inbox, and that’s it, the transaction is complete, even if the friend is off-line. No need for your friend to generate an invoice and so on. In addition, using Bolt 11, we will implement a pull based transaction system as well.

We’ve also been experimenting with programmable ecash, adding complex conditions like spending conditions. We encode these conditions in a secret that undergoes blind signing. Then, you can build features like ‘pay to public key’ and execute scripts to unlock ecash spending conditions.

CASHU PROJECT OVERVIEW

With Cashu for Bitcoin, we started building this ecash project with different implementations, focusing a lot on describing the protocol, specing it out similar to how BIPs, Bolts, the LNURL protocol, or the Nostr protocol works.

Cashu uses NUTs. NUTs stands for Notation Utilization and Terminology. NUT-1through NUT-7are the mandatory Cashu protocol pieces that you need to implement in order to be a Cashu wallet or mint. Then there are additional optional protocols, and specifications that you can also implement to do things like, pay to public key, and so on.

It has been very fascinating to observe Cashu’s progression, because the project is only one year old, but has already come such a long way. I started working on this three days after last year’s Baltic Honey Badger 2022 Conference. So I come back here essentially one year later, and we can see how much it has evolved.

OVERVIEW OF CASHU WALLETS

Here’s one example that some people are working on, it is a wallet called eNuts, an attempt to have a very user-friendly and novel custodial lightning wallet which allows you to connect to as many mints as you want, have all your balances in one place, and then, for example, send ecash over Nostr to your Nostr friends. This is possible because you can use any communication medium to transmit ecash. eNuts pulls up your Nostr contact list, and you just press a button, and you can basically send money to your contacts.

DIFFERENT TYPES OF CASHU IMPLEMENTATIONS

Now I will give you an overview of different types of implementations that people have been working on. I just personally started Nutshell, which is a Python implementation. Then after that, a couple of people started working on their own Rust language mints, and a Golang mint and so forth. They are all basically interoperable.

People have also been working on different types of wallets as well, for instance command line wallets, web wallets, and iOS and Android compatible native wallets. It’s just amazing to see that people are taking this and running with it.

Furthermore, there are a few integrations. Because we’re focusing on building libraries, we design these libraries to help developers easily implement ecash. As a developer, the general experience is:

  1. Import a Cashu library
  2. Call cashu.generate-invoice
  3. When that invoice is paid, you’ll get ecash in the library that you can store.

It’s easy to implement, and people have been implementing it into several Nostr clients already, such as Snort and Amethyst. If someone sends you ecash via direct message on Nostr, Amethyst, for example, will render it as a widget where you just press a button, and then it gets sent to your lightning wallet, and that’s pretty cool!

There is also a category that I like to call “Novel Use Cases” for what you can do with ecash, and as opposed to what you couldn’t do with other payment mechanisms. I’ll discuss ProxNut a little later, which uses something we call X-Cashu. I’m also going to talk a little bit about what we’re doing with Katzenpost, which is a privacy mix network.

SUMMARY OF CASHU MILESTONES ACHIEVED SINCE Q3-2022

I want to spend a little time reviewing some of the milestones that we’ve reached in this past year. We have come a long way, but there is still more coming.

BITCOIN LIGHTNING INTEGRATION

Cashu for Bitcoin initially started with a Bitcoin Lightning integration. This was the first thing that we did after building the ecash mechanism and then adding Bitcoin support to it. Cashu establishes a mint that generates ecash tokens via the Lightning Network, and uses blinded signatures to mint ecash tokens.

DETERMINISTIC ECASH DERIVATION & SEED PHRASE BACKUPS

We’ve also merged into Nutshell something called deterministic ecash derivation. It’s very similar to BIP32, where you generate addresses in your Bitcoin wallet. Previously, one of the biggest issues with ecash was that if you lose your wallet, and your money is gone. This is not an acceptable state to be in, especially if you want to make it useful for ordinary folks.

One way to mitigate a loss of money scenario is doing something that is very similar to BIP32; you start with a random secret, and then you derive ecash secrets from that, which you then get blind signed by the mint, and you have ecash in your wallet. Now, when you lose your wallet, what you can do is you take your seed phrase again, regenerate blind messages, and then re-request the signatures from the server.

Basically, from a UX perspective, it goes like this:

  1. You lose your phone
  2. You enter your seed phrase
  3. Then it takes a while to communicate with the mint
  4. Then at the end, your ecash reappears in your wallet

The important bit is that privacy remains intact. However, during the correlation part, the mint might identify a particular user restoring their balance at the moment. Nevertheless, the system still maintains the ecash privacy properties.

PROOF-OF-LIABILITIES SCHEME FOR PUBLIC AUDITABILITY OF ECASH MINTS

It’s very hard to audit ecash mints, primarily because it’s not on a blockchain. A very quick summary of how this proof-of-liabilities scheme works:

The mint has a set of private keys that it signs the ecash with. You issue ecash with the set of private keys, and after a short time (ie: one month), the mint rotates the keys into a new key set, which is basically like opening up a new ecash mint. On top of this, you can make it mandatory that all the old ecash gets recycled into the ecash of the new key epoch.

You can then simulate a perpetual bank run, forcing old key sets to go into a zero balance again by forcing users to switch over to the new keyset epoch. And with that, you can increase the probability of detecting whether the mint has printed more ecash than they have reserves in their Bitcoin on-chain wallet, for example.

This is a key part because proof of reserves is kind of easy, you point to the chain, and that’s it. Proof of liabilities is the other part of that, trying to convince others that you haven’t promised more than you actually have in your reserves.

RECEIVER-OFFLINE TRANSACTIONS THAT ARE VERIFIABLY FINAL

We are working on receiver offline transactions, which is super interesting. You can lock ecash to a public key and verify that ecash. As a receiver, when I see ecash, I can verify the signature to see that it is locked to my public key. That means I can remain fully offline. As soon as I see ecash, the transaction is complete.

This is kind of magic because, imagine you’re in a bunker, there is no internet, you want to sell something, someone sends pre-locked ecash to your public key, and they can essentially pay inside the bunker without internet, letting you know that the transaction is final.

INTRODUCTION TO X-CASHU

I wanted to also jump into X-Cashu, which is one of the “novel use cases” that we’ve been exploring. Essentially by making use of the bearer token nature of ecash, you can add ecash into data packages to pay for stuff.

One of the things that you might know, for example, L402 by Lightning Labs or LSATs, it’s a mechanism to build paid API endpoints. Essentially, you ask the server, “Hey, can I get this endpoint?” and then the server says, “No, you need to pay for it.”

Now with X-Cashu, it’s a middleware that you can plug in front of your web server. It will just say, “Get some ecash first,” prompting you to add ecash to the request, and then you add ecash to the request to get the desired response.

LIGHTNING: THE CONNECTIVE TISSUE

Lightning is the connecting tissue for the Cashu ecash protocol, because ecash doesn’t make much sense if you cannot connect to other users on different mints. So this is essentially the first mint that I started. I can only exchange with people on the same mint, and we’ve also seen that I can exchange my ecash to bitcoin using the Lightning network with this mint connected to the Lightning network.

But there are other people on other mints. Some people will have balances on both mints, they could also act as a broker between ecash mints, which would be an interesting concept to see.

I think there is one project working on that in Cashu, but I don’t have more details on that at the moment. Nevertheless, you can do an exchange between mints if there’s a third party who owns assets on both of these mints. But what you would essentially always do in most cases is send a Lightning transaction between them, and this extends to a much larger scale.

X-CASHU FOR WEB PAYWALLS

Let’s look at what X-Cashu looks like when implemented; there is a project called ProxNut and the goal of this project is to make paywalls using ecash backed by bitcoin.

Essentially, imagine this scenario: you click on a link to an article and go onto NewYorkTimes[dot]com. There, a subscription popup greets you, and a paywall restricts the content. But once you have subscribed through typical means to the New York Times, and have a balance on that website, it essentially needs to track you to know which articles you read and so on, in order to deduct your paywall balance while visiting the website.

So we’re trying to fix this using ecash, by creating a X-Cashu powered web paywall, if you will, that cannot know which user accessed which resource by essentially sitting in the middle between the user, and the New York Times. They cannot correlate which user is using the service.

ONION-ROUTED ECASH

Onion-Routed Ecash is a concept of adding ecash to requests. There is a fantastic guy, Jonathan Wilkins, one of the co-founders of Blockstream, he’s working on a very, very cool privacy-aware SIM card solution, and they want to offer extremely private VPN services, so to speak. And the way they want to do this is using a mixnet called “Katzenpost”.

It’s similar to a Tor network, but it’s a mixnet, so it’s very inefficient, but that allows you to even circumvent the traffic monitoring by the NSA, if you assume that the NSA is watching all your servers. Using Katzenpost, they couldn’t figure out who’s the sender and receiver of a package. So, if you want to use a privacy service like Tor and Katzenpost, the question pops up, which payment method is private enough and fast enough to use those methods.

A DEEPER DIVE INTO THE “KATZENPOST” METHOD

Cuts

  • This term refers to the process of dividing a message into smaller pieces or “cuts”. By breaking down the message, it becomes more challenging to track or identify the content as it moves through the mixnet.

Post

  • The system cuts the message into smaller parts and then sends these parts through the mixnet independently. Once they reach their destination, the system reassembles or ‘posts’ them back together to form the original message.

So, we know that lightning sender privacy is excellent, but the receiver privacy is really not that good yet. Even lightning might not be fast enough to do it on a request basis. So, the idea here is, similar to proxnut, that you just can add ecash to the request that you want to send through this method, for example, Tor network, but the idea is that we can also wrap ecash inside layers of onions, and that’s how the Tor network and Katzenpost work.

INTEGRATING ECASH WITH ONION ROUTING

See in the screenshot above how your request travels through the Katzenpost network, and observe how you encrypt and layer your onion. What you do is basically add ecash into every single onion layer. You can have multiple payments inside one data package, and as you send this onion across the network. Each party can then “peel off” one layer of the onion and take out some ecash and get paid for hosting a Tor relay, for example. And with that, you can make sure that there is no way to figure out who the users are who are paying for that.

So, essentially, for these types of systems, you want the maximum amount of privacy, and ecash can really shine, especially in closed systems like a mixnet, like Katzenpost, and a system where you don’t want to compromise in privacy at all. We are happy to build this system on top of Bitcoin for the simple fact that it should be built on Bitcoin!

You could use other privacy shitcoins for it if you really wanted, but not even they have these privacy properties that ecash can provide. As for myself, I’m just happy to see that this almost ancient technology is experiencing a renaissance because of the developers in the Bitcoin space, with the Fedimint developers and the Cashu developers, who are really taking it back and bringing it somehow into the 21st century, which is really cool to see.

Disclaimer:

Transcripts provided on bitlyrics.co represents solely the opinion of the speaker and is not by any means financial/legal advice or an opinion of the website. The content has been transcribed with maximum possible accuracy. Repetitions and fill words have been amended in order to enhance the reading experience. The full text may or may not be confirmed by the speaker. Please, refer back to the above-provided source of content for more certainty. If you are a speaker and wish to confirm/amend your speech please contact us.

bitcoinchaumian ecashcashuprivacybitcoin honeybadgercallebtccryptographypayments