Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ben DiFrancesco: Umbra – Privacy Preserving Token Transfers

Episode Date: May 19, 2023

Public transaction history in blockchains represents one of their key features which, alongside immutability, aim to provide an alternative to CeFi. However, this transparency comes at a price: privacy. As a result, different solutions have been proposed, that preserve privacy while maintaining all the other benefits of blockchain technology, but there currently isn't a one-size-fits-all answer to this problem. For example, zero knowledge proofs convey the validity of a transaction batch without sharing any other details, but the underlying arithmetic circuits are both complex as well as computational intensive. Umbra proposes a system that relies completely on elliptic curve cryptography, employing multiple private-public key pairs to achieve stealth payments.We were joined by Ben DiFrancesco, founder & CEO of ScopeLift, to talk about Umbra's privacy preserving stealth token transfer system and if the need for privacy on blockchains outweighs any implicit UX frictions.Topics covered in this episode:Ben’s backgroundUmbra's missionHow Umbra worksNon-interactive key distributionPotential solutions (& trade-offs) for Umbra's computational intensityGenerating private-public key pairs by the Umbra smart contractUser experience (UX) for senders and receiversFee structure for deterring griefing attacksHow Umbra works for ERC20 tokens & NFTsPrivacy preserving withdrawals from stealth addressesPrivacy vs. UX frictionSmart wallets & account abstractionPrioritising privacyEpisode links: Ben DiFrancesco on TwitterUmbra on TwitterScopeLift on TwitterThis episode is hosted by Friederike Ernst. Show notes and listening options: epicenter.tv/496

This is Epicenter, episode 496, with a guest, Bendie Francesco. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization at the blockchain revolution. I'm Trinidad, and today I'm speaking with Beni Francesco, who is the CEO of Scope Lift and creator of Umbra, a privacy layer for Ether-based token transfers. Ben, it's the title of you on. Yeah, thank you so much for having me. Really appreciate it, excited to chat.

Cool. So I think the very clear first question here is tell us about yourself. Who are you? How did you get into the space? And is it true you are originally an aerospace engineer? Yeah, sure, absolutely. Yes. I am originally an aerospace engineer. So believe it or not, growing up, I was kind of a nerd. And so I was interested in. I know. Really shocking. Unusual in the space. Very unusual. But, so I was interested in computers from a very early age. I kind of like played around and started teaching myself to program. I was also interested in like aviation and aerospace and airspace and all that kind of stuff. And so I went to school for aerospace engineering because I was very excited about that. And I really enjoyed kind of the coursework and the, you know, the sort of like overall idea of doing aerospace engineering. And then when I got out of school, I went to work at a large. aerospace engineering firm here in the States and what I learned pretty quickly is that the reality of aerospace engineering at least at these big firms is very different from kind of the um you know uh idealistic view that I had as a as a young kid going to study it so in reality you know aerospace engineering for good reason is very um slow basically you know you can work on a project and aircraft project for for many years before it can come to fruition there are a lot of people

involved in any given project and in general especially again at these big firms things are very bureaucratic and slow moving. And it also turns out that at these big firms, engineering firms, traditional engineering firms, really in general, they desperately need more people to program because there's all kinds of stuff that needs to be done software-wise, building software, but it's hard to get people that have the knowledge to build the software, but also have the engineering side of things. And so within this large firm, I was doing all software engineering work anyway. And what I realized was that I wasn't loving my job. I loved, I really enjoyed the programming side of things, the software side of things. What I didn't like was the bureaucracy, the top heaviness,

the slow moving side of things. And so I left Boeing and went into kind of, I basically started freelancing and then eventually grew my company Scoplift into a consulting firm, a dev shop, for lack of a better word. And this was probably around 2012, 2013. At the time, I was not doing work in crypto, but I was following crypto. So I had found Bitcoin. I was really fascinated by it, and I was following the project. I was doing stuff on the side, you know, for fun. I, like, built a mining rig and I was mining Dogecoin, believe it or not, like probably at a loss in my house, but like paying more for the electricity than the Dogecoin I was mining. But I was following it. There wasn't really much of a crypto industry of the time, except for like a few companies out there. So it was

really when Ethereum launched that I sort of got really excited about crypto because I realized this was it went from like, oh, this is an interesting kind of, interesting kind of, you know, thing, digital scarcity that's been invented to, oh, this is like a whole new platform. And as a software engineer, I can build things on top of this. And this is going to allow us to create all brand new kinds of software that do things we couldn't previously do before. And so that kind of, when I learned about smart contracts and saw Ethereum coming together, that like Mike bulb kind of went off. And so again, I continued to sort of follow the project, started tinkering with Ethereum and smart contracts. And then it really wasn't until the boom of 2017 into like 2018 when I

started picking up projects. Scoplish started picking up projects. By this time, it was a small consultancy, and we started picking up actual crypto projects. And by 2019, I decided to really shift the firm 100% into focusing on crypto. So we wound up our legacy projects, our web two, and kind of, we were doing some native mobile work as well and decided to focus 100% on crypto, sort of having to start from the ground up with business development and all that kind of stuff. But really, it's been an also ride because, as you know, the space since 2019, the space has changed an enormous amount. And we've had the opportunity in that time to really contribute to a whole bunch of stuff in the Ethereum ecosystem in particular and some other ecosystems as well. But mainly we're

focused in Ethereum. And that's been really gratifying. and a lot of fun. And yeah, that's kind of the long-winded explanation to your question. Can you tell us about some of the projects you've contributed to over the years? Yeah, absolutely. We've done a lot of work with a lot of great projects. We've been lucky to get to contribute to projects. Certainly, your audience, would have heard of optimism,

Gipcoin, we've done a ton of work with them, Uniswap, Endowments, Oble, a bunch of other really, really cool projects. And then, of course, we also have done some of our own internal projects over the years with varying degrees of success. And the one that has a decent amount of, has probably the most traction of the internal stuff that we've built is Umbra. Ambra is also the project we're here to talk about today. But maybe before we dive into that, how is it kind of being a hired gun on some projects and kind of scurring that with building your own? I imagine that's a really difficult line to toe. Yeah, I mean, yes and no.

I mean, I think me personally, and I think as a culture the company selects for this, we're like, we're a seven-person team. We're all engineers. We're all very, we just like to build things, basically, I think would be the culture. And so it's like really a culture focused on engineering excellence. And you come to us with hard problems and we help you solve them

