ZKSnacks Blacklisting Coins
Speakers: Max Hillebrand
Date: April 1, 2022
Transcript By: Stephan Livera
Media: https://www.youtube.com/watch?v=NtLCL9ztEuQ
podcast: https://stephanlivera.com/episode/364/
Stephan Livera:
Max, great to chat again.
Max Hillebrand:
Oh, welcome, Stephan. I’m really looking forward to this conversation. It’s gonna be a fun one.
Stephan Livera:
Right. So look, as I’ve mentioned, I think we’re gonna disagree a bit on this one, but let’s chat it out. Let’s discuss what’s going on in the world of Bitcoin and privacy. So obviously the main topic here is going to be around what’s going on with Wasabi Wallet and the blacklisting, but if you wanted to just give us your thoughts on how we got to this situation, or maybe just provide a bit of an overview about what’s going on for listeners who aren’t familiar and then we can discuss the various issues.
Max Hillebrand:
Yeah. So the TLDR is that the ZKSnacks coordinator of Wasabi Wallet—the default—has decided to start blacklisting or censoring certain UTXOs that are associated with known criminals, to the best of its ability. And why is that a problem in the first place? And I think for that, we have to go back all the way to the very beginning of where CoinJoin was actually discussed: 2010, I think the concept came around, and then 2013, Gregory Maxwell formalized it, that you don’t need to be a single user making a Bitcoin transaction all by yourself with only inputs that you actually control. Because if you do that all by yourself, the common input ownership heuristic applies. So whenever you see someone making a payment with multiple inputs, you can assume all of these inputs belong to the same person, even when they’re not on the same address. This is some additional information that you share with every Bitcoin transaction that you make. And then in 2013 there came this concept of a CoinJoin: let’s just get together a group of users where we all have some inputs and we all have some outputs and let’s just make a transaction together. There’s nothing in the Bitcoin consensus protocol that says it’s not allowed. And the big question is then—so we’re as a group now building a new PSBT, new partially or unsigned CoinJoin transactions where people have their inputs and their outputs. And the question is: how do we get a consensus on which transaction are we building here? Which inputs are included and which outputs? And in which order? Because since all inputs need to sign the exact same message—the actual transaction referencing all the inputs and outputs—that’s a consensus problem. And all the way back, we had centralized solutions to this consensus problem. Just: let’s pick one computer that keeps the PSBT, and users need to connect to this computer and say, Hey, these are the inputs I want to register, these are the outputs I want to register. And, you know, centralized things are “easy”: they’re fast, they’re scalable—they just work. And then we saw multiple centralized CoinJoin implementations, like, for example, Joinmarket being one of the early pioneers. And then Wasabi coming later, where the big difference is that, in Wasabi or Samourai, you see a single coordinator that is connected to by all clients by default. So you download a packaged software and you as a client now connect to the default coordinator, which is just one long-term reputable person. And hopefully, if there are not enough app downloads and people depositing money into their wallets, then hopefully they’re gonna register and hopefully you’re gonna have enough liquidity, because we’re here trying to hide in a crowd. So you need a crowd, and hopefully lots of different people look very different on the input side. You want to get a lot of different transaction graphs consolidated in the CoinJoin. And these coordinators with a steady reputation have done a decent job at that, to some extent, but a Joinmarket has a brilliant solution to this, too. So an actual user who wants to make a CoinJoin to a very specific round parameter—like, exactly this standard denomination or equal denomination I want to create—the user is the coordinator as the taker and he defines the round parameters. But then how are you gonna get liquidity into your CoinJoin? You’re just this random identity on the Internet. Why would anyone connect to you? You’re not even packaging yourself as the default in some software. Well, the market is the solution. You just pay people to provide liquidity, and those liquidity providers are the makers. They’re willing to CoinJoin with any round parameter for the amount of sats that they actually have. They don’t care what the standard denomination is—they just want to CoinJoin. And that is a very genius solution. It distributes the task of running a coordinator, because there is not just one for the software, but every user has the coordination code included and every user can spin up a taker very, very easily. However, it’s still quite complex, and even though it’s a great solution, there’s room for other solutions. And this is then where centrally coordinated CoinJoin wallets with a steady long-term reputable coordinator is there. But whenever you have a trusted third party—here in the sense of a trusted third party with whom you build your PSBT together, and that’s the one single computer that has the authoritative copy of which transaction are we gonna sign—well, trusted third parties are a security hole, and that’s why there is a big problem here. For one is: how are you gonna talk to that coordinator? For example, Joinmarket uses IRC servers, and no actual blinding in the protocol itself. So you as the maker just provide all of your inputs and all of your output addresses in a single message to the taker, and then the taker can actually spy on you as a maker because there is no encryption used—and that’s a problem. So Gregory Maxwell already back in 2013 had this one single line in his description of, Hey, how about we just use Chaumian blind signatures? And we basically create an eCash token—a digital bearer certificate—which represents access rights to this PSBT whiteboard. So you can purchase yourself some access credentials in input registration when you present your input and you prove that you’re actually the one who controls the script and can sign for this input. And when you’ve done that, the coordinator will put your input into the PSBT and he will give you this digital bearer certificate—a blind token—which is the access rights to also write an output to this PSBT board. However, because this is a Chaumian eCash, the anonymity set of any token is all users, and so the coordinator cannot differentiate any of these tokens. So when you later come and you present a token and you register your output, the coordinator has no way to link you to the input side. He does not know which input is associated to this output. He just knows that there was an input—he has verified that—so it’s not that someone is registering just an output of 1,000 Bitcoin, even though he doesn’t have an input. And that’s very important. So with using advanced blinded cryptography, we can reduce the amount of information that the coordinator has. And that’s a very crucial point, because the more information the coordinator has, the more you’ve attributed yourself to these actions, and the more there can be selective censorship going on. So the ultimate goal is to reduce the amount of information that the coordinator learns to as little as is reasonable and possible. But the thing is, you still have to talk to the coordinator and you will still have to provide some information. Specifically, which input are you registering? And also, which output are you registering? The coordinator might not be able to link the one to the other, but he can still see that a certain input was registered. And well, I don’t think that there is any way to get around this problem in Bitcoin. The coordinator and all signers just need to know what are the inputs and the outputs—there needs to be a consensus on this. That’s the entire point. And that means that there is gonna be some level of control and censorship inherently just in the protocol. And specifically, as we’re seeing it now, the coordinator can just say, Hey, this certain input, I’m like pretty sure that this comes from a hacker who stole thousands of Bitcoins from innocent users. And you know what? I just don’t want to allow this certain input to be registered—for whatever reasons—we can go into them at a later point. But this is just one piece of information that any coordinator will always have. And whenever you must reveal some information, you can be associated to it, and the other person can make decisions based on the information that you have revealed specifically here, not allowing you to register. And so the proper solution around this would maybe be something like a decentrally coordinated CoinJoin. So we remove that single computer that keeps our authoritative copy of the PSBT that we’re building and we distribute this out so that there’s just a network of peers that share information in multiple rounds with everyone, and they then get a consensus on which transaction to sign without there being a single third party that they all trust. CoinShuffle or CoinShuffle++ are great decentralized CoinJoin protocols—they’re just very complex, inefficient, and slow. And so even though we looked into them, it’s just—building stuff decentralized is bloody difficult, and doing it centralized is a lot easier. And I think that’s why we will stick with centralized CoinJoins for a while, but any centralized CoinJoin has that problem that you might be excluded from its round.
Stephan Livera:
Yeah. Okay, so let me just summarize some of that for listeners to make sure everyone’s following along. So the idea is: there are today three well known CoinJoin providers—and we’re gonna get into exactly what does that mean—but the general idea, as you were saying, is that people who want to participate in the CoinJoin, they’re registering their inputs into that CoinJoin, this CoinJoin coordinator is helping with that, and then you are receiving those coins on the output side. As you said, the registering of the outputs part. And of course there is that architectural difference with, say, Joinmarket, where it’s coordinated through IRC channels. And basically it’s like the maker and taker—there’s a little bit more going on there, that the taker is the one who is paying the CoinJoin fee, and then he gets a little bit more privacy because of that. Whereas the maker is the one sitting there just providing his coins for liquidity for the CoinJoin. Whereas the Wasabi and Samourai model, there is a coordinator who’s actually doing that as a centralized entity. Now, I think to bring that now to what’s happening in recent weeks with Wasabi Wallet and ZKSnacks, it seems—so going back a few years, it was never seen like, Oh, we’re gonna have multiple coordinators—this seems to have been a recent change in the language or change in the strategy. Why is that now this is becoming now the way? Because isn’t it that people have to build up a reputation in a particular coordinator, whether that’s the Samourai coordinator or what used to be the one Wasabi Wallet coordinator? Why is it now a change in that reasoning and strategy that there should be multiple?
Max Hillebrand:
Yeah. So there has always been a default coordinator in both Samourai and Wasabi. But just to stick with Wasabi for now, the code for the back end is open source. Everything from the very first commit—both client and back end—free and open source, very well documented of how you can run the back end coordinator by yourself. And in fact, for the 1.0 ZeroLink coordinator, a couple people did that. I know of a handful, maybe five mainnet coordinators, that provided the exact same service that ZKSnacks did, but with some different configurations in the wrong parameters. Because again, if we have a trusted third party, that central coordinator defines the wrong parameters. What’s the minimum and maximum input value? What’s the standard or equal denomination that we generate? All of these things are just inherently defined, dictated, by the coordinator. In the Joinmarket model, because the taker is the coordinator and because the taker actually has inputs and outputs, you’re gonna choose a denomination that suits your preferences. And that’s awesome because you can make a CoinJoin with some random denomination like 10.675 Bitcoin or something, and you’re still gonna get people to CoinJoin at specifically that value that you want—that’s awesome. This way you can actually have payments in a CoinJoin just with having one standard denomination. At least one person can make an arbitrary amount payment—the taker—but with ZeroLink, it’s different in the sense that you just have one coordinator that does dictate the exact round parameters, and this coordinator is not even a user of the CoinJoin. He doesn’t have inputs. And for example, in Wasabi’s case, the ZKSnacks coordinator had the minimum denomination of 0.1 Bitcoin, and that was like the one default denomination that every user had to be part of. So if you have less than 0.1 Bitcoin, sorry, but you can’t CoinJoin. And if you have 100 Bitcoin, well you’re only gonna get a large anonymity set for the 0.1 Bitcoin denomination, so you’re gonna have to get many different UTXOs. But if you have 100 Bitcoin, you get roughly a thousand coins worth 0.1 Bitcoin, so that’s a bit tough. And then we saw other coordinators defining different standard or equal denominations. So for example, the ChainCase ZeroLink coordinator, they had a 0.01 Bitcoin or 0.05 or something like that, just because it was on mobile. People don’t tend to have that much Bitcoin on mobile wallets and it’s still alpha software so you want to take it slow, but that’s a very valuable thing of why you would want to run a different coordinator, because you want to have different round parameters. And of course, mainly on the technical level, these round parameters do include the equal denomination—especially in ZeroLink. Not so much in WabiSabi, but we’ll talk about that a bit later, maybe. And then one additional configuration that you can do is just deny certain coins to register to your round. And again, that’s nothing new—that has always existed in Wasabi code—that’s the denial of service protection. If you have a CoinJoin with a bunch of inputs and outputs, and one of these inputs fails to sign the CoinJoin, then you can assume—because you have denial of service protections—you can assume that this is actually a malicious user who wants to disrupt the round. So what you do is you start the next round, a [blame] round, but there you exclude, you censor, that specific input that did not sign. So this blacklisting logic has been in the code since day one. And it has been executed and people have been blocked in Wasabi already.
Stephan Livera:
Max, to be clear though, that is for a different reason—I think we could agree. So there is the reason of having certain protections in the code to allow a CoinJoin round to proceed despite, let’s say, one user who is being malicious or maybe even in a non-malicious case—maybe their Internet cut out or something like that. And so the coordinator might logically say, Look, fine—we’re just gonna exclude party A from the CoinJoin because they are disrupting the CoinJoin whether intentionally or not. That’s distinct from the blacklisting that we’re talking about today, right?
Max Hillebrand:
For sure, yes, but I’m just highlighting that this idea of having multiple coordinators has existed in the past. And there are many reasons why you would want to run your own coordinator. And one of the other main reasons is because you want to control which inputs are actually gonna be registered there. Like, you can have invite-only CoinJoins. There are ZeroLink Wasabi coordinators out there where the actual onion is not public knowledge. So someone needs to invite you by sending you this onion, and only then can you CoinJoin. So here you could have CoinJoins just among your friends who know about this onion address of the coordinator. So to curate who actually gets to register is already a live use case of one quite big ZeroLink coordinator. And sure, it’s very different to now also add the additional metadata that we have on the Bitcoin blockchain that chain surveillance companies provide—all these tags of the risk factor of certain coins. Yes, that’s definitely something new, so I’m not trying to [downplay] this here. But it’s somewhat of a soft fork, right? You’re changing the acceptance of which coins do you consider valid—not on the Bitcoin consensus layer—that’s the other important thing. Bitcoin consensus is still permissionless and decentralized enough that you can make payments even if you are blacklisted: you can just either get hashrate yourself or bribe a miner to hash a block with your transaction in it—so Bitcoin works. But what we’re talking about here is: will you get access to someone else’s computer? Will someone else allow you to write stuff on his computer, basically? And in my opinion, ultimately it comes down to property rights. A coordinator is just someone else’s computer—and it’s not yours. So you ought to be quite thankful that someone actually provides you a service where you can use his computer for certain things like coordinating a round. Well, for arbitrary reasons, any entrepreneur can decline to do business with anyone. Now sure, we can talk about the rationale behind the selective curation of your customer base as an entrepreneur, and that there can be strategic blunders here—absolutely. You might lose a shit-ton of customers, but there might also be quite valid reasons for doing this. But fundamentally I think—ethically speaking—it’s very much in line.
Stephan Livera:
So this is where we are coming to—and I think we were talking on Twitter—maybe I left a comment under one of your posts saying, I think this is an obfuscation a bit. Like, you’re saying that you’re retreating back to this idea of, Oh, it’s the freedom of the entrepreneur. And I think basically most people in Bitcoin already accept this freedom—I think I would say: that’s not the point in contention here. The point in contention here is more about you actually doing what you set out to do. And look, Max, this is something you’ve commented I believe even maybe two years ago or 2019 or around there, you were literally saying—or not in these exact words—but you said something like, Chain surveillance, you are my enemy. We’re trying to end you, or something similar like this. And you tagged in a bunch of these chain surveillance companies. And now it seems very disjointed or awkward now that you’re in a position where ZKSnacks is actually having to work with one or some of these entities. How do you square these two ideas?
Max Hillebrand:
Yeah, definitely. For me personally, my views did not change. I’m actually still quite critical of the decision that ZKSnacks made here, and arguably this is quite a blunder. But again, I’m not the company—I’m just a random contributor, so I don’t get to make the decision, and it’s even tough for me to question these decisions. So, yes. And the reasons why I have so many quarrels with these companies is—for one, that Bitcoin is a public ledger, so they are just accumulating whatever information that they already have. But the thing is that many Bitcoin users have really bad practices when it comes to privacy usage of this public ledger: address reuse, massive input consolidation, rounded payments amounts—all these things. And basically, chain surveillance companies now prey on the mistakes of individuals. And that’s just—for me—a weird thing. I mean, I have nothing inherently against private investigators, but it just seems to me as being a really odd business model, and I still don’t support it. However, it is just the reality: there is outside consensus metadata of the Bitcoin blockchain, and certain coins are attributed to certain users. Now, in some very few cases, we have a very clear definition or like it’s very obvious that a certain coin belongs to a criminal. For example, the Bitfinex hacker—that was massive consolidation of all the money that he stole, and it’s not that easy to hide 10,000s of Bitcoin. So in that case, for example, its was pretty obvious—Hey, this is someone who just literally stole Bitcoin. Bitcoin is not unconfiscatable. You can steal Bitcoin very much. You can take Bitcoin that is not yours, specifically in such a custodial clusterfuck as that was. And then that’s the question of: so what do we do when we actually have cases that are very clear-cut? But then the more pressing matter is it’s not always gonna be clear-cut, especially when you start making transactions, especially when you have things like CoinSwap, Lightning, PayJoin—we’re working really hard to make the life of chain surveillance miserable, and that means that they’re gonna have many more false positives. So they’re gonna say that this coin is owned by a criminal, even though it’s actually a peaceful individual. And they’re gonna have false negatives. There’s gonna be a bunch of criminals who are gonna use Bitcoin in a privacy-preserving way that’s gonna be very difficult to attribute their actions to the coins that they have. This is what I have a big quarrel with—the false positives and the false negatives. And I would say that, at least as I understand it, ZKSnacks will try to only focus on these cases that are really clear-cut—very obvious, very little ambiguity, because only then it works. Because if you have too many false positives and false negatives, it doesn’t make sense—you’re just disrupting your business way too much. But in a really clear-cut, obvious case—I get it.
Stephan Livera:
So I’m not sure how much you’re able to share or how much you know, but are you able to share like which chain surveillance tool is being used here? Like, do you know the method by which these obvious or clear-cut determinations will be made? Or is it like a black box that users are meant to just submit to the black box without knowing if their coins will be censored out of or stopped from participating in a CoinJoin round?
Max Hillebrand:
Yeah, I actually don’t know yet which company is being chosen. But as far as I understand it, there’s a risk score between 1 to 10, 1 being the least risk, 10 being the highest, and the idea is to only take out risk factor 10. Right. So only the highest—that could be argued is the one with least ambiguity. But again, I’m not sure on this—this might change. And then the question of is it a black box—I guess it is, because this is a configuration on the back end server. You just don’t know what the configuration is. And I don’t know if the choice of which coin categories are blacklisted. Like for example, saying chain analysis risk factor 10, or something like that—if that would be revealed in the coordinator GET status API request—I don’t know. Arguably it could be. But one really, really interesting difference is: if a custodial exchange does the chain surveillance, they only get the information of which coin paid them after the transaction was broadcast. It’s out—the Bitcoin is sent. And then the custodian is in possession of the Bitcoin, and then they are saying, Okay, no, actually we don’t like the transaction history so we’re gonna refuse this. But then you have this issue of a refund process. Now we actually need to refund the money to the person who sent it to you, and that’s very complicated and usually another privacy leak. But with CoinJoins, it’s very different. A CoinJoin is fundamentally secure in the sense that no money moves until you verify both inputs and outputs of the final transaction and you sign it and everyone else signs it. And I think technically how this is gonna work is that during input registration or at the end of input registration, an API request is made to the chain surveillance firm, and then you see which inputs are not allowed or blacklisted, and these then get a response from the coordinator with, Sorry, we could not allow your coin to be registered because of these reasons. But the cool thing is: your money never moved—this was all during the coordination of the PSBT. Nothing was signed and your input isn’t even revealed to other participants of the round. So there’s never gonna be an issue that you’re gonna send money somewhere in the CoinJoin and then all of a sudden it has to be reverted because of the censorship. This happens even before you move your coins, like before there’s any chance of signing the transaction. So there is an interesting nuance here with CoinJoin that custodial providers have different.
Stephan Livera:
So I understand that point, that you are saying, in the case of using a custodial exchange, you might be then in the position of asking for your coins back, but in this case with Wasabi, as an example, you might have some coins outside in a different wallet and you spend them into Wasabi Wallet, and then basically what you’re saying is: Wasabi Wallet would then poll or API call to the chain surveillance company and say, Hey, is this coin from Stephan? Is it a risk factor 10 coin? Yes? Okay, then Stephan’s coin cannot participate in the CoinJoin with ZKSnacks as the coordinator. That’s essentially what you’re saying, right?
Max Hillebrand:
Yeah, exactly. Just, of course—we don’t know that you’re Stephan. We just see a random TOR identity popping up and registering a single coin. Another interesting thing is: if you have, let’s say, five coins that you want to register and one of them is risk factor 10 but the other four are not. The cool thing—what we fixed with WabiSabi—is that there is no longer input consolidation in the coordination protocol. Whereas ZeroLink, you had to provide one API request with one TOR identity where you list all of the inputs that you want to consolidate in this round. With WabiSabi, that’s gone. So you create a new TOR identity and just push one input through that to the coordinator, and then another new independent TOR identity, and that connects to the coordinator. So ultimately, the coordinator no longer knows which inputs belong to one user in this round. So in our case here—one blacklisted coin, four none—your one blacklisted coin would get the response, Hey sorry, you can’t CoinJoin with this, but the four other ones would still go through because the coordinator has no way of knowing that they actually do belong to you or to the same person that has the blacklisted coin.
Stephan Livera:
Yeah. And the weird thing to me though is: if the idea is these are privacy tools, isn’t there a little bit of a contradiction here, because in some ways, one of the arguments is—and this is even on the Wasabi Wallet FAQ—is that some of these chain surveillance firms oversell their capability. They overstate their capacity to actually trace coins. And so isn’t it a contradictory thing where you’re speaking out of both sides of your mouth here, because it’s kind of like we’re saying, Oh look, use this privacy wallet, and, We don’t like the chain surveillance companies because they are overstating their capabilities. But at the same time, you’re like—at least ZKSnacks, not Wasabi Wallet—ZKSnacks is paying or presumably working with them to get their opinion on whether this coin is high risk factor or not. Don’t you see a contradiction there?
Max Hillebrand:
Absolutely. No, no, for sure. One of my main points that I quarrel with as well is: there are false positives. There are false negatives. These are all based on heuristics. And yes, they are oversold tremendously. So yeah, that’s a contention. But still, there are some cases where it’s really clear-cut—the BitFinex hacker was one of them. And if you try to only take out these cases—it’s not perfect, I absolutely agree. But there’s a lot of nuance in how you could implement this. And my personal opinion on the final judgment of what ZKSnacks is doing here very much is still out in the open, because it just depends on the nuances. If, all of a sudden, all Canadian truckers, all peaceful Russian civilians start getting blacklisted, I would have big quarrels with that. But if, on the other hand, only politicians and other violent criminals are getting blacklisted—well, you know, then I’m happy. So I guess it really depends. There’s a lot of nuance here, but in general what we can say is: yes—that is another precedent that UTXOs are not fungible, that there is metadata associated to UTXOs that are outside of the consensus implementation. And that’s just super difficult because now you’re gonna have different surveillance companies that have different blacklists and different risk scores associated to it. And now you have competing soft forked clients, basically, that reach a different consensus of which coins are good and which coins are bad. And well—there’s no solution to it. Bitcoin is the only solution to reach a decentralized consensus on something like this. And obviously Bitcoin doesn’t work if you would have KYC and all these things baked in. So yeah, I agree: there’s a lot of uncertainty here, a lot of edge cases where it’s definitely not going to work. But this is why we need a free market. This is why we will have even more WabiSabi coordinators, I think, that just try all the different things. And one of the other big things that we didn’t mention yet that should be obvious: not just do entrepreneurs have the choice of which customers to work with—obviously, customers have the choice of which entrepreneur to work with. So you don’t have to talk to the ZKSnacks coordinator if you don’t agree with this censoring just for any reason—on ethical grounds or not even if you are affected from it, you might not even be blacklisted yourself but you still might disagree with the choice that the coordinator did—and then sure, use another coordinator that makes sense. And that’s a good thing. So in a free market, all these conflicts over what service should be provided and how should a customer and entrepreneur collaborate together—like, that doesn’t work in a centrally planned system. It only works in a free market because there we have optionality and choice. And so I think there is a large user base who would insist to not CoinJoin their coins with known public criminals with the risk score 10, for example. That was one of the feedbacks that I got especially from companies and institutional people of, Hey, how about you CoinJoin? Well, the first thing was, It’s too expensive. It just consumes too much block space. We fixed that with 2.0—it’s way more block space efficient. And then the second thing was, I don’t want to CoinJoin my money with criminals. I personally don’t agree with that statement, but it was one of the major feedbacks that we got. And now if you would have on the coordinator side a blacklisting curation of these known criminals then a lot of users are gonna be happy. A lot of users are not gonna be happy because they care about freedom of speech and permissionless interactions, but some users just want to be perceived as not dirty. And it’s just a reality that this concept of taint and metadata—as flawed as it is—it’s just a reality of how it works today. And then we saw, for example, a lot of CoinJoin outputs being blacklisted with custodians precisely because there were some high risks associated with them. Now if you would remove all of the high risk inputs, then blacklisting the outputs doesn’t really make sense because there was no high risk input so there cannot be a high risk output—kind of, at least to some extent. So arguably, that might improve the blacklisting of all CoinJoin outputs with some entrepreneurs who just don’t want to work with that risk of the ambiguity of a CoinJoin. Now I get that that’s not the most strong of all arguments, and I think the jury is still out—I don’t know if the acceptance of CoinJoin outputs will increase for the ZKSnacks coordinator compared to others who don’t have this. I guess we’ll see how the market reacts.
Stephan Livera:
The way I’m seeing it, I think very few people would want to use this because I think it just goes very anathema—it’s very anti, the whole idea of having a privacy wallet that censors people, and obviously with the DoS reason aside. Censoring people based on the past history of that coin just seems completely antithetical, in my view. So I’m just very confused. And I think probably the other question that a lot of people have is: why is ZKSnacks trying to pre-comply or comply before there’s even a regulation or even some kind of police instruction or law enforcement instruction of, Hey, you must stop these bad coins. Why is ZKSnacks jumping the gun?
Max Hillebrand:
Yeah—another of my main quarrels with this. Just to be clear, there is no regulation that would compel this, and I don’t think that there would be anytime soon because it’s freedom of speech, man—the coordinator is just a message relay. It’s a chat room. You pass messages from left to right. If that’s illegal, like oof, everything breaks down—civilization is at an end at that point. So I hope that it will never reach that point that some outside party will compel ZKSnacks to blacklist certain UTXOs. And by the way, just because ZKSnacks is now blacklisting some coins doesn’t mean that regulators will be happy, because some will say, Blacklist all Russian civilians or all truckers. But as far as I get it, ZKSnacks would not do that. And there might still be friction here. So again, this is a soft fork. Other people might not agree with the consensus rules that you have. There’s a lot of nuance here. And so it’s a tough one, really, and I would have preferred if this were a client-side policy. If, on the client side, you could blacklist certain risk factors, for example—because there are people who would be super stringent. I want to go all the way down to only CoinJoin with risk factor 1—lowest risk possible—for example. Some clients would have this specific preference. And maybe it could be implemented in a nice way on the client-side so that if you don’t care, you just leave it all the way up to 10, and if you do care, you configure it. And maybe that would have led to a better outcome because you can still talk to one coordinator and all the risk factor coins can still talk to one coordinator, and then we just figure out on the client-side of how to allocate this—maybe. I really hope to see a future where a lot of the CoinJoin coordination goes a lot to client-side and the optionality of a coordinator becomes less and less. I think we’re getting there—we’re not yet there fully. And one of the major downsides is that then every client would have to have an account with the chain surveillance company. If you want to curate the coins that you’re seeing in this proposed CoinJoin and you decide whether or not you want to CoinJoin based on the metadata risk factor, you need to ask the chain surveillance company and then you need to get an account and KYC, probably, in all of this. So—not that easy. In the meantime, just doing it top-down from the coordinator-side is a solution that—assuming that you want to do this—it is a solution that is cheaper, because only one person has to talk to the chain surveillance company compared to all the users who want to do it.
Stephan Livera:
Yeah. And I think that’s probably the other point that’s very antithetical is this supposed privacy company is now paying a surveillance—like, presumably there’s a payment relationship going on here where ZKSnacks is paying the chain surveillance firm for access to their surveillance black box to figure out which ones are risk factor 10. And it just seems so antithetical to me. Like, why would you want to participate in that? Why would users want to be a part of this system?
Max Hillebrand:
Yeah, good question. And I agree—I would prefer if ZKSnacks would’ve hired another developer compared to paying the surveillance company, obviously. However—for one, it’s their money—who am I to disagree where they spend it with. If hookers and coke—do it. But on the other hand, the vast majority of the revenue still gets reinvested in free and open source software. Like, it’s crazy how many people get paid for working on Wasabi and other projects by now. So yes, some money goes to the enemy—the majority still stays within the ecosystem. So I think, yes, a lot of users will disagree with the move and go to a different coordinator entirely, but I’m not sure if everyone will do that.
Stephan Livera:
Yeah. Okay, and the other point that—perhaps I’m speculating a little bit—but when I saw this news I got a bit skeptical and thought, Is this a regulatory capture play? So, as we see with the likes of the chain surveillance firms, they are trying to go out there, market themselves to governments and market themselves to exchange compliance teams saying, You need us to help—because they’ll market it like, Look, see, we’re keeping the crypto streets clean. When I think people who know better understand that a lot of the heuristics and this kind of tainting idea is oversold, as we’ve agreed. So is there an angle there that ZKSnacks is almost trying to get into the regulatory capture game to say, Look, see, we’re a regulatory-compliant CoinJoin, so therefore, Mr. Government or Mr. Regulator or Mr. Central Bank, please do not shut me down—or exchanges, please do not blacklist the coins coming out from me, ZKSnacks coordinator, you know?
Max Hillebrand:
Yeah. That’s certainly a desired outcome. And again, I don’t think that governments have the power to actually shut down the coordinator and mandate a certain blacklist. And I still think ZKSnacks is gonna make a legal stance on that because they want to actually choose what to blacklist—they don’t want to be dictated what to blacklist. So I don’t think that this free speech argument is over, but I think it’s to some extent at least delayed. I think that this move extended the lifecycle of ZKSnacks as a company, just because there are obvious regulatory risks involved with this, and anti-money laundering laws are crazy—they’re really insane. So yeah, there’s gonna be some aspects of it that might still lead to contention in the future. But one other thing is that: if you, as a CoinJoin coordinator, if you want to work with institutional clients, hedge funds, insurance funds, Michael Saylor, and all these people, well, even if ZKSnacks were not to be regulated, those customers might very well be, maybe because they’re custodians of other people’s money or whatnot. And then these regulated entities can only become users of a coordinator—arguably, I’m not sure—if such a blacklisting is involved. Again, the major feedback that I got from institutionals regarding CoinJoin adoption was, I don’t want to mix with criminals—my compliance team is gonna take me apart on that one. Now, I don’t know if there is an actual concern here or if this is just, again, some preemptive speculative compliance, but arguably there is. So we might see this world where ZKSnacks specifically has a bunch of liquidity from institutionals that are just not comfortable to CoinJoin with another coordinator which has the Anyone can join policy, including criminals. And so there’s really a lot of nuance here. So yes, this alienates a lot of users—me being one of them—but also this will encourage a lot of new users to come in. And that is why it was a preemptive step from ZKSnacks, because the question was—I mean, we’re already really big, but we want to get even bigger—how do we not just attract more liquidity, but how do we also ensure that our legal set up will survive in the long run and we’re just not completely overwhelmed with court cases and things like this. This was just one preemptive move to help with the scaling of the company, because we think that now we can provide the service at a much larger scale while still having way less regulatory pressure than before, because again, the coordinator can blacklist inputs and he can at least pay someone else to find out what the risk factor of this input is. So if you now do take the preemptive step to exclude known criminals, that might be desired by certain customers. But again, I really struggle to say something here with certainty because preferences are subjective and value is subjective and customers will have their own preferences that I just don’t know and could never predict. And so I’m gonna be very, very, very curious of the actual on-chain activity that ZKSnacks has and that other Wasabi 2.0 coordinators will have. I mean—defaults matter a lot. That’s the other thing. And if you download the Wasabi package and you just by default connect to that one coordinator, obviously he still will get a large liquidity, but it’s gonna be very curious to see how other non-blacklisting coordinators do, in any case.
Stephan Livera:
So a couple reactions, but first I want to talk a little bit about the free and voluntary interaction part. Because as we’ve been talking about a lot, we’ve been talking about the free choice of entrepreneurs, of consumers, but there is a serious risk then of regulatory capture if, say, the regulation gets crafted in such a way to say, Ah look, see this company is doing it—why doesn’t every other company do it? And if you’re not doing it—that’s now the new regulatory standard. And then what happens is one big company gets—the regulation almost becomes a cocoon or a defensive moat around them that then does actually influence other people’s choices in a way that’s not voluntary, right? Because we’ve been talking about voluntary, but when it’s government regulation, that’s not voluntary. So there’s a lot of people who might then get impacted by that regulatory capture angle of it. Would you agree?
Max Hillebrand:
Yeah, absolutely. And that’s a big risk and that’s why this is a bad precedent. This is the first CoinJoin coordinator to actually do that. And yeah, that might lead to it being misinterpreted that this is required to comply with anti-money laundering regulations. But again, ZKSnacks isn’t really making that argument. They’re just saying, We are still the only one who can make this decision of whom to work with or not. We’re not gonna tolerate anyone dictating us certain users that we cannot work with, unless there are sufficient reasons that we agree with. So this free speech argument is not yet over, and we’ll see how ZKSnacks will handle this and pioneer this in the future. But again, there will be other coordinators and they will be legal entities too—some of them, at least—and some of them will very much pursue a legal battle to make a clear precedent that this is not at all required. So I really hope that someone spins up a new coordinator, has a staunch free speech and anti-censorship ethos, then earns a bunch of money and uses that to defend himself in legal courts and set legal precedents—that would be great. I would love to see that. And to a certain extent, ZKSnacks is gonna do exactly that, too.
Stephan Livera:
Okay. So I guess there’s a couple other things that people—I mean, there’s always debates, back and forth, about what’s going on with Wasabi, but one of them that I continually see is things around address reuse. And it seems like there’s this constant debate back and forth there that, Oh, that’s an old bug, but then it’s still occurring. And then we’re hearing different stories of people speculating that, Oh okay, is it that there are different users running the same seed on different Wasabi clients? And therefore, that’s why we’re seeing this address reuse? From your perspective, Max, why are we seeing address reuse still in Wasabi Wallet CoinJoin?
Max Hillebrand:
Yeah, that’s a good question. There were numerous bugs and edge cases. Some of them were triggered by running multiple clients in parallel, which is just not a supported way to use the software—it just won’t work. But also, we didn’t have a way to actually discourage users to do that. There wasn’t a big notification—ah, actually there was just an open PR that implements this so that when one client sees coins of its wallet registered that he did not register himself, then he will shut down and not CoinJoin anymore. So that will solve some of this further. There was some weird behavior in Bitcoin Knots that we didn’t anticipate where it lost mempool after restart, and that led to some CoinJoin coins being no longer recognized in the client—unconfirmed. And then these addresses weren’t marked as spent and then they were reused in the future—things like this. I’m probably forgetting a couple. There was something in our block filters tool, I think. But yeah, software is bloody difficult. And the problem is, mistakes on mainnet are memorable. And when you run buggy software on mainnet—and there are certain bugs—they will just get fixed afterwards, but the mistakes that you made are still there. So I think a lot of the things that we saw were either even already fixed at the time where the mistake made but the user was running an out of date client, or later it got fixed. So there is however the big question of, Should the coordinator be actively blacklisting certain addresses that are reused? Or coins that come from a reused address? And that’s a tough one because address reuse is a “legitimate” use of Bitcoin. You can have a public donation address. And then, for example, you have multiple coins on the same address and now you want to register them in a CoinJoin, and that’s gonna be a coin from a previous address that’s gonna be registered again. Or if you want to make payments inside a CoinJoin, you might want to pay someone who actually has an address reused. So there might be multiple CoinJoins that have outputs of this one receiver who has a static address. Things like this are all possible and therefore blacklisting it on the coordinator side is difficult. Now there are some cases where you can do that, and I think there’s something in the code there now. And so yeah, it’s a tough one. I personally like to think that the coordinator really is quite stupid—it’s just a PSBT whiteboard. And ultimately, it’s up to the user of which coins to register and which addresses to register. Of course, I would hope to say that the bugs are fixed now. We actually saw on Testnet some address reuse, too. And then we found that we actually had a bug in the new code—2.0 related. So that is fixed now. And I think now for the last couple weeks, there hasn’t been any address reuse on Testnet, so I’m thinking, I’m hoping, that it’s good now. But yeah, there’s just a lot of edge cases that you need to consider and it’s not easy, but hopefully we’ll have bug-free software now, at least in that extent.
Stephan Livera:
Right. As I understand—I mean, I still see it’s like even an hour or two ago I saw there’s an address reuse happening in some Wasabi CoinJoin. And maybe part of this is an architectural difference as well. So as I see in like, say, the Samourai Wallet where they do a Tx0 and they split it out earlier, then it may be that that’s an easier way to stop address reuse. So I’m curious as well, from your perspective—and I don’t know whether you are speaking for ZKSnacks or just for yourself—what is the reason for that architectural difference? Is it an efficiency thing? Is it some other reason?
Max Hillebrand:
Yeah, absolutely—block space efficiency. Saving users on mining fee cost. That was always a design constraint in Wasabi. And ZeroLink is “flawed” in many ways. For example the input-to-input linkage. And the input-to-change output linkage—the coordinator knows, at least. And there’s only one denomination or multiples thereof. So you could have a ZeroLink implementation like Samourai that implements the on-chain graph in a way that adheres to the limitations of the coordination principle. So every user only has one input and every user only gets one equal amount output and no change. This way, the coordinator cannot link anything here—and that’s great. It’s just horrendously block space expensive, because for one, you need to have two transactions: your Tx0 and then a second transaction. And so you have multiple coins being created and spent, which is a large cost, and you have the transaction header overhead. So transaction batching is a massive fee savings. Like, we’re talking—I don’t know, it depends—but 70%-80% or something like this, just if you batch the Tx0 transaction with the actual CoinJoin. You could also then have multiple denominations in separate transaction pools like Samourai does. The one with 0.1 0.5, one Bitcoin, five Bitcoin—whatever. But here again, it’s more transactions—more UTXOs being created and destroyed—therefore just a whole bunch more fees. And another thing that we specifically designed Wasabi 2.0 for is that we’re still batching the different denomination pools, so to say, but in a way that, if you have five Bitcoin, you’re still going to give privacy to the plebs—the plebs who have little Bitcoin, like let’s say only 0.1 or something like that. The whale is still gonna participate in the lower denomination CoinJoin outputs, and therefore the anonymity set for those lower denominations is gonna increase. If you would have only a round of plebs, you would have less anonymity set in that round than if you add the whales into this and the whales also get some pleb-sized outputs. And so we have an implementation of ZeroLink that did have compromises in the extent that we accepted certain things that the coordinator will learn, like multiple inputs being able to register at the same time from one user. And in some cases also, results on the blockchain transaction graph—those privacy drawbacks—but they just come at a massive fee savings that is really, really, really substantial. The demurrage (carrying) cost of using money privately should be low. We want to have cheap transaction fees for private payments, and creating a bunch of UTXOs is just inherently super, super expensive. But what we did with the 2.0 research is we fundamentally improved our coordination protocol. We fixed all the flaws of the ZeroLink coordination protocol. You can now consolidate multiple inputs in a round anonymously. You can now create multiple outputs in a round anonymously of whatever arbitrary amount you want. If you want to create an exactly 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9 output, you can do that. And it will be—on the coordination level—as private as any other amount. So because we’ve now reduced the amount of information that the client needs to share with the coordinator, we can go even more into block space savings. And I don’t know the exact number, but something like: Wasabi 2.0 is maybe a hundred times cheaper than Wasabi 1.0 for some use cases. And that’s mainly because of—
Stephan Livera:
That’s in terms of miner fee, not in terms of CoinJoin fee, right?
Max Hillebrand:
Yes, exactly. The main cost is, by far, mining fee. Coordination fee is trivial and already now in a low fee environment. Even if you have 1 sat per vByte CoinJoins, if you’re creating hundreds and hundreds of coins, you’re gonna notice that—it’s gonna eat into your budget. And so we’ll for sure have to optimize for this in the future when fees are sustainably high, but even right now, it is very much noticeable. Again, one of the main feedbacks that I got from especially corporates is, Hey, I have a low margin business. I just can’t afford to spend 0.1%-0.2% or something on the mining fee—that’s crazy. I have a margin of 2%. Like, I’m not gonna give you like half of my revenue. So yeah. And one other major thing—if you’re only allowed to register one input then you cannot make payments. So let’s say you register one input worth one Bitcoin and you get a one Bitcoin private back. And now you make a payment of 0.3 Bitcoin. So now you have 0.7—how are you gonna get back into the 0.1 Bitcoin round? You can’t, because you cannot consolidate your 0.7 with another coin that you have to get above the 0.1 again. So that means that you cannot CoinJoin, make a payment, and then CoinJoin again. That doesn’t work. It even doesn’t really nicely work in Wasabi 1.0, but there it works better than in Samourai, because at least you can consolidate batched in the CoinJoin itself. And there’s some outside ambiguity, but with WabiSabi and Wasabi 2.0 it’s fundamentally fixed, because you can register as low as 5,000 sats on the input side. And you can consolidate an arbitrary number of coins I think up to 10, and the coordinator won’t know that one person is doing this. So that just means you can CoinJoin, and then you make a payment, and with the change output that you receive you just CoinJoin again and you can register just the one change output and not consolidate it with any of the other inputs that you control in your UTXO set. So there’s no consolidation penalty in the remix that you make because you don’t need to consolidate because any amount is good. So this just means: with 2.0, you’re gonna be able to just CoinJoin all the time, basically. At first, we don’t even have payments inside CoinJoin, but it’s coming. So at first, you just make a single user payment outside of the CoinJoin and then you can CoinJoin the change—with a fun thing added, that for the change and the payment output of the single user payment, if all the inputs of the single user payment are CoinJoin outputs of that coordinator, you can remix for free. Without paying the coordination fee. Of course, you do still have to pay the mining fee. That’s another thing that’s difficult with the Tx0 set up: you don’t know the fee rate in advance but you’re creating in advance the coins that you register into the final CoinJoin round. And they’re only two fresh coins and like three remixes, something like that—maybe flipped around. But that just means that you have a fixed fee that you will pay all the time and you cannot adjust it, and that kind of sucks, too. So you’re gonna overpay or underpay for fees, which is not optimal. You’re gonna, again, save on fees if you’re able to adjust the fee rate at the point where you’re actually creating the CoinJoin itself. And so these are just some of the—I think—many nuances of why I’m not a big fan of the Tx0 set up. I don’t think makes sense. Yes, it generates perfect CoinJoins, per se, but it comes at a usability downside, at a fee estimation downside, and especially at a block space downside. And all these, I think, are very much reason enough to look for alternatives. And yes, our Wasabi 1.0 implementation wasn’t perfect—we could have done it a lot better even in the ZeroLink coordination concept of Chaumian blind signatures, but we decided instead to fix the actual CoinJoin coordination model and make it so that it works with arbitrary amounts, that there’s no input-to-input or output-to-output linkage. Well, we did that. But now comes actually the crazy part of: given that we now have the ability to create arbitrary amount CoinJoins with private consolidations, et cetera., well, which output amounts do we actually now choose? Because the coordinator now no longer says everyone needs to get the 0.1 Bitcoin output. The coordinator says: everything between 5,000 sats and I think 1,300 Bitcoin is good. There are, however, some denominations that are preferred, and we curated them based on some research and simulation. And these are basically low Hamming weight numbers: so, powers of two, powers of three, powers of ten, in a one to five series. And the cool thing is that with these low Hamming weight denominations, you can very efficiently decompose any arbitrary input amount into only a handful of outputs. So you have your one Bitcoin input—a single one Bitcoin input—and you get three or four coins back, and they all have these standard denominations, but because of how we arranged this client-side, almost every denomination has at least a couple anonymity sets. So, equal outputs with exactly the same denomination as these others. We did some simulations: I think if we have fifty inputs, we have nine change outputs, meaning that they are not equal—they don’t have another equal amount. And the average anonymity set size was something like three and a half. But then if we increased that, it gets a whole bunch better. So if I remember correctly, a hundred inputs was something like only three change outputs with a median anonymity set size of five. And then if we are above 350 inputs, we get only one change output—like one standard denomination, one non-equal amount—and that is usually the coordinator fee. So basically: every user only gets coins that has at least two anonymity sets, but on the median they have nine anonymity sets. So when we have a lot of inputs being registered with our client-side amount decomposition that is now possible thanks to WabiSabi, we get a whole bunch more efficient. Like, we don’t purchase block space for change anymore. Change can be linked to your inputs—why would you ever buy block space when it can still be linked to your input? It doesn’t make sense. So we just don’t buy block space anymore when it’s not private. So basically, every block space that you purchase will increase your ambiguity. And in basically no case will it stay the same—and that’s just more and more block space savings.
Stephan Livera:
So just so I can understand that then: what we’re talking about here is a CoinJoin that has a massive number of inputs, as an example. So we’re talking about basically a huge, huge transaction. It’s got literally 200 or 300 inputs. And then on the output side there, what does that look like for the end user? Is it one cycle and then they get their output UTXO at the end of it? Or can you explain that part for me?
Max Hillebrand:
So there is still gonna be a slight fan-out, on average. So if you have something like 300 inputs, you’re gonna get 340 outputs—so a larger number of outputs than inputs. That’s not always the case, but it is the case on average, at least in our simulations. And that means that our UTXO set does slowly grow. We create more outputs than inputs. We could tweak it to actually create less outputs than inputs, but then you would have non-standard denomination change with no anonymity set. And we figured that it’s efficient enough to go all the way that you only create private block space and no change. And then the question of how much anonymity set would you fancy, would you like? I think that depends a lot on the user. What are your preferences? They’re subjective, and it’s difficult how we’re gonna get that feedback, because how are you gonna ask someone to give their preferences? It’s not easy. The way that we figured is basically three different modes: optimized for speed, optimized for privacy, and optimized for cost. Currently, you choose one out of these three, and there are other ways that you could get more fine-grained nuance out of this—that’s where the Austrian method comes in with subjective, marginal preference. You could have three attributes—speed, privacy, and cost—and now you ask the user, Please rank order these three attributes to how you want your wallets to behave. So it might be my highest priority is privacy, my second priority is speed, and my lowest priority is cost. So I want to have privacy first and foremost, I want to have it rather quickly, but I really don’t care how much money I spend. Another example would be: my highest priority is cost, my second is speed, and my third is privacy. So, first of all, I don’t want to pay much for block space. Second of all, I still want to get it somewhat fast, but really I don’t care about the privacy—like, a little ambiguity is good enough. I know I’m not on the FBI most wanted list, so a little bit of anonymity is all right. And the results of this question of user preferences will adjust the behavior of your block space accountant—the robot with whom you charge to purchase block space on your behalf. And that can be in numerous things. So one would be, for example: how many UTXOS do you want to create? If you prioritize cost above everything else, you would want to reduce the number of coins that you create, because mining fee is the most substantial. Another thing to control for cost is the current fee rate of the CoinJoin. So in the Joinmarket taker, the maker-taker model, the coordinator—one of the users—just defines the fee rate and pays it. But in the reputable, persistent, centrally coordinated model, the coordinator chooses the fee rate. And so at some point in time, the current fee rate is gonna be way higher than it was in the past—you know, a mempool spike. And you can basically filter out those mempool spikes by saying, If the current CoinJoin fee is larger or higher than the median of the last week of all CoinJoins that happened, then I don’t want to register. So you basically only register whenever it’s lower than the average of the last week.
Stephan Livera:
So it’s sort of waiting for a good window to opportunistically say, Oh hey, the mempool is low—let me put mine in now. That, in sort of a coded way.
Max Hillebrand:
Exactly, yeah. And then how do we control for privacy? Well, that’s mainly the anonymity set calculation. And here we calculates a very conservative lower bound estimate. So we only count a number of equal amount outputs, and that is your anonymity set. And then there are very strong consolidation penalties. So even though the coordinator does not know which coins you consolidate—you know, an outside observer maybe still might get some information—so when you consolidate multiple coins, we just take the lowest common denominator. So you have a ten anonset, a five anonset, and a three anonset coin, and you all consolidate them, and then the combined lowest common denominator would be three anonset. And let’s say on the output side you get another five anonset. So you have three anonset on the input side—because of the consolidation penalty—five anonset on the output side, so that’s eight—I think that’s how it works. So then the question is: how much anonset do you actually want? And here, for example, if privacy is your lowest—you’re okay with maybe five anonset—and you’re gonna get five anonset basically in a single round. Maybe not for every denomination, but for most—for sure. But if privacy is your highest preference, you might actually want to go all the way to a hundred anonset, for example. And now we also have this concept of the minimum and maximum anonymity set range. Whereas previously it was a target, now it is a range. So that means if you’re below the minimum, you will always prefer to register those coins below the anonymity set target minimum. And if you reach over that minimum but you’re still below the maximum, you will only occasionally CoinJoin. You will prefer to CoinJoin the ones who are lower, but you will still do occasional remixes whenever it is opportune. But then if you reach the maximum anonymity set, you will just not CoinJoin anymore. That’s the sanity check of: if it’s more than a hundred, that’s plenty—please don’t waste any more money on buying block space—a hundred is sufficient. And that’s the controlling mechanisms here.
Stephan Livera:
One other question I’ve got with Wasabi 2.0, as obviously I haven’t used it: is there going to be a segregation there between pre-mix and post-mix? Is that segregation going to exist? And is there going to be something like a post-mix spend tool? So in Samourai, for example, they have Stonewall, Stonewallx2—these are some examples. So is there going to be some kind of analogue or something like that in Wasabi 2.0, or is it a different model?
Max Hillebrand:
So yes, there’s still the concept of coins that are known by a certain identity. So basically your label. Generate a new receive address saying, Hey, I’m sending that money to Stephan, so that address to Stephan—he’s gonna pay me. And maybe he uses the Kraken exchange and he just makes deposits out of that directly. So I write: Stephan, Kraken, for example. This will automatically have a one anonymity set, and therefore Wasabi will prefer to CoinJoin it. Then, if it is below the minimum anonymity set score, we keep the labels. And so that metadata is still there. You only got three anonset but your minimum was five, for example, so it would still show you Stephan and Kraken know that this is yours. And as soon as you get above the minimum anonset threshold, that label metadata disappears though—we consider this coin sufficiently private where Stephan and Kraken no longer know that it is actually mine. And then whenever you make a single user payment, Wasabi will always prefer—in its automatic coin selection—to send those coins that are above the minimum anonset target, even above the maximum anonset target. So in most cases—since all of the coins that you get get some anonymity set—in most cases you’re gonna have 70%-80% of your wallet balance above anonset target coins, and therefore you just select automatically some of them. You don’t care which ones are selected because all of them are “fungible”—all of them have some ambiguity. Another cool benefit is that, because we have these low Hamming weight standard denominations, they don’t just effectively get decomposed from one input to multiple outputs, they also get very efficiently consolidated. So let’s say you want to make a payment of 1.2 Bitcoin or something like this—because you have a lot of these standard denominations, you might just have to consolidate a handful of coins to actually get that, and you’re gonna get exactly the amount that you want to have. So there’s not gonna be change coming back to you. We’re actually automating that process now, that whenever you type in a payment amount, Wasabi will calculate for you in the background and say, Hey, a change output is created if you set exactly that fee rate and that payment amount, but if you sent a little bit more or a little bit less—and often it’s just a matter of a couple sats—there’s not gonna be a change amount created.
Stephan Livera:
Right. So it’s the kind of stopping the change—change avoidance. Yeah, change avoidance, I’ve heard it referred to. So that’s an interesting idea. So I think some of it comes down to—for the user, thinking about, What am I going to use? It comes down to, in their mind, what quality of CoinJoin are they looking for? And they have to then decide what tools are available in that ecosystem, if they’re using Joinmarket or Samourai or Wasabi, they have to think about that. So I think it comes down to: I think there is just that difference of trying to deal with unmixed change inside the mix. So I think that’s probably the—
Max Hillebrand:
And that’s fixed in 2.0—there is no more change. So that’s another reason why there is no XPUB segregation or so. There’s just the metadata segregation. But since there is no change anymore—at least in most cases—that’s all right. You don’t need to have proper segregation of all the block space—all the outputs that you get are fungible.
Stephan Livera:
Right.
Max Hillebrand:
And then in terms of post-mix tools, so Wasabi has the PayJoin sending capability, so if you want to send to BTCPay or something, that works. Not yet receiving—that will come. There is actually an old, old PR that makes it work, but we didn’t put much effort into it yet. And I guess this change avoidance can be considered as a post-mix privacy tool. However, there’s no such thing as these two-party CoinJoins or fake CoinJoins, because of, again, block space efficiency, and it just having some small ambiguity but needing to purchase twice as much block space is a question of if that’s actually worth it. And for me personally, I would like to obliterate the post-mix world in the sense of: make every spend a CoinJoin. And you can do that in WabiSabi, again. You can register arbitrary amounts and nobody knows who registered it. So I think we’re gonna see payments in the CoinJoin so that I’m a Wasabi user and you give me your address and then I just put it into an output of the huge CoinJoin with exactly the amount that you would want to have. I might need to be able to generate multiple addresses for you, because CoinJoin rounds fail and you don’t want to reuse addresses across different rounds. And so I might need your XPUB, or at least some gap limit of multiple addresses. That’s one thing. But the other thing that’s even more exciting is payments inside a CoinJoin. I call it pay-to-end-point WabiSabi. So here we have a scenario where both Stephan and me are Wasabi Wallet users, or at least we understand the WabiSabi CoinJoin protocol and we talk to the same coordinator. And let’s say I want to make a payment to Stephan. Now I register an input—not with Stephan—but I register it with the coordinator. So a new TOR identity talks to the coordinator, I register my input, and now I get this my eCash credential, these key-derived anonymous credentials. And let’s say I registered one Bitcoin, so it’s one Bitcoin worth. And now I can reissue this credential to myself. It’s like an internal transfer in the eCash system which has the anonymity set size of all the transactions that happen in the eCash system. So I just make one reissuance where I break up the one Bitcoin credential into two credentials worth 0.3 and 0.7. And now I have a new credential that is 0.3—just a string of text. That’s a signature, basically. And I can give that credential to Stephan. So for him, it’s just some arbitrary looking gibberish, but he can now go to the coordinator and request—
Stephan Livera:
And claim that.
Max Hillebrand:
Well, he first requests to reissue the credential, too. So you present that 0.3 credential and you go to the coordinator and say, I would like a 0.2 and a 0.1. But we’re actually using Pederson commitments here, so the coordinator does not know the amounts that’s happening—he just sees one credential gets presented and two get redeemed. He doesn’t know the value in them, but he makes sure that all outputs equal inputs. So this way now, you have two new credentials that nobody knows are yours, basically. And these credentials, again, give you access rights to write to the output side of the PSBT. And so during output registration now, you connect to the coordinator directly. You don’t connect to me, but you connect to the coordinator, and you present him the 0.2 credential and you say, Please send it to this address. Then you create a new TOR identity and you present the 0.1 credential and then you say, To this address, please.
Stephan Livera:
Right. And that’s how I can kind of claim it from the coordinator even if I’m not a Wasabi 2.0 user myself—
Max Hillebrand:
No, no—in this case you have to be a Wasabi—or at least, you need to understand WabiSabi and talk to the same coordinator. It might happen in a different wallet if there’s a BIP and a standard. And I do the same with my change output. I still get 0.7 back. So I break that down to 0.4 and 0.3 or something, and I present those two coins to the coordinator.
Stephan Livera:
The same way, yeah.
Max Hillebrand:
But now the crazy thing is: I just paid you money, but you have no idea which input coin I used—I never sent that to you. It’s one of hundreds of inputs on the CoinJoin. So you have no idea about my past transaction history. And I, as a sender, have no idea about the addresses or amounts that you just had. So I don’t know your address and therefore not your future transaction history. So these are perfectly anonymous payments in the sense that neither the sender nor the receiver knows the pre- and post-mix transaction history. And the coordinator doesn’t even know that that’s going on. For him, it’s just a regular reissuance request. He doesn’t know that someone passed the token to someone else. And the best thing is it works similar to PayJoin, that the receiver can also consolidate anonymously. So you would, Stephan, just register an input or a couple inputs at the coordinator, then I register some inputs and I give you the amount credential of what I want to pay you, but you already have some credentials from the three coins that you registered or something, plus you get my credential, and now you can consolidate those credentials, basically, present two of them to the coordinator and turn them into one. And you do that twice or three times, and then you have one credential with all the amounts. And that ends up being put onto the Bitcoin blockchain. So it might even be—and I don’t know that you’re consolidating—so I have literally no idea neither of the address nor the amount that you are receiving on the other side.
Stephan Livera:
Yeah. Interesting to see. Okay, so what’s the timeline then for Wasabi 2.0 or WabiSabi?
Max Hillebrand:
Two weeks, of course. So I think four weeks ago we released the first Testnet release candidate—I mean, the code was open source, you could have run it on Mainnet since day one, but we would not encourage it yet. And we, ZKSnacks, do not run a coordinator on Mainnet yet. And so we only have a WabiSabi Testnet coordinator. And I think we’re the only one—or now actually some people are testing with the coordinator, too. So we’re probably not the only one in Testnet. And now a couple days ago we released a second version of our release candidate. By the way, in that meantime, I think it was only two weeks—something like 110 pull requests got merged. Like, that’s what you get when 30 developers are working on some code, and that’s what you get when you have a reputable long-term coordinator who earns a bunch of money. You can actually pay people to focus full-time on that. So we’re making some serious, serious improvements here. And yeah, that’s out, so go to the github.com/zksnacks/walletwasabi and scroll down: there’s a pre-release version 2.0. And try it out—it’s cool. It’s not just the CoinJoin under the hood having been improved tremendously, but it’s an entire new user interface. We have I think three of the maintainers of Avalonia—which is a UI framework—working full-time on Wasabi, and they are kind of considering Wasabi to be one of the flagship products of Avalonia, so they really put a lot of love into it and made it look quite beautiful. Even master branches are already more advanced than our second Testnet release candidates. So the UI is really, really pretty. Because Wasabi 2.0 is gonna be so much more block space-efficient and so much more cheaper for our users, we’re now just happy to do it by default. So whenever you send money into your Wasabi Wallet and it confirms, those coins will be registered and automatically—you don’t have to do anything—and it will just break down into smaller value coins that have some ambiguity. And Wasabi will also now keep running in the background. So by default, the GUI just minimizes, basically, but the daemon keeps running in the background—rather resource-light, hopefully, and then you can just opportunistically CoinJoin as long as you have your computer running. All of this together just makes it such a more simple UX. Now it’s literally: you receive money, you wait a couple hours, and then you spend money. You have no idea what happened in the meantime, but you can rest assured that your privacy’s protected, that the person who you’re sending money to now has no idea how much money you earned in the past or from whom. And this is I think really one of the things that led to a lot of user mistakes in 1.0, was that we offloaded a bunch of responsibility to the user in 1.0. It was all based on manual coin selection and manual CoinJoin registration. So by default, even though we have perfect privacy on TOR and on the network level with block filters, but by default, there was zero privacy on the Bitcoin blockchain in Wasabi 1.0. Because the user, first of all, had to understand that there was a problem. Sure, if you had a one anonset coin there was a red shield, but who cares? Nobody knows what that even means. And they need to know that there’s a solution to that problem, which is known as CoinJoin, but what the fuck is a CoinJoin? No idea. So few people knew that there was a problem, few people knew the solution to the problem, and fewer still knew how to use solution properly in the sense of not consolidating inputs and stuff. But we just offloaded a bunch of responsibility to the user who are, frankly, the least educated and the least able to make those decisions. I have no idea how to configure TOR properly—I just install the TOR browser and it works. But I don’t need to know the details of what our circuits and strings and bridges and whatnot—it just works by default. And I think we’ve achieved that on the blockchain now, that you actually don’t need to care about what are UTXOs, even—you just receive money and you spend it and that’s it. But because of the default CoinJoin, and because of some things like the change avoidance, pocket selection, and things like this, we can just abstract a lot of the complexities out of the wallet. And that’s another thing that’s quite controversial, because I’m a power user and I love to see all the details and be able to control my robot to its fullest extent, and Wasabi 2.0 is moving away from that direction. It doesn’t try to be the next Electrum or Sparrow—it really tries to be a wallet that everyone can use and everyone can use privately by default without doxxing all of your financial activity on the chain, and I think that’s quite an important goal. We’re still probably far away from it—like, 2.0 is quite shitty—it’s far from perfect on many levels, but I think it’s a major, major leap and improvement in Bitcoin privacy wallet design in general. So, as bad as it is, I’m still quite proud of it, of what we’ve actually achieved here, but I’m very certain that this is not the end. Like, there are a whole bunch more things that can and will be improved, so it’s definitely not gonna be boring.
Stephan Livera:
Okay. Well, I’ll have to have a look. I think it is one of those things where people are—yeah, I guess we’ll have to see what happens with that and see what happens in terms of chain surveillance or chain analysts in the community and privacy developers and privacy advocates, say, once they’ve had a chance to play around with it. So Max, thanks for joining me today and we’ll catch up some other time. And Max, where can people find you online?
Max Hillebrand:
Yeah, thanks Stephan for the invite. I think it’s really good that we talked. And again, I don’t think we disagree on much here. I just wanna highlight: there’s a bunch of nuance here, and ultimately that’s why we have the free market. I think this is a win, win, win—we’re gonna be for everyone. More services offered like this are a good thing. And ultimately, also, financial incentives are key, and if you’re gonna pay a hundred or a thousand times more in fees with other solutions, that’s gonna be noticeable. So I’m super stoked that we improved efficiency of on-chain CoinJoins by such an extent—and the usability of them, too. So yeah, I’m bullish on Bitcoin privacy more than I ever was before, even though I’m not that happy with that decision ZKSnacks took. But yes, find me on Twitter at @HillebrandMax and towardsliberty.com, my site for personal consultations and all other things. It was a pleasure speaking with you, Stephan. Let’s keep in touch.
Stephan Livera:
Thanks, Max. Bye.