There are three so-called privacy guarantees of Wasabi 2.0. One is that the more inputs there are, there is the likelihood that there’s gonna be multiple equal denominations. It gets higher and higher, and like Max said, when it gets to 150 inputs or 300 or something like that, it’s gonna be very, very likely, that there’s gonna be multiple equal amounts for all of the denominations. Now that is good. That provides us anon set. That is one privacy guarantee. Now, there’s also the fact that now in Wasabi, you cannot really know how many inputs this user has, how many outputs did he break the amount into. And you know, all of these kinds of nuances, it makes it really, really difficult to try to analyze Wasabi coinjoin transactions because there’s kind of this possibility of you breaking down your amounts in many different ways, so you don’t really know it. It’s kind of another way of making it difficult for any analyzer to figure out what really happened over here.

Now the third one, which is not really a guarantee, you know, it’s just a practical thing that we’ve noticed that it is very difficult to try to even create a probability table for a coinjoin transaction as large as Wasabi 2.0 coinjoin. If you have 300 inputs and 300 outputs, just trying to calculate some kind of a, you know, doing coinjoin Sudoku and trying to figure out which inputs could have gone or broken down into which outputs or consolidate into, you know, all of the possibilities.

That is just something that we have not with our hardware been able to even do.

Well K Y C P doesn’t either on large transactions, they just go “run it yourself” because it’s so computationally expensive.

Yep. So even if you have these amounts, as long as you are not the big whale and a lonely whale in Wasabi 2.0, coinjoin transaction, it is gonna be very crazy hard to figure out the input-input linkage, input-output linkage or output- output linkage.

Now in the Wasabi Wallet 2.0 coinjoins, there is a bunch of these so-called privacy guarantees. So we have the traditional anon set, but we have much more things on top of it.

I think when we want to focus on change in coinjoins, it’s important to look at the entire user journey and Rafe you just hinted it in some regards.What about post links? So the entire user journey is arbitrary amount input value. Maybe that’s not gonna be enough as the minimum denomination that the coordinator dictates in Whirlpool or Wasabi 1.0, for example. So then you have a problem and you’re excluded. And so you have to consolidate multiple input coins in the same joint transaction or TX zero transaction, which reveals common input ownership, at least to the coordinator with Wasabi 1.0 and to the entire blockchain with TX zero in Whirlpool, which isn’t great, right? But you’re now in the coinjoin. You get your private output amount of a standard denomination, but now you want to make a payment. And the big problem is, well, the payment, the merchant wants an arbitrary amount, and it’s very likely not that standard denomination that you have.

So you have to consolidate multiple inputs to make a payment. Also, you are gonna have to create a change output because the merchant’s payment output is, is not the value of your inputs. Then if the coordinator dictates certain input and output values in the coinjoin, this means that you cannot do the payment inside the coinjoin. Like for example, in Wasabi 1.0, no merchant wants to get exactly 0.1123, or something. In Whirlpool you couldn’t even collect multiple inputs, the coordinator says you can only have one input, and no merchant wants to get the exact pool denomination. So this means in Wasabi 1.0 and in Samourai, you would have to make single-user payment transactions, but single-user transactions are horrible because we reveal common input ownership. And so now if you need to consolidate multiple standard denomination coinjoin outputs in your single-user payment transaction, you just revealed common input ownership.

Then you have the merchant’s payment output and your change output. Well, now the merchant knows that this is your change output and an outside observer knows that this is the change output to a payment that was done by a coinjoin user, and then you will most likely want to get privacy back on that change output, right? It’s toxic after all. So you want to put it into a coinjoin. The problem is, The problem is, you just commissioned a payment with a standard denomination. So the change output is gonna be less than that, meaning you cannot go back into the same denomination coinjoin pool, right? Let’s say in Wasabi 1.0 you get a 0.1 output, you make a 0.03 payment and you get your 0.07 change. Well, the 0.07 change cannot be registered in the 0.1 pool, meaning you have to consolidate to get into the coinjoin again, and that sucks for privacy. The change output is such a huge problem, not just inside coinjoin, but also inside payments, which cannot be made inside the coinjoin, but because of the entire idea of trying to prevent change. But here is where Wasabi 2.0 really comes in to shine.