is kind of the approach that we take. And, you know, I think like I just have fun. We have fun doing that. that, right? So I think it's, I'm always impressed when people can, you know, find an idea that they're so passionate about, like a singular project that they're willing to sort of grind on that for years and years and years and years. My mind likes to kind of jump all over the place. And so it's been awesome to get to contribute to a whole bunch of different projects and to, you know, have a few things going on at any given time. It also just gives us like a really wide view of the space because there is

so much going on, right? And even with that wide view, it's like, it used, you know, in 2017-ish, you could reasonably, like, have a sense of everything going on in Ethereum as one person if you were really paying attention. By then, it was starting to already get hard. Now it's like literally impossible. You can barely keep an eye on a sliver of the activity that's happening in the ecosystem at any given time. But, you know, we get to, we get to see a relative to maybe other folks, we get to see a wide breath of that. So that's a lot of fun. Of course, there is some tension with our client work and our own projects that we would like to push forward. But we've been really lucky, especially with Umbra, to get funding in the form of grants from a lot of different sources,

a number of different sources in the ecosystem. And so we've been able to, you know, push that forward while at the same time balancing it with our client work in the ecosystem. In a nutshell, what does Umbra set out to do? Yeah, cool. So Umbra is a privacy tool. It's a stealth adjunctual. system and it's different from some of the privacy tools that maybe your audience would be used to. So it's primarily about receiving payments or receiving a transaction sent to you by a known sender where the fact that they've sent it to you isn't immediately, isn't legible on chain, isn't obvious on chain. So another way to say that is it's about receiving payments where

only the sender and the receiver know who the receiver is. Right. So, The sender is visible on chain. The receiver is stealth. That's where the stealth address side of things comes into play. So unlike some other tools that your audience may be familiar with, like Tornado Cash being the most prominent example, for example, would be it's not a mixer, right? So a mixer is primarily about taking funds that you control,

but are doxed in some way. It's known that you control these funds in this. address and then moving them through the mixer and when they come out the other side of the mixer, they're in an address that you control, but it's no longer clear that you're the owner of them. So it's breaking the link between address A and address B, both of which are controlled by the same entity, right? That's not what Umbra does. That's what a mixer does and we're not a mixer.

So Umbra is about, I want to receive a payment. It could be e-commerce. It could be, you know, you're paying an invoice because I'm a business and we worked together. could be you're paying my salary, you know, whatever it is. We have some economic relationship. You want to pay me, but we don't all want it to be obvious on chain that you have sent this amount of money to me. So if you use UMRA, basically what it looks like is you've sent some tokens or some ether to an address that has never been seen before on chain. Now, behind the scenes, it turns out that I control that address and only I control that address. And as soon as you've

sent those funds, they're essentially custodied by me and you couldn't recover them. No one else could recover them. Only I have the ability to remove them from that stealth address that they've been sent to. But on chain, who that address is controlled by is

not visible or legible at all. So that's sort of a quick summary of what UMRA enables. So if I look at my ragbeiler saying Meta Mask, it lets me derive a de facto unlimited number of addresses from a single seat phrase.

So basically, if we coordinate ahead of time, what I could do is I could just make a new address from the seed phrase that I'm already using and give you that. But what Umbra actually does, it actually lets you kind of, I mean, it works differently. We'll talk about how it works in just a bit, but it'll let you generate a new address on my behalf, right? Yeah, that's a great, that's exactly right. That's a great way to think about it, right? So, yes, like the privacy sort of tradeoffs that you get from Umbra are the same as

if you, if I, you were going to pay me and I generated a fresh address, you know, just went into Metamask and clicked add new or created some private keys and imported it, whatever, generated a fresh address and then sent that address to you and then you sent the funds to that address. That's the privacy. The privacy properties that you would get from that interaction are the privacy properties that you get from Umbra. The difference is that it's a non-interactive protocol.

In other words, we don't have to do that out-of-band coordination in order for you to get a fresh address that only I control. You can, as you alluded to, effectively generate a fresh address on my behalf that only I can control, but still looks completely completely. used a new on chain and it basically looks like a regular address on chain. It 100% looks like a regular address on chain. There's nothing special about it because it is a special address. It's just generated using some cryptography.

Okay. So basically saying, I want to pay you, say 15 die or whatever. How do I go about creating this address that you and only you have the private key tool? Cool. Yeah. So do you want to dive into this from at the technical level, at like the user experience level? Like where do you want to start with this? Yeah, I think that's a great question.

Let's get the maths straight first. And then we can go through the user experience after. Okay, cool. So I'm going to describe the way that it works in UMRA today. And the principle is the same, right? The underlying math principle is the same. There are slightly different constructions, like ways that you could put it together. And so like different stealth address schemes might have slightly different constructions.

but I'm going to describe the one that we use in Umbra and the underlying, you know, principles are all the same regardless of the exact implementation details. So to do that, I'm going to have to back up a little bit and talk about elliptic curve cryptography, which is the kind of cryptography that underlies basically all of the serum, right? So elliptic curve cryptography is asymmetric cryptography. In other words, you have not just, you know, with symmetric cryptography, you have a private key and you use that private key. to encrypt something and then you use that key to decrypt something. So the key is the secret and the key lets you encrypt it and decrypt it. In asymmetric, asymmetric cryptography, you have a private key and you have a public key, right? And so that and those two things are a pair, right? So for every private key, there's an associated public key and vice versa. And if you have the public key,

you can't derive the private key, but you can use the public key to encrypt something. So to take some text or data and encrypt it so that it can't be viewed. And then once that's encrypted with the public key, only the owner of the private key can decrypt it. So this is what we use in things like, you know, private chat apps, right, like Signal or whatever, right? So I, you know, the app does this process where you can see my public key and then you send you take, you write a message. The app encrypts it with my public key sends it to me. I decrypt it once on, it's on my device with my private key. when it went over the wire, nobody could read it, right? So that's the same cryptography that underlies all of Ethereum. And the private key and the public key in these scenarios are just big

numbers, right? So they're big integers. And your Ethereum address, the Ethereum address that you have in Metamask is derived from the public key of the private key, right? So it's actually the hash of your public key just defines your Ethereum address. And so when you send a transaction on Ethereum, you sign it with the private key and then you broadcast it out and people running nodes have to validate that the signature is correct and then execute whatever actions it has to include it in that blockchain. Okay. Sorry for that background, but I think it's important to establish what I'm going to talk about

next, which is how getting back to how Umbro works, right? So the way that it turns out, right, and this is just a property of the math, but it turns out within elliptic curve cryptography, you have this big number for your private key and this big number for your public key. And the math that's going on isn't like normal math, right? It's not like the math where we multiply numbers together, right, the way that we learned to do it in grade school, right? It's a different kind of math called elliptic curve math, basically. And I won't get into exactly what that is and how it works because it's out, it's even further outside of the scope than the scuff I've already described. But basically, it turns

