Join Kalle, a seasoned developer and speaker, as he delves into the world of Chalmeney Cache protocol, Cashew. This video is a treasure trove for tech enthusiasts interested in understanding the workings of this intriguing protocol. Kalle walks you through the ins and outs of Cashew, a protocol designed to tackle custodial risk and privacy issues in custodial services.
In this video, you'll learn how Chormin eCache stores money on a user's hard drive instead of a blockchain, ensuring untraceability and the ability to use it as a bearer token. Kalle also introduces you to the concept of a push user experience, eliminating the need for generating invoices during transactions.
Kalle and his team have been hard at work developing the eCash project, and this video gives you a sneak peek into the various implementations and milestones they've achieved. Learn about the NUTS protocol, the user-friendly custodial lightning wallet E Nuts, and the different eCash implementations developed in EN713.
The video also delves into the intricacies of encashing secrets, blind signing, and restoring balance. Kalle touches upon the privacy of e-cash transactions and the development of programmable e-cash with spending conditions.
Ever wondered about using digital currency offline? Kalle explains the use of eCash in offline scenarios and introduces XCache, a middleware that allows eCash to be added to data packages for payment.
Kalle also demonstrates how to set up your own eCash mint using LNBits, a custodial server, and how to use a wallet with zero Satoshis and a cashier extension. You'll also learn about the interoperability between different wallets using the nutsdash app.
The video concludes with a discussion on the integration of Lightning Network with different mints, the exchange of e-cash between mints, the role of brokers, and the xCashShoe project.
Whether you're a developer interested in exploring the code behind these projects, or a tech enthusiast curious about the future of digital currency, this video is a must-watch. Tune in for an insightful journey into the world of eCash and the fascinating projects Kalle and his team have been working on.
I'm Kalle and I work on a Chalmeney Cache protocol called Cashew. We're a bunch of developers now playing around with it. I gave a talk on this yesterday, so I don't want to repeat myself completely for some people might have seen the talk already, but still I want to give an introduction with the gist of the talk from yesterday, but actually I would like to prefer if this is more of a interactive workshop. So I think I will just. skim over the basics of how this whole system works so you get an idea of it. And then I would like to point you towards some of the projects that we've been working on.
And if you have a phone or a laptop with you, you can take it out and we can do some Chomini cash magic on Bitcoin. All right, so Cachew is a Chawmin eCache project. And basically the problem that we're trying to solve is one of these two custodial risk problems. The first one is that you can be rocked, but the second one that you have basically no privacy if you use a custodial service. And the way every custodial service is built is that they must know your activity.
Otherwise there is no other concept of building that except one big, big, big, big, big, exception to that is using Chormin eCache and we make use of that in order to use or construct custodial systems that are fully unaware of what you're doing. Right, so I will skip some slides and come to the point and describe how Chormin eCache works. We have our three actors, Alice and Carol are two users, and Bob is a German e-cash mint. And now if Alice has some e-cash in her database, she stores it as a piece of data. And if she now wants to send money to Carol, what she does is she pulls up a piece of electronic data. This is e-cash.
It's a blind signature and a secret. I can explain a little bit how that works in detail later. But what she essentially does is she pulls up data from the database. And here's the interesting difference to, for example, how Bitcoin works is where the data that you store in your wallet is a key. And at least I interpret it as a, you know, you have a key and you take that key to then make a transaction on this blockchain. So you move the money. on the blockchain using your key, but in eCash, the money is on your hard drive. So there is no, you know, blockchain or something that would interact with that.
So basically you just send over the eCash over any medium that you want. And then to finalize the transaction, Carol needs to make sure that this eCash cannot be double-spent. So she sends it over to the Mint and then the Mint does basically a check, is the blind signature that it gave on this eCash correct or not? Mint. checks whether it has seen that e-cash before or not.
And if that's not the case, so I have not seen that e-cash before, she stores it in her database and then generates a new piece of e-cash and sends it to Carol, and then the transaction is complete, right? So, The essential properties of eCash and why it's interesting to play and build with it is, first of all, it is basically untraceable, except for correlations that you could do, but the eCash transaction itself is not related to the eCash transaction previously that has generated that eCash. It's also a bearer token. That means that since you now have a piece of data that is the money, you can play around with it, put it into requests, put it into onions and so on.
I'm going to summarize a little bit what we've been doing with it, but you can do things that are not really possible in a, you know, key based system. It allows a push UX, so I imagine that you take a piece of data and you throw it at your friend and the transaction is complete so they don't have to wake up and generate an invoice and so on. For example, like in Bolt11 we will have rather a pull-based system and we've also been experimenting with programmable e-cash.
So we've been adding spending conditions onto e-cash, encoding it in the secret that is blind-signed and then you can build things like pay to public key with it, you can execute scripts to unlock it. e-cash spending conditions. All right, so skipping further, in the cash project, so I'm going to show you. We started building this e-cache project that has different implementations. We've been focusing a lot on describing the protocol. So we've been speccing it out similar to how BIPs work or BOLTs work or LNUL protocol or the NOSTA protocol is described. So there is a bunch of NUTS. NUTS stands for Notation, Utilization and Terminology. And there are NUT1 to NUT7, for example. These are the mandatory.
protocol pieces that you need to implement in order to be a cashew wallet or mint and then there are additional optional protocols and specifications that you can also implement for example pay to public key and so on. So it's been very fascinating to observe this because the project is only one year old and I started working on it three days after the last year's Baltic Honey Badger. So I come back here essentially exactly one year later and we can kind of see how it evolved. Here's one example that some people are working on is what it called E-Nuts. And it's trying to be a very user-friendly and novel way of doing things.
custodial lightning wallet, which allows you to, you know, connect to as many mints as you want, have all your balance in one place. And then, for example, send over e-cash over Nostar to your Nostar friends, because you can use any communication medium to transmit e-cash. It pulls up your Nostar contact list and you just press a button and you can basically send money to them. But, so I just want to give you an overview of the different implementations that people have been working on. So I just. started Nutshell, which is the reference kind of Python implementation that I started with. And then after that, a couple of people started working on their own Rust mins, and there's a Golang min, and so forth.
They are all basically interoperable. And people have been working on different wallets. So we have command line wallets, web wallets, iOS and Android compatible native wallets. And it's just amazing to see that people are running with it. Furthermore, there are a couple of integrations. So because we're focusing on building libraries and these libraries are supposed to help you to implement eCache easily. So as a developer, the experience is you import a cache library and then you say cache. generateInvoice and then you have a cache library. So you have a cache library, Someone pays that invoice and you get e-cash. In the library, you have e-cash that you can then store.
So it's easy to implement and people have been implementing it in to several, for example, these Nostar clients, Snort and Amethyst. If someone sends you e-cash via direct message on Nostar, Amethyst will render it as a widget that you just press a button and then it gets deducted to your Lightning Wallet. So this is pretty cool. And there's also a category that I call like novel use cases, new use cases. what you can do with eCash, what you couldn't do with other payment mechanisms. And I want to demo ProxNets later, which is something we call XCashU, and I'm also going to talk a little bit about what we're doing with KatsenPost, which is a privacy mixnet.
And so I want to mention some of the milestones that we've reached in this one year. First of all, we started with a Bitcoin Lightning integration. This was the first thing that we did after, you know, building the e-cash mechanism and then adding Bitcoin support to it. Recently, we've also merged in a nutshell, something called deterministic e-cash derivation. It's very similar to BIP32, where you generate addresses in your Bitcoin wallet. Previously, one of the biggest issues with e-cash was that if you lose your wallet, then your money is gone. And so, we've added a new feature called DeFi, which is a decentralized e-cash wallet. It's a wallet that you can use to transfer your money to your wallet. And it's a very simple wallet.
It's a wallet that you can use to transfer your money to your wallet. And this is not a state that is acceptable, especially if you want to make it useful for ordinary folks. And one way to mitigate this is doing very similar to BIP32. You start with a random secret, and then you derive e-cash secrets from that, which you then get blind signed by the mint. And you have e-cash in your wallet. Now, when you lose your wallet, what you can do is you take that seed phrase again, regenerate blind messages, and then can re-request the signatures from the server.
Basically, the UX is, I've lost my phone, you enter your seed phrase, and then it takes a while because there's a lot of communication with the mint, but then at the end, your e-cash reappears in your wallet and you can start using it again. And the important bit is that still the privacy remains. except for the correlation part that the Mint might be able to know that, you know, this is one user restoring their balance right now, but the eCache privacy properties are still maintained. Yeah, we've been, as I just said, we've been working on programmable e-cash with spending conditions. I'll skip that for now. I'm also working on a proof of liability scheme. It's very hard to audit e-cash mints because it's not a blockchain.
I guess that's the main reason. And we've been working on a proof of liability scheme. Just a very quick summary of how this works is. Essentially, you have a set of keys. The mint has a set of private keys that it signs the e-cash with. And then you accumulate, you know, you issue e-cash with those set of private keys for your users. And then after one month, for example, the mint will rotate the keys into a new key set. And that is basically like opening up a new e-cash mint. And what you then also on top of that force is that all the old e-cash is now gets recycled into the e-cash of the new key epoch.
And what you then can simulate with that is kind of a perpetual bank run on different key sets. So you can force old key sets into going to zero balance again by forcing users to switch over to the new e-cash epoch. And with that, you can increase the probability of detecting whether the mint has printed more e-cash than they have reserves in their Bitcoin on-chain wallet, for example. So it's a key part because proof of reserves is kind of easy. You point to the mint. 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.
And so I guess this is one way that we want to go further on and implement this. So we are working on receiver offline transactions. This is super interesting. So if you can lock eCash to a public key and you can verify that eCash, so as a receiver, I see eCash, I can verify the signature and I can see that it is locked to my private key, 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, I mean, imagine you're in a bunker, there is no internet, you want to sell something.
Someone comes in with pre-locked e-cash to your public key, and they can essentially pay inside the bunker without internet, and you will know that the transaction is final, at least in an e-cash sense. Yeah, and as I said, we've been working on libraries, different implementations, and mobile wallets. All right. I wanted to also jump in into xCashU. which is one of the novel use cases that we've been exploring. Essentially making use of the bearer token nature of eCash. You can add eCash into data packages to pay for stuff. So one of the things that you might know, for example, L4 or two by Lightning Labs or LSATs, it's a mechanism to build a paid API endpoints.
So essentially you ask the server, hey, can I get this endpoint? And then the server says, no, and you need to pay for it. And. And now with XCache, it's a middleware that you can plug in front of your web server. It will just ask, you know, get some e-cache first and then add e-cache to the request. And you do that and then you add e-cache to the request and you get a response to it. All right, so this is the very, very short summary of my presentation yesterday. And now I would like to invite you to set up, if you have a laptop, you can set up your own e-cash mint. It will take you one minute.
If you don't have a laptop, we can just use one that I create here, I guess. All right, so I am going to, let's see. go now on LNBits on the demo server. So this is the LNBits demo server. It's a custodial server that is run by our LNBits team. And you can just create a wallet here, right? And I will copy this, so I'm not gonna lose this later. Oops. All right, so we have copied that lmbits account. And now inside lmbits, there's an extension. We can go to the extensions. You can also run a cashier mint completely natively, but this is the fastest way to set it up. And we search for the cashier extension, enable that. Now it pops up here.
All right, so we have a wallet with zero Satoshis and we have the cashier extension. Now I add a new mint. I say, this is the BHB23. Mint, I associate this wallet with it and the mint is created. So now we have a mint that runs on that Lightning wallet and you have several ways to access that mint. So I'm going to now, how do we do this? You don't, let's see, I'm going to open this mint now in one of the Cashew wallets. This is cashew. me, right? And it prompts me like, Hey, I'm going to open this wallet. This is your connect. You don't have any mint edit yet. Do you really trust that mint? I say, yes, I trust that mint. Now it's edit.
I have zero sets in my account here. And so there are, as you can see here, two buttons for e-cash operations, two buttons for Lightning operations. And let's first peg in. So I'm going to put some sets in here, create an invoice. See if anyone's faster than me, but I'm going to pay it. All right. Let's work. They're paid. So now we have created 100 sets that is stored in my local storage. So when we look in here now. Let's really get into it. You can see this local storage of this website and there are now a couple of keys and there is this proofs and well, let's see if I can zoom in here.
And you can see that I have three eCash tokens now with different amounts. One for four Satoshis, 32 Satoshis, 64 Satoshis. This makes 100 Satoshis. And I can, now this is a piece of data. This is E-cash, right? It's a blind signature here. Here's a secret that was signed. All right, so I'm gonna send this now to someone. Let's get rid of this again. I'm going to press send e-cash. Now you've seen, I don't have 10, 10 Satoshis. I want to send 10 Satoshis now, but I don't have 10 Satoshis. What I do is now I sent, for example, the 32 Satoshi e-cash note that I have in my wallet.
I'm going to send it to the mint and say, please mint, cut it at exactly 10 Satoshis and give me two sets of e-cash back, and that's what's going to happen when I just enter send 10, this happened, it's done. Oh, 10 is not the best number because 10 means it's two e-cash nodes and that doesn't fit into a QR code. So I'm going to just cancel that and send you eight because eight is two to the power of N and eight will be represented by a single e-cash node. This fits now into a QR code. If you have now a Cashew wallet, you open Cashew. me, that's the wallet.
You can scan this QR code and someone who's fast enough should be able to grab it. And my. . . Wallet here will recognize if it's taken. And you can see, so we have a serialization format basically down here, there's the string represented, and that's it. So someone took it and it was detected from my balance here. There's also an open 10 Satoshis here still that no one received because it's not represented as a QR code. I can basically just copy it.
And this is what you would experience, you know, when someone gives you a token on Twitter or something, you just copy the token on Twitter and then you say, receive e-cash, you paste it in, it says 10 Satoshis is from the mint that I know, press receive and. It's done. Well, the fascinating thing about it is how fast everything, of course, is because it's a single server round trip for a single transaction. All right. So how much time do we have? Okay, we're good. All right. So to maybe demonstrate interoperability, let's look at a different wallet. And this one is called nutsdash. You can also open it on your phone if you like. It's nutsdash. app. All right, I'm going there and there's open wallet. Wallet. nutsdash.
app looks completely different, made by a different person, speaks the same protocol. So. As you can see here, there are no mints added here yet. And I've just generated a new mint, right? The 10 Satoshis that someone just grabbed is now lives on this one mint that I created. This mint is not added to this wallet yet, but let's demonstrate maybe inter-mint operability because that's what most people will experience, right? Most people won't be just using one mint or not everyone will be using the same mint and so on. So there is a default mint in this wallet. I'm just going to add this one. And I have now zero Satoshis in this wallet.
So what I'm going to do is to, now the UX is a bit different here. I'm going to press the mint button to mint some e-cash. And I'm going to say, I want 10 Satoshis. It says request mint. And then it becomes, oops. I know this is my Albi extension. I didn't know that it was integrated with LB, but that's pretty cool. So now I have 10 Satoshis in this wallet. I have 92 Satoshis in this wallet. Let's do it the other way around. I'm going to use this as a normal, you know, lightning wallet. I say create invoice. And let's do maybe five because of the fees. Here's an invoice. I copy the invoice.
If I just pay this now, this is on a different mint, a different user. He says, pay a lightning invoice. Entered I choose the mint from which I want to pay the invoice. This is the only one that I have I say pay The invoice has been paid here. So what just happened is the e-cash on Mint A, with the user of User A, was burned. And then a Lightning transaction was sent to Mint B. And on Mint B, new e-cash was generated and sent to User B. So essentially, both are just e-cash wallets, but they interface between the mints using Lightning. So the image that I'd like to show here. Oops. Is. This one. So lightning as a connecting tissue.
Because E-cache doesn't make much sense if you cannot connect to other users on different mints. So this is essentially my 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 e-cash to Bitcoin on Lightning Network with this Mint connected to Lightning Network, but there are other people on other Mints. And the way that I can, you know, some people will have balances on both Mints. They could also act as a broker between e-cash Mints, which would be interesting to see. I think there is one project working on that in Cashew, but.
I don't have more details on that, but you can do an exchange between mints, obviously, if there is 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. That's what we just did. And this extends, obviously, to a much larger scale. All right, so I said I would also like to present xCashShoe. Now, I'm going to show you how to do that. I don't have a good understanding of how many people are coders here and not. So I can also show some code, but maybe who's, who's a developer here? Uh, it feels like 25%. Let's not do it. All right.
So then let's look at what Xcash can look like. And this is called Croxnut. It's by the same developer who made Nutsdash. And the goal of this project is to make paywalls using e-cash, backed by Bitcoin. But so essentially what we want to build here is imagine you go onto newyorktimes. com and then you have a subscription and the content is paywalled. No, that's fine. And you can pay with Bitcoin to read the content. That's also great. But once you have a balance on that website, it essentially needs to track you.
It needs to know which articles you read and so on in order to deduct the balance from your paywall balance that you have on the website. So we're trying to fix this by using e-cash, by making a web paywall that cannot know which user accessed which resource. So that's the idea. Let's go into demo. So this is now a fake website, a toy website that he made. You know, you have a couple of buttons. You want to request some content. And if you press that one, it says, no, you don't have any funds. No funds, no funds. Here we go. And you can see here, this is the web widget. This is a Cashew library that you import into a website.
And it opens up. It looks like this cute little wallet here. You can say top up. I'm going to put 10 Satoshis here, confirm. It's a Lightning invoice. Let's pay it. So let's see. I pay it. So it's paid and you can see I have now 10 nuts in my wallet up here. And now I can just go on browsing the website. And if I just request this resources, you know, it costs me one set. You can see as soon as I press, I get the response and it's deducted from my eCash wallet up here. And I can, yes, yeah. And then communicating with the mint and the exchange for smaller values.
So what this, the precise implementation for this right now, I don't know, but you don't need a round trip. You could also mint a bunch of Wansatoshi tokens, for example, or if all the resources cost the same amount, then that would be ideal for privacy as well, yeah. So we can just keep on doing that, request different resources. And you can see as that my balance slowly goes down. Now I have only one Satoshi left in here. This is even below the dust limit of lightning transactions. So I won't be able to cash that out. But what you can do here is basically, if you're done, you can press cash out, enter a lightning invoice and your money is again in your lightning wallet.
But the owner of this website doesn't know which wallet is yours, where the lightning, you know. and cannot correlate you consuming this website with your pegout again. All right. So, we have five more minutes. I mean, we can also open up the discussion. Maybe anyone has questions on how we do certain things. If you want to learn more about the cryptography or something, I can answer any question you like. What's in it for the mint? What's in it for the mints? Right now, nothing. So the mint itself doesn't have any mechanism to collect a fee or something, but it would be essentially trivial to add that as a function. Right now, it doesn't make sense to think about that yet.
So that's one economic aspect. But I mean, look at this mess, I wanted to say. Look at this mess. This is the custodial. This is the distribution of wallets that are used for zaps on Nostra. And this 90% is custodial. So as a wallet of Satoshi could offer something that others cannot offer by promising almost perfect privacy to their users. So essentially, that's also in it. So. I saw that you had a notification where somebody was paying for tokens. Yes.
How does that work? The way that works is we have an endpoint in the API, a description, where you can send basically the, you can ask the server what the state of this token, have you ever seen this token, yes or no? By constantly pinging the server, whether the token is spent, you can build a responsive Lightning wallet. But that's also, you know, from a privacy perspective, that's a little bit critical because again, it allows more easy temporal correlation of who is doing what, if two users are doing an operation at the same time, it's easier to assume that. We're, you know, we're thinking about how to scramble that up. Cryptographically, there might be ways to do it, but essentially I think most, biggest problem is literally temporal correlation.
So what I want to also mention for those who haven't seen this yesterday, but this is basically, this is going all in on this concept of adding e-cash to requests, what I call here, Onion-routed e-cash. I'm working on, so this is a proof of, it's a work in progress. There is a fantastic guy, Jonathan Wilkins, one of the co-founders of Blockstream, and he's a fantastic guy.
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 cuts and post and cuts and post is a You can imagine it's similar to a Tor network, but it's a mixed net, 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 cuts and posts, they couldn't figure out who's the sender and receiver of a package. So that's it.
Essentially, if you want to use privacy of a service like Tor and Katzenpost, the question pops up, which payment methods, if you want to pay for them, what is private enough and fast enough to use those methods? So I mean, we know that Lightning sender privacy is excellent. The receiver privacy is really not that good yet. But even Lightning might not be fast enough to do it on a request basis. So. The idea here is similar to the Proxnod stuff, that you just can add e-cache to the request that you want to send through this, for example, Tor network. But the idea squared is that we can also wrap e-cache inside layers of onions. And that's how the Tor network and also KudsenPost works.
So you have this little image here that shows how your request is routed through the KudsenPost network, and you construct your onion. in layers encrypted. And what you can now do is basically add e-cash into every single Onion layer. You can have multiple payments inside one data package. And as you send this Onion across the network, everyone can peel off one layer of the Onion and take out some e-cash 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 and so on. So essentially for these type of systems, you want the maximum.
amount of privacy and I guess, you know, e-cash can really shine, especially in closed systems like a mixed net like Hudson Post and a system where you just want, you know, for where you don't want to compromise in privacy at all. And I mean, we are happy to build this system on top of Bitcoin because it should be built on Bitcoin. You could use other privacy shitcoins for it, but not even them have these privacy properties that e-cash can provide. And I myself, I'm just happy to see that this almost ancient technology these days has a renaissance because of the developers in the Bitcoin space with the Fediman developers.
And the cache developers were really, you know, taking it back and bringing it somehow into the 21st century, which is really fucking cool to see. Um, there are also other e-cache projects out there, um, that I want to mention. Uh, like blue Tyler, they are essentially working towards a CBDC e-cache proposal, which is a very, you know, spicy topic. And, um, also web cache, which is. Yeah, an e-cash shitcoin, you could say, with its own market and value and so on. So we're not interested in dealing with those kinds of things. But, um, so yeah, this is, this is essentially my demo and my, uh, my presentation short, I don't know if there's more time for questions, but if you have a pressing question, just ask it, I guess now, here we go. I'm curious about this one.
Um, be putting payments in the onion layers? Was it started only from taking the money and not including the actions? That's a very good question. So actually, I don't know. I haven't thought about that too much. I think this can, right now, the way we've built it, it can only work altruistically. But this is already a service that is hosted by a company that wants to provide you the service. So it's not like they are going to rock you twice or something, but if this would be a completely anonymous system where everyone can join and everyone can participate, then you have to at least do more crypto magic on how to unlock the e-cash on a way back.
Like in Lightning Network, for example, you have this back propagation of the hash lock that makes sure that everyone gets their money only if they have also delivered on their promise. Yeah. that as discussion, that maybe this would incentivize bad actors to create the network. To make money while griefing the network or something? Yeah. Could be. I mean, Tor right now is exploring proof of work, right? So the problem is real. And well, we don't, for an anonymous decentralized system, there is no other known solution than proof of work. Yeah. All right. I think that's it. Thank you for your attention. .