It just shows the incredible benefit of having arbitrary amount coinjoins. You can come in with any amount that you just put through from an exchange or whatnot and get only private outputs on the output side, and now you have a multitude of different standard denominations in your wallet after a couple rounds of coinjoin. And now if you want to make a single-user payment transaction, you can combine these standard denominations very efficiently to reach any arbitrary payment output value with only a handful of inputs.

These standard denominations are good for decomposing, like breaking down a certain large amount into many smaller amounts, but they’re equally as efficient in taking a bunch of small amounts and adding them up to a precise large amount. So with very few inputs, you can make any value payment, but still, let’s assume that you still get a change output back. Well, the change output is gonna be lower than the standard denomination on your input side. But in 2.0 it doesn’t matter because you can register as low as 5,000 satoshis on the input side, regardless of what amount it is. So a payment change output can directly be registered in the coinjoin and it can be registered together with private outputs that you have. So you can combine one or two non-private change outputs together with three or four private coinjoin outputs, which means now even though one or two coins of yours are revealed on the input side, all of your other coins that you have on the input side are private. And so, even an outside observer who might know that this specific change coin belongs to you,  does not know which other inputs you have and therefore the value of the inputs that you have. And if you don’t know the value of the inputs that you have, it’s gonna be even more difficult to find out which output values do you actually have.

Ultimately with 2.0, we have a much smoother user experience that is faster and especially cheaper and more private.You can get any arbitrary input value, and even after making a payment, you can register the change without any issue in the next coinjoin.

Just to kind of explain a little bit of what is anon score.

Imagine that you have a coinjoin round where you have one of the outputs of one Bitcoin and there are nine other outputs that are also one Bitcoin. Normally we would consider that this, your coin has anon set of 10. The thing is, we could previously say that with all of the three old implementations, because we had this idea that the user will have only one of those equal denomination outputs. That was the guarantee that enabled all of these implementations to somewhat of at least use anon set as an estimation of how private did their output get. There is nine other outputs that are equal amount, and each of the outputs are owned by different people. Now with 2.0, that is not true anymore.

So there can be that you might have, let’s say two of those, one Bitcoin outputs instead of just one. What would be then your anon set? Well, it is again, for each of the outputs that we have, like this one bitcoin output, the anon set is 10. But because we cannot know, if all of the other eight outputs are also coming from different people, we have to be conservative.

So there is certain calculation of how anon score is a conservative version of anon set. Instead of you having one of those one Bitcoin outputs, we don’t give an anon set of 10. We give, let’s say, as an example, an anon score of 4. Because we assume that multiple of these outputs might be actually from the same user, not all from different individuals.

That is kind of like anon score. So whenever, like we have in the wallet now ‘Anon Score Targets’, when the user starts a wallet, he has to choose from different profiles. And those profiles have a certain amount of Anon score that they are targeting. And automatically, whenever the conjoin rounds succeed in a way that they actually do get this traditional anon set, we make a conservative calculation from that and then we show it for the user that, hey, you got privacy. So we are not even calculating or counting into our privacy calculation the fact that it’s computationally just hard to figure out all the possibilities of how the linkages could go in this coinjoin. We are not counting on this being able to break down the amounts into multiple different ways.

We are being ultimately very, very conservative. Even more conservative with the anon set in the calculation of privacy.

Check out the full recording, if you haven’t already: https://youtu.be/Zu-bT9XojYk

The post Twitter Spaces Highlights – Toxic Change in CoinJoins appeared first on Wasabi Wallet - Blog.

Read the podcast highlights below.

On Working on Wasabi 1.0 with Nopara73 and L.Ontivero in Lisbon.