out the way that it, the way that the properties of this math and the way that it works is, if you take the number that is your private key and you pick another number, a random number, and you multiply it by that random number. So private key times random number gives you another new number, right? If you use that number, you can use that number as a private key and generate a new public key, right? With me so far, is that making sense? So private key times random number, new number, new private key, right? So if it turns out, if you go back to that original private key, the associated public key, if you take that public key and you multiply it by the same random number, right, then the resulting number that you get, the resulting public key that

you get is the public key that associates with or is paired with that private key that we got in the first step, right? So in fact, the way that I'm works is in reverse. So what you as the sender do, or what the software does on your behalf behind the scenes is it takes a public key associated with the receiver. It multiplies it by a big random number and it generates a new public key from that operation. And again, this is all elliptic curve math that's going on, not normal math. And then what the user on the other side, the receiver can do is take that same, if you can communicate that same random number to the user, and we'll talk about that in a second. But if you somehow send that other, that random number to the user,

they can take it, multiply it by their private key and get the private key for the associated public key that you calculated as the sender in the first step. So again, a little confusing, but hopefully that sort of made sense. I'll let you ask some questions. Yes, absolutely. So, but that still leaves me to get the random number to you encrypted, right? Because if I send it to you unencrypted, then anyone can just try out which public key belongs to it, right? Right. Yeah. So you might be one.

This is exactly. So basically the question you're asking is, okay, that sounds neat, but what good has it done? Because I still have to send you that random number before you can figure out how to generate the new address, the new public key, which associates with the stealth address, the new address. So how do you, how do we do that? I still have to send it to you and you might as well have just sent me an address, right? So like what have we gained by doing all this this math? So what Umbra does to make this non-interactive is, remember we talked about how these public and private key pairs allow for this asymmetric encryption, right?

So effectively what we do then is we take the public key and we use it to encrypt that random number that we just created and we use to generate the new address. And then once we've encrypted that random number, we take that increment. encrypted data that nobody can decrypt except you as the holder of the private key. And we announce it on chain through an event in a smart contract, right? So UMbra is a smart contract system. There's an associated smart contract. Your funds flow through that smart contract when you make the payments. And we make an announcement, an event that gets broadcast on chain with that encrypted data inside of it. And so then what you do as the receiver when you use UMRA is you come,

you log on and you look at all the payments that have happened through UMBRA, every event that's occurred through UMBRA since the last time you used the app. And then you basically tried to decrypt each one and you're not going to be able to decrypt most of them, but you will be able to decrypt the ones that are payments to you. And so when you decrypt them, you get that random number that you need and you can use it along with your private key to generate the private key for the new stealth address that received the funds. And so we basically use events on Ethereum and indexing those events, processing those events locally on your computer because we want to keep it privately, obviously, to enable this data to be communicated in a non-interactive way.

Okay, I think I follow so far. Isn't it an awful lot of overhead for you to kind of look at every single event, not knowing whether this may be decrypted message for you? basically if this is something that kind of is used at scale, is that even computationally feasible? Yeah, yeah, really good question. So in computer science terms, this is like an O of N problem. So it's a linear, it scales linearly, right? So that's not terrible, but it's not great. Right? What it means is every time someone sends a transaction, every other user of the system is going to have to decrypt, attempts to decrypt that transaction when they go to receive their, on payments. So the way there are there are a couple kind of approaches that you can use to deal with that. And I would kind of put them in two buckets, right? One bucket is like sort of like researchy

sort of things, right? So you can think of like gossip protocols and different things that we can do like research that we can do to take this linear problem and make it like an O log end problem again in computer science terms, right? So one that is more scalable. And those are, there is research being done on that and we're very interested in that we're kind of following it and paying attention and would like to even presentially contribute to it in the future. But then the other bucket of solutions and these are the ones that we've pursued so far and there's still a bunch of more of them that we can pursue to make things more efficient are what I would call like the engineering hack bucket of solutions, right? And so these are solutions that don't make the,

they don't solve the problem in that it's still a linear, it's still an O of N problem, but they can take a lot, they can do a lot of things to improve the user experience, basically reduce the constant time cost that comes with doing this, right? So in the long run, you know, if we were going to scale this up to every payment on earth, which, by the way, I don't think it needs to or should, like there are a lot of different privacy solutions and different ones are appropriate for different use cases, right? And so Umbra has a set of tradeoffs that are valuable in certain situations, but not necessarily everyone. But if we were to scale this up to every payment on Earth, we need one of those

sort of like researchy solutions to come through in order to make this scalable. But we can get really far with what I would call the kind of like engineering hacks in terms of still providing a useful and acceptable user experience in the sort of like short to medium term. And so that's kind of where we are today. And I can dive into like what some of those are, some of the ones we've done already some of the ones we're looking at in the future. But yeah, that's kind of the high-level answer. So in my understanding of what I lean from the answer is that the computation still needs to be done in the background somewhere, it's just done such that it doesn't bother the user so much. Is that correct? Yeah, yeah. So let me dive into some of those possibilities, right?

So one of them is the one that you maybe alluded to, right? So when I described the system earlier, I said that we take the public key and we use that to generate the stealth address. And then we also take the public key and we use that to encrypt the data. In reality, in Umbra, the way that we do it is we actually have two separate public keys. And when you set up Umbra as to be a receiver, to receive payments, you generate two public private key pairs and you publish the two public keys in a registry. And one of those is a spending key and the other is the viewing key. So the first one is used to generate the stealth addresses.

The viewing key is used to do the encryption and decryption of these events. And so what that means is one option that you have, an imperfect option for sure, but at least an option, is you can give some third party that viewing key so that they can do the monitoring and decrypting on your behalf and then just let you know when you've received a payment. But that third party is not able to withdraw your funds. So obviously you've given up your privacy to that third party. but you haven't given up control of your funds to that third party. And there are a lot of, now that isn't perfect for everyone, right? There are plenty of people who are going to say, well, that's not a tradeoff I want to make.

But there are plenty of people who might say that that actually does work for them. So for example, if you're using this for like receiving payments or, you know, invoice payments or salary payments or something like that, you know, just like today, you're probably okay with your invoicing software company or your bank or whatever knowing about your salary payment or your insurance. invoice payment, you're okay with them knowing that. You just don't want it like broadcast and legible to literally everyone who knows how to go to EtherScan, right? So it might be an acceptable privacy tradeoff for you to give a trusted third party the ability to see what you've been paid, but not withdraw the funds, right? In fact, that's an improvement over today where your bank literally can see they're not really your funds at all, right? They're the banks until you withdraw them. So that's one sort of like simple, simple low-tech solution to this problem.