After Dan started working on Avalonia, his journey with Wasabi Wallet began. In 2018, He was contacted by Nopara73 with an interesting proposition of shortening his vacation time to work on Wasabi Wallet in Lisbon Portugal, a mere few weeks before Nopara73’s presentation at the 2018 Building in Bitcoin conference.

“I met up with Adam, Lucas as well, and I was pretty impressed. And I was like, oh, these guys have flown from the other side of the world to meet me, to find out about Avalonia. And this was kind of like the first time I’ve met anybody, in person, from the sort of Avalonia community or anybody that was building anything with Avalonia. So for me, it was like a pretty exciting adventure and on his own.

So now it’s more than just some people that you just type in a box to, you know, these are actual personalities that you get to know. And, that was, that was really nice. So, Adam sort of tried to explain the concept of what he was doing and what it was. And obviously for somebody that is new to Bitcoin, obviously it was a lot to take in, didn’t fully understand it at first. But, I could see that as you say, he basically built a lot of the code, so he’d done all the engineering and the research to actually implement all of this stuff and it was basically missing the UI.

Basically, we were in a small flat, and me and Lucas would sit around the kitchen table and Adam told us his ideas about how the UX might work and we just went at it like one piece at a time and it was pretty intense. We were working really fast to put stuff together. I think it might’ve been three weeks from nothing until we had something that was at least demonstrable and functional.

If Adam hadn’t already done all the work that he’d done three weeks would have been impossible, so a lot of the stuff had already been done and that was mainly purely building the UI and yeah, and it was really good because obviously, I had so many questions about, Bitcoin, you know, I just had to be like a sponge learning everything. And we would sort of go for these long lunches, me and Lucas and Lucas would tell me absolutely everything that he knows. And I was asking him probably the same question anybody that’s new is asking, you know, over and over again. And he was really patient and explained everything in detail. And, and that was really cool for me.”

On Deciding to Change Wasabi’s UI

Though Wasabi’s initial design was based on Nopara73’s vision of a privacy-focused bitcoin wallet and had a targeted audience of Bitcoin’s early adopters and technical users who understood the principles of bitcoin and Coinjoining, the UI has served its purpose and it’s now time for an upgrade – Wasabi Wallet 2.0, which according to Dan, is completely different and a lot more refined.

The fundamental issue is that we’ve ended up with some slightly redundant UT  concepts in there that are technically now needed and after a while people got used to it and people started talking about our features and things that we could do with Wasabi. It started getting to the point where Okay, maybe we’ve gone a far as we can with the current UI  and as well it is important to remember that in the beginning there were not many users for Wasabi and I guess it was kind of an experiment – I don’t think anybody could’ve imagined that it was gonna get to where it is today. You know, maybe Adam did, but I didn’t imagine. I quickly realized that it probably was going to be once I started to understand.

The current UI that has served a very important purpose, which is it got us up and running very quickly, it’s become stable reasonably quickly, and lots of people are using it, but now it’s got to the point where, okay, we’re now this successful wallet, and we’re able to provide all these features. Would we have done the UI the same now if we’d known this was the position where we’re going to be a few years ago? And, in my opinion, we would have had similar concepts, but the UI would probably be quite different, which is why we’ve started work on Wasabi Wallet 2.0 and the great thing is now we’ve got lots of resources. So we’ve got UI designers, UX designers, a whole team just for the UX and implementing that. And that’s the direction we’re going in now.

“Now we start from a design. We will spend a lot of time on the design refining how the UI is gonna look, how it’s gonna be laid out, how the user is going to interact with what the user experience is around a certain feature or of the product. So there’s a lot more time available and we’re not rushing to get to the next conference in a few weeks. We’ve got months to spend on it. “

Wasabi’s UI will not be the only noticeable feature change with the upcoming Wasabi 2.0  release. Read our previous blogpost to see what’s coming and listen to the full episode below to hear more about Dan’s work.