Putting that aside and talking about, well, what if I'm an individual user who doesn't want to give up my privacy? What options do I have? There's still a bunch of stuff out there. So one of them obviously is just like caching, right? So once you've decrypted, like Ethereum is, you know, past blocks are immutable, right? So once we've scanned that event once, we don't ever have to scan that one again. And so if you use Umbra to receive payments regularly, like every week, two weeks or a month, you're only going to have to scan the events from the last time

and decrypt the events from the last time that you use them. Another obvious one is just parallelization, right? These are totally independent things, right? And so computers are getting more and more parallel, like your MacBook these days has like 32 cores or more. And so we can blast those across all the processors on your phone or your computer and decrypt them in parallel. They're not contingent on each other at all. And so that that's a big help in reducing the time. There's another solution called view tags. This is something that actually comes from Manaro. We don't have this implemented currently, but it's something that we're looking into. And I won't get into the details there, but basically it's a constant time speed up where you can get as much as maybe like a 6x

constant time speed up on the decryption. And the kind of short explanation of it is like there's sort of like a two-step process. One of them is is computationally. inexpensive and then the other is the actual decryption, the process that we do today. And you can do the computationally inexpensive step to basically rule out big chunks of the transactions before actually doing the full computationally expensive step to see if it's definitely one for you. And so you can rule out five, six of the transactions before you even do the expensive step and then only decrypt the six that are left. And so you get a big speed up there. So this is just like a, you know, a short sampling of some of the things that are out there,

but there's a lot of juice to squeeze in terms of making this fast enough to work for users today before we hit the limit. Again, in the medium term, these approaches can get us pretty far. So let me recap and then kind of let's go over the user experience. So just to kind of reiterate how it works. So I want to send you funds. So you have an address, you have a public address and basically I generate a random number and multiply your address by that random number.

And then I encrypt the random number to send it to you. And then you can generate the private key to that new public key that I generated with the random number. And I can send funds to that to that. Yes, that was a good, good summary. The public key that you generate, that I go off of, is that just a standard Ethereum address? So basically, if you give me your metamask key, can I perform this? Or where exactly does Umbra actually come in? Yeah, yeah, really good question.

So as we said earlier, like elliptic curve cryptography is what underlies all of Ethereum, right? So your address, any address that you use in Metamask or whatever, is backed by a standard public key on, like the ones that we use in Umbra. Now, the address itself is actually the hash of that public key. And so if you know anything about hash functions, like you can't reverse a hash function. You can verify it if you have the plain text, but you can't take a hash and figure out what the plain text was, right? So if I give you just an address, that isn't actually enough information for you to know, what the pub key of that address is. So the public key has to be shared somewhere. Now, it turns out when you sign a transaction and send it to the Ethereum network, you effectively at that point

reveal the public key of the address. And so once at least one transaction has been broadcast on the network for a given address, we can recover the public key that underlies that address, and then we can use it in Umbra to do everything that we just described. That is a is possible in Umbra. Nothing about the way Umbra works prevents you from doing that. And in fact, we even support it in our front end, but we support it behind a flag that we call like an advanced mode flag. And we put like all kinds of friction in front of the user before we allow them to do that.

The reason is because as the receiver, the only way for you to receive your funds is to take the private key associated with your address and to then put that private key into a wallet, for like the front end of UMRA that supports looking for these transactions, right? That gives you all the functionality. And so obviously we don't want users pasting their private keys into like random front ends, even our own, right? It's just not a good security practice that we want users getting in the habit of doing. And so we allow you to do it if you know what you're doing. Like our app is open source. You can pull it down locally, run it locally, paste your

private key in there if you want feeling better about that we're not logging it or something like that if you know how to audit the code yourself, etc. But it's not something anybody should do normally. And so the way we have it set up is when you come to the Umbra app as a default user, if you don't go through the trouble of turning on this advanced mode, you sign a very specific message, a human readable message. It says like, you know, this message is used to generate your Umbra keys. You sign that message and we use the signature to generate two public private key pairs, the viewing key and the spending key that we talked about before. And what this allows you to do is we generate those keys from the signature from your address.

And so only you as the wallet holder can generate those keys. But, you know, you don't have to back up any new key material. Right. So if your seed phrase is backed up somewhere, you know, in a safe or on a piece of steel, then, you know, you're fine. As long as you can recover that address, you can sign that message and recover your umber funds as well. So no new key material comes into play. but it's still not actually the underlying key that's used for all of your other Ethereum stuff.

And then once we've generated that public private key, those two public private key pairs, we publish the two public keys in a registry. So it's just a really simple contract that you store, you know, you take your address, you associate it with two public keys. And then as a sender, you would come and you would look up, the software looks up in that registry, the address and pulls the public key for the viewing key and the spending key, you know, uses the spending key to generate the address, uses the viewing key to encrypt it and announce it on Umbra.

So that's the kind of scheme and the approach that we've taken for kind of like a user safety, user safety reasons. But Umbra is only a web app or can I download this as a desktop app? Because that would kind of alleviate a lot of your security concerns, no? Yeah, really good question. Right now it's only a web app and we hosted in the front end ourselves. We've explored before maybe packaging it up, you know, like using some of these technologies like electron or whatnot to like package apps up so that they can

run locally on the desktop. That's probably something that we should look into more in the future. We're also actually sometimes soon, it's on our roadmap to deploy Umbra to like a decentralized storage solution, which, you know, it doesn't really alleviate the exact problem that you were describing, but is something that I think is also useful. The app is also open source, right? So if you're a developer and you know like the basics of, you know, NPM and stuff like that, you can pull the app down and spin it up and run it locally. But right now we don't have a desktop app. It's probably something that we should explore some time in the future.

Okay, so let's talk about the users again. So the receiver and the sender, do they both need to be Umbra users, at least in the non-advanced node? Yeah, good question. So just to back up real quick, I want to add something that I should have also included. We hope in the future that like this stealth address

tech, like the stuff that underlies Umbra, will also be integrated in wallets so that users can use it directly in the wallet. So I think in the long run, that's like the ideal gold standard of how users would interact with this stuff. It would just be like an option in your wallet. So again, you wouldn't even have to worry about those private keys, public keys existing anywhere, anywhere else. And that's sort of why we develop Umbra as more of a protocol as opposed to like just adapt. We have a front end. We have a first party front end, but it's really just a set of standards that anybody can plug into. And we should talk more about our work to, in the future, to talk about to make an EIP,

a standardized EIP to push for exactly that future. But so getting back to the question that you asked, which is what is the user experience like for the sender and the receiver? Do they both have to be like Umbri users? So right now, the receiver, in order to receive payments, again, if you're not going to do this advanced mode thing, which we again recommend against, the receiver has to, has to do one transaction per network to publish their public private key pair that is used in the rest of the system. So if I want to receive payments with UMRA, the first step that I have to do

is go to UMRA, click setup, and it'll say, you know, sign this message, click sign in Metamask, and then it'll say, submit this transaction. It's a very low gas cost transaction. We've optimized it as much as possible, compressing the public keys, et cetera. And then you accept that, you pay the network fee and it publishes those public keys. It's a one-time thing. After that, you can receive as many payments as you want from Umbra. And then what you would do as someone who wants to get paid with Umbra is you would you would send, you would tell your sender, hey, can you pay me via Umbra? Just go to this app, go to this app, go to app.comba.cash and pay me there. And so as a sender, you go to those site and you click on send and you get a form that just

has like two address, token amount, right? Very, very straightforward. You don't have to do any setup, all you have to do is fill in those fields and click send and it sends the tokens, right, or the or the ether underlying via Umbra. You don't need to know any of the details of all the stuff that we just described. The software is taking care of all of that for you automatically. On chain, it looks just like, well, yeah, we can talk a little bit more about what it looks like on chain, tokens versus ether, et cetera. But for you as a user, it's just like another transaction interacting with a contract.

the gas fees are only slightly above what the gas cost would be for a normal transaction. Again, this is one of the advantages of Ambrough compared to other privacy solutions. Like zero knowledge proofs are super cool and awesome and have a lot of really cool use cases, but currently at least they're very expensive to validate on Ethereum, right? Maybe some pre-compiles in the future will make that cheaper. But right now, you know, validating ZKPs at the smart contract level is expensive. if we're not using ZKPs, there's no zero knowledge magic happening. And so the gas costs both for sending and receiving are minimally,

minimal compared to just sending and receiving in the clear. So yeah, that's a quick overview of the user experience for the receivers and the senders. So if I do this via your web app, what's the information that you can, US-URA can glean from that? So basically, if you say send funds to me and you say send it to ferns.eh, obviously, Anbra will know who's sending what to whom, because the address is kind of generated server side for you, right? So the address is generated, not server side, no, it's generated client side, right?

Yeah, so the web app is doing all the generation. Now, if we're malicious and we publish code in our front end that is, isn't doing what we say it's doing or is logging things back to our server or whatever, then obviously we can get that information. But we're not. And you don't have to trust us on that. You can go look at the open source version and run it locally yourself to validate that. But yeah, everything is done client's side. So as for us, as Umbra, we can't, what's visible to us is what's visible to everyone else, which is you sent a transaction to a stealth address. That stealth address looks like a brand new address on chain. We don't know who controls that stealth address. And we'll

never know who controls that stealth address unless they intentionally docks themselves or do something stupid on the withdrawal side of things, which is something we should talk about, about preserving your privacy as a receiver. But yeah, and same with the decryption as a receiver, right? All of that is happening client side. So unless, of course, like we talked about earlier, you delegate your viewing key to a third party intentionally. And as far as I know, there's no service is doing that right now. We've thought about building one ourselves and, you know, giving users that option, but so far we haven't, and not sure if the demand is there for that or not at this point. But unless you, so unless you delegate that to someone else intentionally, then everything

is done client side. So if you go to the app, like all the decryption is done on our side, we don't know which stealth addresses you control or you don't. Okay, say I haven't checked in for like a month. How, how don't would it take me to kind of go? through all the transactions to see whether I actually received anything. Yeah. So it depends on the network, right? And it depends because it depends on how many transactions other people have sent. Right.

So like if we deploy to a new network tomorrow and do a couple test transactions, it'll be like instant because it's really quick. But I think the network that currently has the most transactions that have gone through Umbra is Polygon. I think it's on the order of low hundreds of thousands. So maybe like, I don't know, maybe 100,000, 200,000, something like that. in total on Polygon. I think that's right. I think that's roughly right. Something on that order of magnitude. And right now I was actually just doing some testing with this yesterday because we

were tracking down a small edge case bug. And I think on my computer, you know, like kind of a middle of the road, eight core or whatever developer machine, it was taking me like three or four minutes to decrypt everything, you know, to fetch the data. That actually takes a little bit of time. as well. They have to fetch the announcements and then you have to decrypt them. And, you know, it was like the total time was three or four minutes. So that's not ideal. But obviously with like caching and stuff, that gets better. And that's currently the worst case scenario for Polygon. One thing that is, oh, yeah, and one thing that's worth noting there is that as he said, like, it gets worse as more people send transactions. And so one thing that we also do is there's a small

toll associated with each send that you do on umbra and the reason is we don't like there's a a griefing attack that you could do if you just you know whatever when it like it doesn't you can't steal anything it's not stealing funds or anything but you could just make everyone's life difficult by like wash sending a bunch of you know transactions through to yourself you're not losing any money and but you're adding all these events to the send history that now become this sort of like um you know uh this sort of like uh challenge for everybody else to decrypt on their side, right? And so there's a small toll that's associated with each cent that you have to pay, and that's purely as like a spam mitigation method, right? So if you have to pay a couple of cents, which is basically what we have it said to right now for

each send, then you're going to be, you know, discouraged from sending thousands and thousands of these, which is what it would take to make a noticeable difference in the decryption time. And that's only on low fee networks, by the way, on main net, the gas fees themselves are enough deterrent to do that, but on roll-ups or side chains like Polygon, the fees are low enough that someone who just felt like, you know, felt like causing problems for everybody could do that for pretty cheap. And so we want to make sure we have a mechanism to prevent that. Sure. What happens to the fiends? Yeah, good question. Right now, they are just custodied by the contract. We have an admin key. It's the only admin. It's the only privileged role in the system that we have right now. That admin has the right to

withdraw those fees. But again, it's on the order of like cents per cent, you know, and we've had a few hundred thousand transactions across all of our networks every time. So you can kind of do the math on how much that is. It's not a ton. But it's there to prevent spam. Now, it is an interesting question because we are working to try to develop an EIP standard to sort of make this like a global standard that anybody could use. And so then the question becomes like, okay, well, that's fine for UMRA, which is developed by scope lift, but what happens when this is, when we're trying to make this into a totally decentralized public good, where do those fees go? Should we just burn them? But part of the challenge too is that you want to be able to adjust