Listen to other full episodes on all podcast platforms. Don’t forget to like, subscribe to and follow official Wasabi Wallet channels for more interesting and insightful topics on Bitcoin.

The post Podcast Review: Designing a Privacy-Focused Bitcoin Wallet UX appeared first on Wasabi Wallet - Blog.

The conversation focused on developing the next generation of a more privacy-focused Lightning network with Istvan Seres, a researcher based in Budapest working on Wasabi as well as completing very groundbreaking research and education in the privacy aspects of the Bitcoin Lightning Network.

Here are a few things we learned from this podcast :

What is the Lightning Network

“Lightning is the one and only scalable solution for Bitcoin, which is non-custodial. So this is a super important property. So we want to scale Bitcoin in a non-custodial way, but also even maybe even more importantly at the end of the day, we want to preserve privacy. So, lightning is a layer on top of Bitcoin, which presumably provides both of these properties. So scalability and privacy and security.” ~ István Seres

Types of transactions on the bitcoin blockchain

“Lightning is a layer on top of Bitcoin. So, whenever we talk about privacy, obviously we need to see these two layers simultaneously because it just doesn’t make sense. I mean, an adversary will be present on both layers, for sure. So, you can think of your favorite three-letter agency: KGB, NSA, whatever.

So, obviously lightning requires two on-chain transactions. First, you need to open a payment channel with your peer or peers. That’s an opening channel transaction that happens on-chain. It has an on-chain footprint that costs an on chain transaction.

Once the payment channel is open, then you can send transactions back and forth between you and your peer. If this channel is depleted or your  business relationship is over, then you can say, “Okay, I had enough ice cream, I had enough pizza, I want to close this payment channel.

Also this channel closing transaction goes to the Bitcoin main net. You can have as many transactions as you want, but still, two transactions will be visible on the Bitcoin main net. But even so, whenever we talk about privacy,  I cannot stress enough that we need to consider an adversary that is present on both layers. The adversary will surely do some transaction graph analysis in the first place to assess and  see where the channel was opened and closed, as well as how it was closed. And then, the adversary is surely present also on lightning. That’s the reason why this argumentation is completely flawed, that we move off-chain so the transactions are not visible on the public ledger, on the blockchain, thus we are fine.

This is not the case because this is a permissionless financial network. Obviously, anyone can just fire up a lightning node and just listen to what’s going on, and record everything that they hear on the gossip layer, on the public channel layer. “~ István Seres

Potential attackers we should defend against

“In the on-chain case, usually we consider an ‘adversary’ who has access to the distributed ledger, to the blockchain, so obviously sees every transaction, in addition, in a more evolved case, we also assume that the adversary can hear what’s going on on the network layer. Thus, you can imagine that it’s already pretty devastating if the adversary can link, if you don’t use. For example, Tor,  then they can link your IP address with the Bitcoin transaction you just broadcasted.

This is the on-chain adversarial model so, the adversary hears everything on the network layer and also sees the public ledger. In the lightning case, we assume that the adversary is inside the network. Meaning, the adversary who wants to deanonymize us has many open payment channels with many other nodes in the network. It’s well embedded into the lightning graph and has many payment channels open with many other peers. Most likely whenever you want to route a payment, so Alice wants to route a payment to Bob then they will route it through Cecil, Dave, Eve, Frederic and so on. We can assume that some of these intermediaries are controlled by the adversary so the adversary will log that I needed to route some payments here and there.

That’s the model. Lightning Network if we think of an adversary then we think that the adversary has many open payment channels with other peers and they log every public information. The most important is that the adversary can have open payment channels with lots of nodes and has a lot of capacity.” ~István Seres

The goal of the Lightning Network