those over time, right, to say, oh, you know, gas has gone up on this roll up network. So we actually don't even need the fee anymore. We want to set it to zero. Well, that's an admin privilege as well. So who gets that if you're trying to deploy this as a totally decentralized protocol, which is the goal? And so that becomes, that is one of the challenges that we have right now and that we're trying to figure out with the CIP. You could also just redeploy, right? I mean, there's no network effects at play here, right?

So basically, you could just always re-deploy and kind of reset the fees. Yes, that would be an option. I guess the only like challenge with that is. is, you know, it just makes the like client software more complicated, you know, if there's like multiple places that you have to check if there's been payments and stuff like that. So yeah, there's like an overhead cost associated with it, but you're right. There's nothing where it's like there's not like a liquidity pool or something like there might be with a D5 protocol where redeploying doesn't, you know, a redeployment has some disadvantage compared to the original.

Good point. So we've been talking about sending ETH, but obviously you could also send any ELC 20 token. And then in principle, basically, if I send, for instance, you five optimism tokens, you may be in a position where you cannot withdraw them from the address without doxing yourself

because you have no gas, no ether for gas on the address. How do you go about that? Yeah, really good question. So basically there are two paths in Umbra's contract, and one is for sending the base assets, so ether or like Matic if you're on Polygon or whatever, and then the other path is for sending E or C20 tokens, and they're different for exactly this reason. And so when you send ether through Umbra, what we do is we actually take that ether

and we send it straight to the stealth address, right? And then you as the receiver, you can withdraw from that stealth address, but what that really means is just sending a transaction as that stealth address to send the ether to wherever else you want to send it to. And that's an interesting question. I think we'll come back to in the future where to send it to, but that's a separate question from the one you asked. As a, if you receive tokens and we did that with tokens, let's say we just sent the tokens straight to an address. Like you said, you now have to fund that address. How do you do that without doxing yourself? This becomes a challenge because you have to pay gas fees to actually move the tokens.

So the way that we solve that is when you send tokens in UMRA, we custody the tokens in the address. and the stealth address, the stealth receiver, has to sign a message in order to withdraw them. They can withdraw them directly, so you're not completely relying on a relay area. If you can fund the stealth address without doxing yourself, that's the route you can choose to go. But by default, what's going to happen is

you're going to use a relaying service to withdraw the funds from the contract. So you have to sign a message with the stealth address that received them. You have to agree when you sign that message to pay a small fee to the relay, to compensate them for the gas, and then the relayer will take your transaction or take your signed message and use that to submit a transaction on chain

that the Umbra contract will validate and say, okay, yes, the stealth address agreed to let this relayer withdraw for them to pay this fee and send the tokens to this new to this other address while paying the fee to the relayer. So that's the system that we have in place for Umbra for EOC20 tokens. I mean, that makes total sense.

How do you go about receiving NFTs? So basically, obviously, that works for vulnerable tokens because you can just sell, you know, whatever portion of it. But if you receive an NFT, how do you send it on? Yeah. So the concept of stealth addresses work for NFTs, unlike other privacy tools, right? Because you can send an NFT to a stealth address and the same properties apply in that as it would be if you were sending tokens. Like, okay, I see that you've sent it to an address,

but I don't know who actually controls that address. So unlike, you know, mixers or something that require fungibility, the privacy properties that you get from stealth addresses applied to NFTs equally as they do to fundable tokens, which is pretty cool. There are challenges with like the one that you described, right? So currently today, the current version of member that we have in production does not support NFTs. And this is one of the reasons why it doesn't, right?

there are solutions there are things that you could do there the simplest and easiest and we do hope to and plan to support nfts in the future and future versions of umbrah one of the easiest things that you could do there would be to give the sender the option to include some you know base assets and eth uh along with the nfti when they sent it right so instead of it being a transaction that just sends the nfti the transaction could go through the smart contract to send the nfti and a small amount of eath to the stealth address such that the user on the other side could use that eth to pay for gas to move the NFT in the future. So that would probably be the simplest solution. If you don't want to do that, then you get into, well, what basically mixing and matching privacy tools. So how can I fund,

how can I use some other privacy tool to fund the stealth address in a non-doxed way such that I can then remove the NFT without reeling myself? You alluded to this idea, even after having received something on a new staff address, there's a myriad of ways to kind of still give my identity away. So what should I do? Maybe I can turn the ground. What shouldn't I do? Good question.

Yeah. So the obvious thing that you shouldn't do is just immediately send the funds from your self-address to a doxed wallet, right? If you do that, it's going to be pretty obvious that this, These were funds that were sent to you. And that's actually like a lot harder to communicate than you would think to users. And this is one of the challenges that we've had with Umbro, which is the crypto community as a whole has kind of, because it was basically the first privacy solution available, mixers were, that is,

the crypto community has kind of anchored on mixers as like their, their mental model around what privacy tools mean in crypto. And so a lot of people think like, okay, well, if it went in and then I take it out, well, it's private or something, you know, like as if like that's just, there's like some magic that happened in between the two things. But that's not the case, right? You've sent it to a new address. And so if you want to preserve your privacy, you have to make choices that do that, right? Right now, there are not a ton of great options. So one option would be, this is probably, I would say, the biggest challenge that stealth

has still have. And I think we're exploring a bunch of possible ways to solve this. But, but there's it's still a challenge. So one option would be if you've received funds to a stealth address, you can either just leave the funds in that stealth address or withdraw them to a brand new address and just continue using that address, right? So if you receive like a big payment of ether or something like that, that's like an easy thing to do, you could then take that eth and swap it and, you know, invest in defy or do whatever and just continue using, continue using that address.

and no one except the person who sent it to you knows that you control it, right? That's fine. If you have, now the one obvious question is, well, even that solution doesn't work for tokens, right? So what do you do with tokens? One of the things that we've built into the Umbra contracts is this concept of a post-withdraw hook. And the post-withdraw hook basically says when you take your funds out of Umbra, when you withdraw your funds from Umbra, not only can you move the funds to some other location, but you can take arbitrary actions as well.

So you can basically do an arbitrary transaction on the network in addition to moving your funds at the same time. And you can submit that all through the relays. You can pay for the relator to do it. And so like one example of a post withdrawal hook that we could build, we actually have the contracts for this, but we haven't integrated it into the front end yet. But it's a question as to whether the U.S. is good or not

and whether you just really want it. But one of the things we could build, for example, would be if you receive die, say, you receive 10,000 die, and you want to do what I just described, which is just keep using that without, you know, unchain without do dachshing yourself. You could do a post-withdraw hook to swap some of that dye for each. So now you have, you know, 9,900 dye in a new address with $100 worth of ETH to pay gas fees. And then you can, you know, deposit it in AVE and earn yield or whatever else you want to do, right?

So the broader point is that this idea of a post-withdraw hook gives us the surface area to, integrate, and the fact that, you know, Ethereum is a composable chain and has all these other things available, gives us the surface area to integrate with other things that allow you to make privacy preserving decisions. So another obvious option would be, you know, there's a bunch of other privacy tools out there that do different things, like just one that we've done some work with them and we're interested in their tool as well. It's called Railgun. I don't know if you're familiar with Railgun at all, but it's an interesting privacy solution. but Aztec would be another one that your users would be familiar with, right?

So when you think about those kinds of solutions, there are solutions where you kind of have to enter into a shielded ecosystem, right? And so you could create a post-withdraw hook where you withdraw your funds and immediately shield them into some other privacy-preserving ecosystem like Aztec or Railgun or any other that is or could be developed in the future, right? So that's another sort of like on-chain native solution. The truth is that what I think most of our users are doing today is a lot less sexy, but is practical for a lot of use cases, which is they get paid with UMRA,

like say they're doing some work for a DAO. You know, we've talked to users who are doing this. They're getting paid by a Dow. They don't want that completely legible on-chain. The Dow pays them via UMRA. And then they withdraw their funds directly to an exchange, right? And so they send the funds to an exchange and they cash out to Fiat or send them back on-chain somewhere.

else, you know, effectively using the exchange as a mixer, obviously not a very good mixer because the exchange knows who you are, right? So you have to be okay with that privacy tradeoff, but again, for a lot of use cases, that is acceptable. I mean, even if you're okay with the exchange knowing who you are, these days, exchanges only give you one deposit address. So if you use that trick and it's like a one-time trick. Yeah, it depends. Different exchange. do different things. A lot of them do do one deposit address per asset these days. You know, if you don't, if you only ever used it for Embra, right, then it allows you to consolidate the payments. So you can say like, okay, these different payments all must have

been going to the same entity, but you still don't know who that entity is. But you're right. It's a problem. So yeah, there are, there, this, this is, I would say, the biggest challenge that stealth address addresses have. The privacy properties are really nice in terms of receiving payments in this non-interactive way that aren't obvious on chain. But then it's not necessarily necessarily easy to make privacy preserving decisions after that, after you've received the payments, right? And so this is one of the things that we're working on. As I alluded to, there's this possibility for integrations via these withdrawal hooks. And I think it's one of the places where we can make a lot of improvements in the future. And like I said before, like, I don't think stealth addresses are like a, are like the silver bullet for privacy. Like they're one tool that has a specific or a set of specific use cases and properties. that are useful for certain things. And I think in the long term, in general, for the Ethereum ecosystem and for, you know, crypto ecosystems in general, I think there's not going to be like one tool that like,

oh, this is how you do privacy. It's going to be more like there's a bunch of different tools that give you different properties and you have to sort of know how to use them in conjunction with each other to get the level of privacy that you want and need for whatever your kind of situation is. And I think we can do a lot to make that the UX for doing that easier. But I think that's sort of the reality of privacy in crypto is that there's always going to be multiple tools and you'll have to understand the properties of the different tools

and make decisions to kind of like get the level of privacy you need. Yeah, I mean, as a user, I mean, to us, it seems almost normal. But I mean, if you explain it to anyone else, it would seem crazy, right? Basically, it's like, yeah, so what actually happens is you have several wanted in your different pockets. And you know, you can't mix and can't put like $5 from one to the other. Or everyone will know that they both belong to you. And if you want to, if you want to kind of consolidate,

you have to get like really big pass, kind of like the ad tech or radar gun analogy. And you have to put it in the past. And then in the past, you can exchange money from one wallet into a new wallet. And then basically there's enough to abstract away here for the average user. There is for sure. And so the UX, there's a ton of work to do to make the UX better. You know, I think like a couple things I would say to that.

One is that all of that does sound insane and is to a certain extent, like it'll get better, but it's never going to be, it's never going to be zero friction, right? All other things being equal, a solution that gives you more privacy is probably going to have some additional friction and some additional cost than a solution that doesn't, right? Just sort of logically, that's the case. And so users have to decide the level of privacy that they want and need and are willing to pay for and willing to put up for with an additional amount of friction. One of the things, by the way, that is just a reality of the privacy space, in my opinion,

and learn this firsthand with Umbra is that privacy is one of those things that everyone says they want, and everyone says that they're willing to put up with some friction or additional cost to get. But revealed preferences seem to be that a large chunk of the population, a majority, a large majority, actually doesn't feel that way. Because if you put even the smallest amount of friction or additional cost in their way to achieve privacy, they just don't do it. They choose not to do it. And so, yeah, that's just like, you know, for some of us like myself, like it just is, that's insane.

Like it just like we like, like why would, you know, but that does seem to be the reality. That's okay. Like people can and should make the decisions that they want, but we want these tools to exist and to have the lowest friction and barriers as possible out there. The other thing that I'll say about something that makes building a privacy tool challenging is that there are users out there who do care about privacy. and care about it quite a lot. And for whatever reason, maybe their circumstances, maybe just their disposition, really want the maximum privacy that they can get

and they are willing to pay for it. It turns out, though, that it's really hard to talk to those people because they value their privacy. And so doing user research for a privacy tool and understanding the use cases that people care about and what they're using and what they're not is really hard because those people don't want to talk to you for good reason, right? So this is just a general structural problem with creating privacy tools.

It's really hard to understand your user base. It's really hard to understand if you have product market fit or not. And I don't have a great answer to that. We kind of just have to like stumble forward. I mean, even something like as simple as like we, right, the UMRA app does not have any client side analytics at all. Right. And that's because we felt like it doesn't really seem right to have a privacy tool and a front end for our privacy tool and then be like logging every single action that our user takes tied to their IP address, right? So we don't do that. But that handicaps us, right? Because we don't know like, oh, like that feature that we shipped, are people really using that or not? Like we don't know and we can't tell easily, right?

You know, some things have like a footprint on chain that you can follow. Like, okay, we know that people are sending this token because we can see the funds flowing through. We don't know who they're signing them to, but they're doing it. So obviously, like people wanted to send that token. But we don't, you know, other than that, like more detailed, intricate stuff, we don't know because we choose not to, you know, invade our users' privacy because it's a privacy tool and that would be counterproductive, right? So it's just a structural problem with developing privacy tools, I would say, in general.