“One of the papers which recently came out and was presented in the Financial Cryptography Conference 2021 one or two weeks ago. It’s work by George Kappos, Ania Piotrowska and others  from UCL and Cornell and they identify basically four main privacy guarantees we want to achieve in the lightning network. First obviously, if you have a private channel, then in lightning, you can have public channels and private channels. So to exemplify, if Alice and Bob open a public channel, then it’s fine because all the networks can use this channel for routing payments. But if they decide not to disclose the details of this payment channel, then this is classified as a private channel and then no one else should be able to use this payment channel for routing unless they know the existence of this private payment channel. Some people say that approximately even 30% of the channels on the lightning network currently are private channels.

Therefore, the first privacy guarantee we want is that, if we have a private channel between Alice and Bob, then Alison, Bob wants this private channel to be secret. So, not even the existence of this private channel should be known to anyone.

The second privacy guarantee we want is third party balance secrecy.
In the lightning network, each payment channel’s capacity is public knowledge. Hence, we cannot hide that. If there’s a payment channel between Alice and Bob, then the capacity of it is known. The capacity of the payment channel is basically the sum of the individual balances of Alice and Bob, of the two parties corresponding to the payment channel and obviously, this information is known to Alice and Bob. But this privacy requirement dictates or this is at least our desire, that we want the individual balances themselves to be hidden. In short, Alice and Bob know their individual balances in the payment channel, but we want this information to be hidden from other parties.

The third Privacy property we achieve on the lightning network is on path relationship anonymity. Suppose Alice sends some payment to Bob and they route this payment through many intermediary nodes like Carol, Dave, Eve, Fred, whatever. What we want is, for example, if we just pick a random intermediary, Dave, then Dave should not be able to tell who is the sender and the receiver of this payment, right? That would be pretty devastating. With that, Dave should not be able to tell whether Carol is the sender of this transaction or Alice or one of Carol’s neighbors and similarly, also Dave should not be able to tell whether Eve is the recipient of the payment or Bob.

Lightning uses onion routing. Every routing node only knows the predecessor and the subsequent nodes where they need to route the payment to. Obviously if there’s one hop then we cannot really do anything because then it’s already obvious who is the sender and that receiver. But also the length of the payment path is unknown to intermediaries. Even if the payment has just one hop the payment router cannot know whether the payment has one or two or three hops, whether he or she the only routing. This is on, on path relationship anonymity.

And the fourth and the last one, according to this paper, is off-path payment privacy. For instance, let’s say I am an observer. I have many payment channels to my friends, and I should not be able to tell what’s going on along payments that do not involve me as an intermediary. If Alice sends a payment to Bob okay, there are some intermediaries, Carol, Dave and all, all these nice guys. But still, I should not be able to tell how much money went through along those payment routes, or even just the existence that the payment occurred along some routes. Again, these are the four privacy guarantees according to this paper so hiding private channels, second, third party balance secrecy, third anonymity, fourth payments, privacy.”~István Seres

Of course, the guys delved deeper into this topic and discussed each of these aspects in tandem, but you’d have to listen to the entire podcast to learn more about the lightning network. Don’t just take my word for it.

Listen to the full episode here:

The post Podcast Review: The Privacy Guarantees of the Lightning Network appeared first on Wasabi Wallet - Blog.

Max Hillebrand was recently featured on ‘What Bitcoin Did‘ with Peter McCormack. It’s an honor to be invited on one of (if not) the biggest Bitcoin podcasts. Not only do they discuss the general idea of Bitcoin privacy, but they also debate whether or not everyone needs financial sovereignty and the reasons to distrust 3rd party vendors.

Max also describes how he has completely converted to a Bitcoin only lifestyle and the realities of doing so. Although many of us have dreamed of cutting ties and living a life that is unbound by governments, borders or any of these controlling institutions, very few of us have the courage to truly take the plunge. Listen to find out how this hardcore Bitcoiner has put his money where his mouth is.

“For me, the guiding principle is to reduce the number of seconds that I hold fiat shitcoins.” ~ Max Hillebrand

The post Interview with Max Hillebrand on ‘What Bitcoin Did’ appeared first on Wasabi Wallet - Blog.