I also find that people usually say they value their privacy, but no one actually runs their own node. I mean, in FURRC is everything you do. Correct, yes. But it's not that difficult to run one, but people don't care, right? So basically then kind of needs to be quick and same for desktop apps. So I think people should really use them. Anyways, I have one more area that I would kind of like to explore. And that's smart wallets and account instruction.

So in my understanding, kind of using this stealth address model, but only works for EOAs, right? It doesn't work for smart contract wallet as it does. Okay, fantastic. I see you're nodding. So talk me through it. So sort of. So the scheme that we used today that I described earlier is we have you use your EOA to sign a message to generate that public private key pair. we effectively do that as a convenience layer thing right like it's a because we want the we want users to be

able to to use the setup they already have which for most people is a wallet like metamask or a wallet connect wallet on their phone or whatever with an EOA right and and so that's sort of like the setup that we have today signing messages but but there's no reason that that is the way that the that you have to generate the public private key pair in that way right so like you can generate a public private key pair at any way that you would like. And as long as you publish it in the registry and don't lose the associated private keys, then you're good. And so there's nothing that prevents this from working with a different wallet. And in fact, you know, these account obstruction law, some of the ones that exist, I'm not going to be able to remember up on my head. But there's like

a standard for how they do message signing, like how you sign a message with a notice to save or whatever. or like, you know, maybe you would know a bit more about that, actually. But, you know, the, yeah, there are ways that you can do that. Now, where it gets tricky is, like, some of these wallets, they have, like, the idea of, like, social recovery and stuff like that, right? Where it's like, you, if you can completely lose your private keys and still, like, get all of your assets back. That part doesn't work with UMRA because at the end of the day, there is a public and a private key. There is a public key published somewhere, and that's the public key that someone is using to,

to generate the stealth address that's receiving the funds. And so there has to be a private key that you like preserve somewhere, right? And don't lose. And so if you, you know, use some wallet that has account obstruction and social recovery and you lose the private key that's associated with that and the one that you lose the private key that was used to like generate the public key on Umbra. And then someone sends you funds. Just because you social recover the rest of your app doesn't mean you're going to be able for the rest of your your assets that were stored in that that wallet doesn't mean you're going to be able to go get your funds that haven't yet been withdrawn from umbra out of the system right because those funds were sent using a specific public key if you lose that private key there's

there's nothing that we can do right so i wouldn't say it's not possible to use with these you know smart wallets and whatnot it just adds like a layer a little bit of layer of complexity and it again at the end of the day you have to you have to retain this this key material right um and if you know Today, if you're using an EOA, we do that via the signature, so it's not a big deal. You already have to retain the key material of your EOA, you're fine. But when you get into these social recovery mechanisms and whatnot, it adds a layer of complexity that you have to think about. Maybe switching gears a little bit. How do you think we get to a word where people care about privacy, right?

Because basically, if you think on it, there had been so many revelations over some. say the last 20 years or so. Back in the day, people said, you know, why would anyone spy on me and I'm boring? I have nothing to hide and so on. But it's become so apparent that this is not a blocker. Even if you're really boring, lots of things can still be learned from you

and are learned from you unless you are incredibly sophisticated. What do you think it would take for people to win back their outrage and kind of ask to take back their privacy or just take back that privacy. Do you think it's kind of a little bit like, you know, the analogy with the frog, it's being slowly boiled, right? So when's the point you kind of jump out? Is it going to kind of make people care about their own privacy? I don't know. If there was, I wish I knew it. I don't know. I don't know is the short answer. I mean, we'll have a few thoughts on it. Like, in terms of like individuals, like quote unquote, everyday people, whatever that means, normies, not meant pejoratively

at all. Like, I'm not sure the majority of them are ever going to care unless, like, things get really bad in whatever jurisdiction or, you know, particular locale that they're in, right? Like, and, and they really are being targeted in an obvious and visceral way that motivates them to, you know, really start taking it seriously. I just, you know, I'm not sure that. And so maybe we can move the dial a little bit, get a higher percentage of people to start caring, but I'm not sure that, you know, unless, unless for you as an individual, things get really bad, your most people are going to care. And, you know, look, to a certain part of the answer is like, that's, maybe that's okay. Like, if people want to make

those decisions, like, that's, that's their prerogative, et cetera, et cetera. You know, to me, it's like self-evident that you should want better privacy, but like, obviously it seems not to be for everyone, right? That that's like a self-evidently good thing. So yeah, it's just an interesting reality. And I'm not sure I have an answer on the individual level. One thing that I will note, and this is like part of our thesis with Umbra as well, is that like, whereas individual, you know, people seem not to unmask care about privacy as much as they quote unquote should, whatever that means, right? Like, it does seem, it seems self-evident that businesses and commercial applications care about some level of privacy more than maybe the average user does, right? So if you're a

business and you have some relationship with a vendor and you're paying them some amount, right, that's not something that you're trying to hide from like a nation state, but it isn't something that you want blasted out in public for everyone, right? And same with maybe like things like paying for things on e-commerce, right? Like, I think that This is another example where maybe you can get like the average user to care at least a little bit, right? Like, okay, would you want every single e-commerce vendor that you used? Like, is there anything that you buy that maybe you don't want everyone knowing that you're buying that thing, right? Like, like maybe it would be better if there was some kind of privacy payment system that kept that at least not completely legible.

So, yeah, I mean, I don't know. I don't have a silver bullet there. I think certain people are just never going to care. People will care maybe when things get really bad in their particular situation. Businesses will care. And then some percentage of the population does care. And I think we just have to find ways to make these tools available so that when and if people need them or want them, you know, they have the option and make it as easy as possible to adopt them. I think that's a fair assessment.

So where can people learn more? about Umbra, where can they look at the code, where can they join the community? Absolutely. So you can go to app.unbara.cash to use the app. You can publish your keys with one cheap transaction and then you can receive payments there. You can join our Discord, which is linked on the site as well. And that is where we do announcements and people chat. and, you know, if there's ever any tech support or anything needed, you can find it there.

The GitHub page is also linked on the app, but it's Scoplift slash Umbra-Dash protocol. And it's a mono repo that has the front end, the smart contracts, and the SDK for interacting with those contracts all are hosted there. And you can check that out if you're a developer. And then Umbra is on Twitter at At Umbra Cash. and you can follow us there for announcements and whatnot as well. Perfect. Thank you so much for coming on, Ben. It's been a pleasure.

Thank you very much. It's really been a great conversation. Appreciate it. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device,

you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter. dot TV slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.