The Wasabi Wallet team’s timeline as well as explanations given to address the issue are detailed in this post.

The problem has been resolved, and the system servers are back online.

What happened?

Wasabi Wallet team received an alert email from the hosting server on June 6th, 2021, or approximately 16 UTC, informing us that we were experiencing a massive DDoS attack and that, for security reasons, traffic will be analysed to assess the extent of the attack.

In a Distributed Denial of Service attack, the incoming traffic flooding the victim originates from many different sources (like a botnet). This effectively makes it impossible to stop the attack simply by blocking a single source or IP.

Timeline (UTC)

• About 16:00:00 – DDoS attack started
• 16:02:17 – We received a message from our server host regarding Denial of Service Notification
• About 16:04:00 – Due to the size and scale of the DDoS, network connectivity of the server was automatically and temporarily suspended for 3 hours in an effort to mitigate the attack
• 16:05:31 – Received a “Connection timeout” alert about a period of downtime from Uptime Robot
• 16:08:26 – Wasabi team detects DDoS attack and starts communication in a private channel
• 16:13:13 – Server shutdown
• 17:23:28 – Wasabi team started an Emergency meeting
• 19:03:18 – Server goes back online after 3 hours as scheduled – Wasabi Wallet team starts to implement security measures to mitigate the DDoS and cut off the attacker
• 19:04:02 – Received alert about partial restoration of services from Uptime Robot
• Between 19:04:02 and 20:45:38 – Wasabi Wallet team heroically defends the server by implementing security measures while still being attacked by the botnets of zombie computers
• 20:46:03 – The security measures seemed to stop the attack, but later investigation found no causal relationship between the attack stopping and the hotfixes

Some data about the DDoS attack:

Attack intensity: several million packets per second (Mpps)
Bandwidth involved: several Gigabits per second (Gbps)
Total downtime: 4 hours and 42 minutes

Conclusion

Wasabi Wallet is a well known non-custodial wallet. This means that the users are always in control of their private keys and thus, their funds. When running Wasabi for the first time, the user is given a piece of information called a “seed” and is instructed to write it down to recover their funds in case of an emergency. Also, the user can always export single private keys belonging to single addresses to recover specific UTXOs (Unspent Transaction Outputs). Users always have complete control over their funds through their private keys.

Hence, Wasabi Wallet users’ funds were always safe throughout the entire attack,. The downtime only affected Wasabi Wallet backend services like:

• wasabiwallet.io website
• CoinJoin feature
• BIP-158 Block Filters sync
• Fee estimation
• In-software USD dollar exchange rate

DDoS attacks are a serious thing and it’s really difficult to fully defend against this type of attack.
Satoshi Nakamoto left the Bitcoin community ten years ago on December 12, 2010, with his final message about adding some DoS (Denial of Service) features saying that “there’s more work to do on DoS”.

Cyber attacks are an inevitability. They will always exist and sadly, no one has the ability to halt or control them. There is still a lot of work to be done to continue maintaining the security of Wasabi Wallet. Wasabi Wallet makes it a top priority to protect users from similar threats and thus, Wasabi Wallet’s team is constantly working to provide the highest level of security and privacy.

The post WVE–006 DDoS Attack Report appeared first on Wasabi Wallet - Blog.

On May 22, 2010, Bitcoin was used for the first documented real-world transaction. The day now referred to as “Pizza Day” has become a milestone in Bitcoin’s history, not only because of the significance of such a breakthrough for Bitcoin’s use as a medium of exchange, but also because of the transaction’s current value. The man behind the famous transaction spent 10,000 bitcoin for two pizzas and a coke, which is now worth millions of dollars.

Hundreds, if not thousands, of publications have been written about the price and how much the two pizzas are worth today. But how many articles address the privacy concerns that this transaction raises?

Satoshi Nakamoto said in a Bitcointalk thread:

“The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you’re associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven’t associated with your real identity, then you’re still pseudonymous. For greater privacy, it’s best to use bitcoin addresses only once.”

With This quote in mind, let’s take a look at the historic pizza day transaction that kicked off Bitcoin’s decade-long meteoric rise, and all the privacy concerns that were compromised on that day.

A Bitcointalk user and his pseudonym

On May 18, 2010, a user under the pseudonym “Lászlo ” started a “Pizza for Bitcoins?” message asking for “a couple of pizzas.” In this message, Lászlo shared his Bitcoin address as well as the physical address where the pizzas should be sent in a text.

“I didn’t know much about privacy and how it worked back then and I didn’t really think it was important to worry about it since it wasn’t a very big deal that time.”
~ Lászlo

On May 22nd, 2010, Lászlo sent another message, confirming that the 10,000 Bitcoin transaction had been completed and that he had received the two pizzas. Shortly after that, he posted a URL to a website with pictures of the pizzas.

How much sensitive public data has been given up to this point? There are four infractions to work with when it comes to tracking the consumer as well as the transaction Lászlo was involved in, and we will discuss these below.

The compromised identity of a forum user

Assume there is an entity that wants to track a single person. The first thing they would check is if this individual has shared any personal information on the platform. Trackers and hackers can see if the user has posted any addresses that are entirely their own. The first thing they will do is check whether the user has posted some identifying information on the website (in Laszlo’s case, it was that forum where history was made).

Is this even possible? How are they able to do this?

Yes, this is possible and sometimes, too easy. That is why we, Wasabi Wallet, work hard to raise awareness about the value of privacy and are invested in educating people about making smarter decisions about their privacy.

But what exactly was the issue in Lászlo’s pizza case? Why should users think about improving their privacy?

Well, the explanation is simple. He shared his bitcoin and physical address, the amount of Bitcoin used in the infamous transaction as well as photos of the pizza, after their successful delivery.

Users should never post their bitcoin address on the internet and they should never link it to their physical address. Obviously, no one could have predicted Bitcoin’s huge increase at that time, thus Lászlo could have ignored it as well.

His address has been used in many transactions in the future, and it helped allow the trackers to monitor not only the exact transaction, but also previous and future ones. As a consequence and with an unassuming step, Lászlo’s past, present and future transactions became as visible as an open book.

Trackers could quickly search for transactions involving the same amount around the time period because the blockchain is a transparent and immutable ledger. They could also find that the associated transaction relates to the amounts as well as any other information or addresses that were visible at first after a simple check in this open ledger.

Is it okay to reuse Bitcoin addresses?

The answer is: NO! DO NOT USE THE SAME BITCOIN ADDRESS!

But why? The point is straightforward: if an address is used several times, the same private key will be able to spend all of the coins. It is then very easy to locate all of the UTXOs (Unspent Transaction Outputs) associated with this particular address, and therefore to determine how many bitcoins the private key currently holds or previously held.

What about a Transaction of Change? Is that a good Idea?

The answer is: NO! IT IS NOT A GOOD IDEA!

Lászlo’s pizza transaction raises another privacy issue: by making a change output connected with the same input, trackers can keep records of more and more purchases by the user. It implies that the source of funds from a particular address can be monitored permanently. The detectors have not only discovered how much Bitcoin an individual has, but they can also monitor all of his future Bitcoin transactions.

Should round numbers be used in Bitcoin transactions?

The answer: DO NOT USE ROUND NUMBERS WHEN MAKING TRANSACTIONS!

When sending bitcoins, the destination address is typically given a round number. This is because the human brain follows trends which, for the most part, likes to think in terms of defined numbers since a number like “10,000” is far easier for our brains to grasp than “10,021.92583769.” This helps clarify that the non-round number output is the return to the sender.

Referring to Lászlo’s case, both of the outputs in the previously discussed Bitcoin Pizza transaction were round numbers.

Should a person’s address ever be made available to the public on the internet?

As if you haven’t been paying attention. The answer is: NO!

We’ve shown how multiple cyber attacks in recent decades have stripped away the feeling of security that any human being deserves, and we’re not only referring to Bitcoin-related privacy violations. Our recommendations and the backstory justifying them applies to every service or product that people purchase or use on the internet.

Cyber attacks occur at a rate of over 530 per second. Everybody will be a victim of a hack or data theft at some point in the future, and it should not be a Bitcoin related issue. Everyone uses the internet, banks, social media….etc. Attackers can easily access everything connected to the Internet. What is posted on the internet is open to watchful eyes.

So how can people feel secure in the holiest place of all, our home, if it is shared with the rest of the world?

What about sharing your geographic location?

The answer: Is this for real? If you value your privacy, DO NOT share your geographic location.

Also, when you send a Bitcoin transaction, you’re basically sending a message from your device to the Bitcoin network. Someone running a large number of Bitcoin nodes could be able to match some of your transactions to your IP address, monitoring your bitcoin balance and exact location.

On a desktop, this can be avoided reasonably easily by filtering all transactions through Tor – a free worldwide volunteer overlay network with thousands of relay nodes that protects a user’s location and also from anyone undertaking network surveillance or traffic analysis.

“Things have changed dramatically since Bitcoin is very valuable nowadays. Privacy is more important now than ever before.”  ~ Lászlo

What is the solution to all of these concerns?

First and foremost, be conscious of what you post online. If you’re openly sharing personal information or details, even the best and strongest technologies can only do so much to protect your data and rights. Second, there’s CoinJoin by Wasabi Wallet, the open-source non-custodial, privacy-focused Bitcoin wallet for Desktop, that implements trustless CoinJoin. It has Tor built in and all data seen between customer and server goes through it by default, so IP addresses are shielded and hidden; furthermore, the users’ privacy is protected.

By conjoining your bitcoin it is significantly more difficult for others to track your transactions on the blockchain. CoinJoin is an excellent service which combines multiple coins in a single, big transaction. This protects your money and gives you privacy. It maximizes the security and the privacy of your future by maintaining the transparency of the Bitcoin ecosystem.

Wasabi also provides all of the usual security features, such as Hierarchical Deterministic wallets as well as address reuse prevention, moreover, coin control and labeling specifications. The wallet has a one-click partial full node integration and uses BIP-158 Client-side block filtering to access its own transaction history in a private manner. If a user already has a Bitcoin full node on a local or remote device, the IP address and port, or the Tor onion service, can be defined, and Wasabi will use it to verify and apply Bitcoin rules.

“Wasabi Wallet is my favorite non full node Bitcoin wallet. It uses modern methods to filter transactions and has a privacy first design. The built in CoinJoin functionality is probably the most interesting part. But even for users who are not interested in this feature it is a great wallet that encourages labeling the user’s coins and being aware of what inputs the user is spending.” ~ Lászlo

It also includes specialized cutting-edge features such as:

• Opt-in PayJoin
• Dust attack protections
• Custom change address
• Anti wallet fingerprinting
• Wasabi also has a complete and detailed documentation containing explanations on the architecture of the program,on its functionality and tutorials on how to use it.

The Wasabi Team is also working on Wasabi Wallet 2.0, a combination of user interface (UI), user experience (UX) and coinjoin (CJ) improvements.

On the CoinJoin front, the long awaited WabiSabi will also make its debut. It will facilitate faster, more cost-efficient collaborative transactions without waste, lay the foundation for payments within CoinJoin and open the door for combinations with other technologies.

All in all, even though no one will pay 10,000 BTC for two pizzas today, the privacy issue is a big concern that everybody should consider in the future.

One last piece of advice to help you keep your data private at all times: check the privacy settings on every platform that you use on a regular basis. Or if you ever want to make your Bitcoin more private, check out Wasabi Wallet and put it to use.

What sets us apart from other wallets? Why is Wasabi Wallet so important for privacy?

Because Wasabi Wallet safeguards YOU, your loved ones, and your associates. Because Wasabi Wallet will help you protect your Bitcoin.

What is the point of this, exactly?

The answer is that Wasabi Wallet is determined to reclaim your privacy.

No data. Just privacy.

Recommended reading on Bitcoin privacy:

• https://docs.wasabiwallet.io/
• https://en.bitcoin.it/Privacy
• https://www.lopp.net/bitcoin-information/privacy.html

The post Pizza for Bitcoin? appeared first on Wasabi Wallet - Blog.

It’s a word play, originating from the Block Digest podcast, on the zkSNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) and zkSTARKs (Zero-Knowledge Succinct Transparent Argument of Knowledge) cryptographic concepts. But it goes beyond that. Zero Knowledge Snacks implies that the Snacks should not know anything about their consumers. Anyone should consume these snacks without the snacks knowing who they are being consumed by. The snacks are the product, like Wasabi Bitcoin Wallet and the consumers are its users. The wallet provider should not be able to take the funds of its users and figure out who their users are. This isn’t ensured by the wallet provider choosing to not collect information, this is ensured on the architectural level. The wallet provider cannot collect information even if it wanted to.

~ Adam Ficsor (Co-founder of zkSNACKs)

Imagine eating a bag of chips. Obviously, you know a lot about the bag of chips. Information is forced onto its container providing nutritional information, its ingredients, packaging or expiration date…even the distributer is often listed and where they’re operating from.

But should that bag of chips glean information about you? Should these chips record and then send when and where you purchased them, what else you purchased, how long it was stored before being opened, when you finally opened the bag, how long it took you to finish eating the chips and finally, whether or not you littered the bag after consumption?

In this grotesque hyperbole, it’s easy to get bothered by the notion that a bag of chips collects your personal information. And this information isn’t even all that invasive. Imagine if toilet paper tubes or condom wrappers were operating like the aforementioned paradigm?

It’s unfortunate but this level of data collection, sharing, processing and then use/misuse is already happening on a staggering scale. Is it regulated, not really. Should it be? Not a question for us to answer, if even answerable. But this is why zkSNACKs was founded on strict principles. We adamantly believe that using our products shouldn’t be different than eating a bag of chips…today.

We do not store any personally identifiable information. Moreover, Wasabi’s trustless architecture prevents the CoinJoin coordinator from gathering this information in the first place. Zero-knowledge.

How does Wasabi Wallet Achieve Zero Knowledge?

“Personally identifiable information” is any information that can be directly associated with a specific person and can be used to identify that person. When it comes to financial information (like Bitcoin), protecting privacy is even more important. An example of identifiable information is a person’s name.

That’s why:

• We do not store any personally identifiable information
• We do not track users on our website
• We provide a .onion service
• All Wasabi traffic is routed in Tor

Here’s what you must do to maintain your privacy:

The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you’re associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven’t associated with your real identity, then you’re still pseudonymous. For greater privacy, it’s best to use bitcoin addresses only once.

– Satoshi Nakamoto in How anonymous are bitcoins? – Bitcointalk

Network Privacy

Wasabi Wallet includes built-in Tor and, by default, all traffic between the clients and the server goes through it, so IP addresses are hidden and user privacy is respected. Under normal conditions, Wasabi Wallet never leaves the Tor Onion Network and it never uses Tor exit relays, significantly decreasing the network attack surface.

How Tor Works Within Wasabi

Using Tor within Wasabi has several facets:

• Wasabi frequently utilizes multiple Tor streams where applicable and registration of CoinJoin inputs and outputs is done through different Tor streams to avoid linking.
• The backend server serves block filters to all the clients over Tor. From those filters, the clients figure out which blocks they are interested in and downloads them [and some false positive blocks] from random peers. One block per peer, and always over a fresh Tor stream.
• Wasabi connects to each peer through a different Tor stream. A new random Bitcoin peer is used for every transaction broadcast.
• Wasabi broadcasts transactions to only one peer over Tor, and immediately after that, the peer is disconnected.
• Every fee query happens over Tor with a new Tor identity.

There’s a lot that goes into maintaining this level of privacy for our users. In fact, it’s a balancing act to maintain transparency in what we’re doing while also keeping to our zero knowledge principals. There are so many incentives to collect information on our users, but all of them are off the table. We will not compromise on this promise to our customers and although we realize that creating a company that operates under the zero-knowledge paradigm is rare, as you can see, it’s built into who we are; hell, it’s even in our name.

The post zk Stands for Zero Knowledge appeared first on Wasabi Wallet - Blog.

Usually, a Bitcoin node broadcasts not just the transactions of its user, but it also gossips all of the other transactions that it has received from its peers. Thus it is very difficult to find out which transactions originated from which node.

However, when a node does not gossip all transactions, but only the transactions of its user, like in the case of a light wallet, then it is easier to find out which node has sent those specific transactions.

Bitcoin Full Nodes

When you run your own full node, you can precisely verify if the bitcoin you receive are actually valid. When you do not verify this for yourself, then you need to ask another trusted third party how much money you have.
Regardless how you ask this other server, there is now more metadata available to potentially link your coins to your identity.

There are bad ways to communicate, like querying a block explorer over clearnet, and good ways to communicate, like using BIP 158 block filters over Tor. But regardless, running your own full node means that you don’t need to communicate with anyone about your specific coins and this is strictly better.

Bitcoin Transactions

When you make a Bitcoin transaction, you are essentially creating a message on your device and sending it to the Bitcoin network. Someone operating a large number of nodes on the Bitcoin network might be able to match some of your transactions to your IP address, then deanonymize your stack of bitcoin.

It is relatively easy to avoid this on a computer by relaying all transactions through the Tor network. Wasabi routes all traffic via Tor’s SOCKS5 proxy, by default. This means that by default, all network communication is secured from outside snooping and the IP address is hidden.

Wasabi and Tor

Even if no full node is installed, Wasabi has a light client mode based on BIP 158 block filters. The Wasabi coordinator’s v3 onion service sends a filter of all the transactions in each block to all the users over Tor. Then, users check locally if the block contains any transactions with their addresses. If not, then the filter is stored for later reference, and no block is downloaded.

However, if there is a user transaction in that block, then Wasabi connects to a random Bitcoin P2P node over Tor and asks for this entire block, not just one transaction. This block request is indistinguishable from the regular P2P gossip, and thus nobody, neither the server nor the full node, knows which addresses belong to the user.

All Wasabi traffic is tunneled through Tor. Wasabi connects only to onion nodes, so end-to-end encryption is enforced between the wallet and peers. All this without involving any exit node. Wasabi connects to each peer through a different Tor stream. A new Bitcoin peer is chosen for every transaction broadcast.

Tor Consensus Issues

On January 10, 2021, due to an implementation bug, Tor’s v3 onion services experienced instability. A bug fix is already on the way, but until the update you may experience connection problems and delays.

Normal Tor circuits (using exit relays) still work, and v2 onion services still work, but v3 onion services (like the one used for the Wasabi coordinator) are affected and may not publish descriptors, and clients won’t fetch them.

Fallback Scenario

As we said before, all Internet traffic goes through Tor, and by default all this traffic stays inside the onion network. This means that, in Wasabi coordinator’s case, as v3 services are used to coordinate the CoinJoin transactions, there may have been (or there may be) connection and communication problems.

To ensure service availability, Wasabi Wallet is equipped to offer a fallback scenario where exit nodes are involved. For example, if the Tor onion service of the backend becomes unavailable for the user, the wallet falls back to communicating with the backend’s clearnet endpoint, still over Tor. Wasabi also frequently utilizes multiple Tor streams where applicable.

This allows the user to continue to operate, even in unusual/offline onion backend conditions.
The Tor label inside Wasabi Wallet shows the status of the Tor daemon. You can check that your connection is active by keeping an eye on it.

Who have been affected

Most of our users haven’t noticed any interruptions because Wasabi was able to recover automatically. There were a few users who encountered intermittent Tor connection issues. But in most of these cases, restarting the Tor client solved the problem.

The post Wasabi Wallet and Tor Consensus Issues appeared first on Wasabi Wallet - Blog.

While Bitcoin it is often wrongly considered as anonymous money, the blockchain underlying it is quite the opposite: an extremely transparent, immutable and verifiable system by anyone. Bitcoin does to money what the Internet has done to information: it provides indiscriminate access to a decentralized financial system.

Bitcoin by default does not provide the privacy we got used to with the traditional financial systems due to its publicly transparent nature. The aim is to have privacy by default while having the option to be publicly transparent at will.

Bitcoins are traceable on the blockchain

Each Bitcoin transaction contains at least one input (where the bitcoins come from) and at least one output (where the bitcoins are sent).

Another feature of Bitcoin transactions is that they must always match the previous transaction. If you receive 1 BTC, but later want to send only 0.4 BTC, you’ll need to make a 1 BTC transaction; 0.4 BTC will be sent as payment, while the remaining 0.6 BTC will be returned to the sender as change.

This means that once a single address is known, there is a trail that allows bitcoins to be tracked. This is a big problem for the privacy of network participants.

CoinJoin as a tool for defense

The most promising way to maintain your financial privacy with Bitcoin is through CoinJoin. CoinJoins can be done in a trustless way, meaning that there’s no risk of funds disappearing or being stolen. Each of the signatures needed to create a valid transaction are created on the participant’s computers, so anyone attempting to connect the signatures will not be able to change the transaction or redirect the funds.

The funds will always be in a Bitcoin address that the user controls and is done in a decentralized way, so that the service does not rely on external third parties or centralized servers.

Services like CoinJoin keeps everyone anonymous, even if the observers are participating in the CoinJoin itself. Unfortunately, however, mathematics cannot be fooled. The problem is that it’s still possible to match inputs and outputs since there are usually only a few possible combinations.

To mitigate the possibility of someone understanding which inputs and outputs belong to each other, the protocol must be standardized in some way. Since inputs cannot be easily standardized, a fix would be to default outputs and set a minimum denomination.

For example, you could limit the outputs to exactly 0.1 BTC. Limiting these outputs to exactly 0.1 BTC would make it impossible to understand which input corresponds to which output and vice versa, as each output will be 0.1 BTC. It will still be possible to track the change, thanks to a particular attack called CoinJoin Sudoku.

CoinJoin is an extremely discussed Bitcoin implementation, first proposed by the Bitcoin Core developer Gregory Maxwell back in 2013. CoinJoin transactions have been a reality for years, but in all this time, one problem has always remained: someone like Alice, Bob or Carol has to build the transaction starting from 0.
This person must, in fact, know exactly which old addresses send bitcoins to the new addresses, otherwise it would be impossible to generate the transaction.

If this person is a spy, which is often impossible to know for sure, the effort becomes useless: the spy could re-establish the trail of ownership of the CoinJoined coins.

Chaumian CoinJoin

The advanced version of CoinJoin is, again, from Gregory Maxwell and it’s called “Chaumian CoinJoin” (named after David Chaum’s blind signature scheme).

Alice, Bob and Carol connect to a central Chaumian CoinJoin coordinator server. This is the system used by Wasabi Wallet, where the CoinJoin coordinator server is run by zkSNACKs Ltd., the company sponsoring Wasabi Wallet’s development.

Then they (Alice, Bob and Carol) share their sending addresses, together with the blinded receiving addresses, which are signed cryptographically from the server.

Alice, Bob and Carol disconnect from the Chaumian CoinJoin coordinator and then reconnect via a new identity under Tor hidden service and provide their unblinded addresses. Thanks to Chaumian’s blind signatures, the central server verifies the ownership of Alice, Bob and Carol’s addresses without knowing which address belongs to whom.

The Chaumian CoinJoin gained little momentum for several years. Then, in 2017, Ádám Ficsór, while working on TumbleBit, decided to implement it. Initially included in the ZeroLink framework research, Chaumian CoinJoin was then implemented in HiddenWallet, and subsequently in Wasabi Wallet.

WabiSabi and the future of CoinJoins

WabiSabi is a work-in-progress cryptographic protocol based on keyed-verification anonymous credentials, homomorphic value commitments, and zero knowledge proofs (range proof) that allows the creation of many different protocols from Chaumian e-cash, gift cards, utility/access token, reward system, etc.

zkSNACKs, will use it it to coordinate better CoinJoins, as WabiSabi is much more flexible than the current protocol based only on Blinded Schnorr Signatures.
This will allows Wasabi Wallet to build CoinJoin transactions with different denominations and with a better block space efficiency. Thanks to WabiSabi, not only will a CoinJoin participant gain more privacy against the coordinator because it will not know the common input’s ownership, it will also reduce the change outputs.

Summing up, thanks to the combination of these features via the WabiSabi protocol:

• A Wasabi Wallet user can make transactions with arbitrary amounts by participating in a CoinJoin
• A much smaller denomination than the actual 0.1 BTC will be required to participate in a CoinJoin
• The coordinator will no longer be able to link multiple inputs from the same participant and will no longer be able to link inputs to the change output
• Less UTXOs will be created

A simplified explanation with an informal description by analogy using real world concepts is also provided.
For more information on how the credential scheme can be applied, we also describe a generic protocol (work in progress).

The post What is a Coinjoin? appeared first on Wasabi Wallet - Blog.

The vulnerability has been fixed and can no longer be exploited by a potential attacker.

Who’s affected?

Before the v4 Hard Fork, an attacker could have exploited the vulnerability to perform a DoS (denial-of-service) attack, in such a way that it was difficult to identify the attacker itself. Denial of Service means that the attacker would halt the entire CoinJoin process for all other participants and Wasabi rounds would no longer work. Given that we have not observed any DoS attempts thus far, we assume that no Wasabi user has been affected by the vulnerability.

It is important to specify that the attacker could neither steal users’ funds nor deanonymize anyone. What they could have done was to prevent the completion of the CoinJoin process.

User Action

If you have already downloaded Wasabi Wallet v1.1.12, released on August 5th, 2020, then you are ready to take full advantage of the v4 Hard Fork; which fixed this vulnerability. In this case no user action is needed.

If you have not yet upgraded Wasabi to v1.1.12 version, we urge you to do so; as the Hard Fork breaks the compatibility with older software.

Timeline of Events

• 2020, May 10: Ondřej discloses the vulnerability to the Wasabi team.
• 2020, May 11: Wasabi team confirms the existence of the vulnerability.
• 2020, May 12: Wasabi team pays out a Bitcoin reward for the findings.
• 2020, May 14: Wasabi team starts working on fixing the issue.
• 2020, June 04: Wasabi team finalizes and then plans the deployment of the fix.
• 2020, Aug 05: Wasabi Wallet v1.1.12 is released with the client-side fix.
• 2020, Sept 03: Wasabi Wallet v4 hard fork is deployed.

Closing Thoughts

Finally, we’d like to thank you Ondřej and we hope your actions set the example for responsible review, notification and resolution of vulnerabilities.

Responsible Disclosure

Dear Adam,
I found a severe security issue in your implementation of the coinjoincoordinator. An attacker can exploit the vulnerability to perform adenial-of-service attack such that it's extremely difficult to identifythe attacker.This paragraph summarizes how blind Schnorr signatures are used in yourimplementation. At the beginning of each round a fresh blind Schnorrsignature key pair is generated for every round level. In the input registration phase a participant of the coinjoin registers unspentoutputs in their possession as inputs to the coinjoin transaction andone or more blinded addresses as outputs of the coinjoin transaction. In the connection confirmation phase the coordinator determines how manylevels the participant has funds to participate in, and returns them thecorresponding number of blinded addresses signed with the correspondinglevel keys. In the output registration phase the participant (under adifferent identity) reveals their (unblinded) outputs with the(unblinded) signatures that are verified by the coordinator.A nonce that is used in blind Schnorr signatures is supposed to begenerated freshly for every signature. If a signer generates twosignatures using the same nonce, it's easy to determine their privatekey as same as the private part of the nonce.The problem is that the nonce in your implementation is part of the keypair. As a consequence the nonce is the same for all outputs registeredon the same level. That means that a participant that registers at leasttwo outputs on the same level is able to determine the signer's private key.Suppose h is a blinded message to be signed, d is the coordinator'sprivate key and r is the private part of the nonce.The signature of the blinded message is r - d * h modulo the order ofthe group that is used (secp256k1 in our case). Suppose an attacker hassignatures s1 and s2 of distinct messages h1 and h2 signed with the sameprivate key and nonce. Then the following holds:(s1 - s2) / (h2 - h1) = ((r - d * h1) - (r - d * h2)) / (h2 - h1)  = d * (h2 - h1) / (h2 - h1) = ds1 + h1 * d = (r - d * h1) + h1 * d = rAn attacker that knows the signer's private key can generate a validsignature for every message. Therefore, they are able to register anoutput that was never blind signed by the coordinator. What are theconsequences? As long as the implementation of the client is sound, theattacker can neither steal a decent amount of coins nor deanonymizeanyone. What they can do is prevent the completion of the coinjoin, inother words denial-of-service attack. I've got the following ideas:  * The attacker registers (in the output registration phase) both theirreal outputs and one or more fake outputs. Consequently, there are oneor more participants that aren't allowed to register their outputs sincethe output registration phase ends when there are as many registeredoutputs as returned blinded signatures in the connection confirmationphase. These participants naturally refuse to sign the conjointransaction. As a result, their unspent output registered as inputs tothe coinjoin are banned.  * The attacker registers only one of two of their real outputs. Besidethat, they register one fake output on a higher level. Because theyregistered as many outputs as they have been given blinded signatures,other participants can register their outputs. After that, thecoordinator builds a transaction that can't be valid, since the sum ofall inputs is less than the sum of all outputs. I didn't investigatewhat happens next.What are the possible fixes for this bug?  * The coordinator on request generates nonce pair, remembers bothprivate and public part, and returns the public one. A participant thatregisters their unspent outputs and blinded addresses uses the nonce toblind the addresses and sends the nonce in his request. The coordinatorfinds the corresponding private nonce, blind signs the addresses, andforgets the nonce pair, so it's not used repeatedly.  * Replace Schnorr blind signatures with RSA blind signatures, sinceRSA signature doesn't require nonce. I think you used RSA before.Nevertheless, I don't like this approach because RSA in contrasts withelliptic-curve cryptography isn't so widespread in the bitcoin community.I hope you appreciate this report!

Best regards,
Ondřej Vejpustek

The post WVE–005 Responsible Disclosure & v4 Hard Fork appeared first on Wasabi Wallet - Blog.

Given the huge correlation between Bitcoin and Tor, the news quickly reached major social media, chat rooms and forums; but there is still a lot of confusion about it.
This article will explain if Wasabi Wallet is affected by the issue and how the technology behind Wasabi guarantees security for its users.

TLDR

1. Bitcoin replacement attacks are not possible due to the architecture of Wasabi.
2. Even if they’d be Wasabi stays inside Tor, except in fallbacks.
3. Even if fallbacks, Wasabi enforces HTTPS traffic, so exit nodes still cannot read or replace the traffic.

Summary of the attack

The entire operation is an MITM (man-in-the-middle) attack to Tor users. This attack tries to manipulate traffic as it flows through (malicious hacker controlled) Tor exit relays. The attackers selectively remove HTTP-to-HTTPS redirects to gain full access to plain unencrypted HTTP traffic without causing TLS certificate warnings.

Specifically, hackers attacked multiple bitcoin mixers. They replaced bitcoin addresses in HTTP traffic to redirect transactions to their addresses instead of the user provided bitcoin ones. By replacing the destination address at the HTTP traffic level, the attackers hijacked the user’s funds without the users’ or the Bitcoin mixer’s knowledge.

Why Wasabi is safe and how it defends itself against this type of attack

It’s simple: because Wasabi Wallet is a non-custodial privacy-focused Bitcoin wallet that implements trustless CoinJoin, there are no addresses sent to a server when sending money.
Also, unlike many other “traditional” mixers where users must give control of their coins to another party and trust that this party will return the bitcoin to them, Wasabi Wallet does not take custody of assets.

When sending money, there is no network traffic saying something like send 1 BTC to bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq, so there is no amount or address that can be intercepted and replaced.
In Wasabi Wallet, the user broadcasts Signed transactions. In fact, the wallet broadcasts it to the P2P network using random nodes on the Tor onion network.

During CoinJoin phases, however, an exchange of information about addresses involved takes place.
Specifically, during the input registration phase, this is the data that is exchanged:

• The input coins that you want to register, together with the input proof signature.
• The cleartext change address.
• The cryptographically blinded anonset CoinJoin output.

And subsequently, during the output registration phase, this is the data that is exchanged:

• The cleartext address for the anonset CoinJoin output.
• The coordinator signature over that output.
• The round hash of all the inputs.

But even if an attacker were to carry out an MITM attack by breaking the cryptography that certifies the coordinator signed outputs and replacing an address, the client would not sign the transaction, so no one would be able to hijack the funds.

On the network side, by default and under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays.
All Wasabi Wallet’s traffic stays inside the onion network, and most Tor attacks are not possible if exit nodes are not involved.
In Wasabi, exit nodes are only involved in fallback scenarios.

Fallback scenario? What are you talking about?

Let’s give an example: if the Tor onion service of the backend becomes unavailable for the user, the wallet falls back to communicating with the backend’s clearnet endpoint, still over Tor. This allows the user to continue to operate, even in unusual/offline onion backend conditions.
Regarding the website itself, connections are SSL-enforced and HSTS enabled.

Yes, I know, all these acronyms can seem difficult to understand. But just keep reading, and you will see that we will simplify them in the best possible way:

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.
(Source: Wikipedia)

Don’t Trust, Verify!

As we mentioned earlier, Wasabi’s fallback servers (Mainnet and Testnet) make use of encrypted connections and enable HTTP Strict Transport Security.

Let’s start Wasabi Wallet, open the config file from the wallet GUI, go to File>Open>Config File.

The first lines should look like this:
"Network": "TestNet",
"MainNetBackendUriV3": "http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion/",
"TestNetBackendUriV3": "http://testwnp3fugjln6vh5vpj7mvq3lkqqwjj3c2aafyu7laxz42kgwh2rad.onion/",
"MainNetFallbackBackendUri": "https://wasabiwallet.io/",
"TestNetFallbackBackendUri": "https://wasabiwallet.co/",

MainNetFallbackBackendUri and TestNetFallbackBackendUri are, respectively, the two clearnet backends for Mainnet and Testnet to which Wasabi Wallet connects in case the two .onion backends are inaccessible.

As you can see, both of them are using secure HTTPS connections.
What about HSTS? For this, we can rely on one of the many tools online that allow you to test if a specific domain/ip has HSTS enabled.
Both of them have HSTS enabled, check for yourself:

• Fallback Mainnet backend test
• Fallback Testnet backend test

Your security, like your privacy, is our top priority

Wasabi Wallet is safe in both, Tor onion network and clearnet.
In addition to this, exit nodes are only involved in fallback scenarios. This type of scenario is extremely rare; and should it happen, we have still adopted all the best practices to ensure the safety of your funds.

Additionally, in a custodial mixer, a passive network attack is really dangerous because the attacker can deanonymize all the users and see all their activity. With Wasabi Wallet, this is not possible because even the Wasabi coordinator cannot deanonymize its users.

Learn more about how Tor works within Wasabi

Using Tor within Wasabi has several facets:

• Wasabi frequently utilizes multiple Tor streams where applicable and registration of CoinJoin inputs and outputs is done through different Tor streams to avoid linking.
• The backend server serves block filters to all the clients over Tor. From those filters, the clients figure out which blocks they are interested in and downloads them [and some false positive blocks] from random peers. One block per peer, and always over a fresh Tor stream.
• Wasabi connects to each peer through a different Tor stream. A new random Bitcoin peer is used for every transaction broadcast.
• Wasabi broadcasts transactions to only one peer over Tor, and immediately after that, the peer is disconnected.
• Every fee query happens over Tor with a new Tor identity.

Do you want to learn more? Visit our documentation pages!

The post Wasabi Wallet and Tor SSL stripping attacks appeared first on Wasabi Wallet - Blog.

What’s new?

Among many other improvements, this major release is a preparation for the upcoming v4 Hard Fork. In the near future, the backend will be upgraded to v4 and Hard Fork means that it will break the compatibility with old clients. In any case, your funds are safe, even if you forget to upgrade – you will just find yourself in front of an “upgrade your client now” message.

To avoid this it is recommended to upgrade, as this version support both v3 and v4 backend.

There are many other improvements, so without wasting further time, let’s go see them specifically:

Major connectivity improvements

We upgraded Tor from v4.2.5 to v4.3.5 on both client and backend side – hopefully, it will mitigate the connectivity issues. Also, there were a couple of Tor/Connection related issues that were fixed. See the changelog here for more details.

PayJoin support

Together with BTCPay, we added PayJoin support that can work through Tor.

PayJoin is a collaborative transaction between the sender and the receiver of a payment, for example the merchant and the customer. The goal of the protocol is to break the common input ownership heuristic, while making it difficult to fingerprint that the transaction is in fact a CoinJoin. Further, it reduces the transaction fees paid by the merchant due to the consolidation of coins.

For more information about PayJoin and to find out how to use it within Wasabi Wallet, click here.

Hardware wallet Segwit vulnerability fix support

The recently disclosed security vulnerability caused compatibility problems with some hardware wallets. We added support to the newest firmware where this vulnerability is fixed. Important! Upgrade your hardware’s firmware!

v3 and v4 backend support

Since the 12th of January 2019, the backend API hasn’t been changed. A couple of minor issues accumulated from that time. Many could be fixed with backward compatibility, so old clients still worked well; but in some cases, we were not able to make a clean/compatible solution and are now about to remove the patches and apply refactorings.

Also on the client-side, we made several improvements since then to mitigate connection issues or timeouts that can lead to failing CoinJoins. Even if most of the users are using the newest version, anyone with an old client in the CoinJoin round times out and will disrupt the round for everyone. With the Hard Fork, we also want to put everyone on the same page.

The hardfork was not deployed yet but this client version supports both version. So it is recommended to upgrade to be able to use the software when the backend will be upgraded in the near future.

The most important updates include:

• Stricten Mempool Acceptance With Batching #3670
• Better filter generation #3542
• Using Bitcoin Knots on the backend #3330
• Fix of banning clients in case of mempool dis-acceptance #3741
• DoS Attack fix #3815
• Fee computation fix #3808
• Better SchnorrBlinding #3739
• Added caching #3088

Bitcoin Knots 0.20.0

This version contains important bug fixes, this is a recommended upgrade for users who are actively using the full node integration feature. See the changelog here for more details.

Various stability improvements and bug fixes

We have made many minor improvements and fixed dozens of bugs. See release notes for details.

How to update?

To update to the latest version, go to https://wasabiwallet.io/ and choose the package based on your operating system.
If you prefer, you can also find them on https://github.com/zkSNACKs/WalletWasabi/releases/

The post Wasabi Wallet 1.1.12 is out! appeared first on Wasabi Wallet - Blog.

If you’re a Wasabi Wallet user with a Trezor device, please don’t update your current Wasabi Wallet installation and Trezor devices to version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) yet or you may get locked out of your bitcoins until we fix the issue. Please update both when we’ve published a new version of Wasabi Wallet through our official channels.

Last Wednesday, SatoshiLabs s.r.o., the makers of the popular Trezor hardware wallet, has disclosed a security vulnerability in the Partially-Signed Bitcoin Transaction specification (BIP-174) that can potentially exfiltrate a victim’s bitcoins by paying too high mining fees, if the vulnerability is exploited.

The vulnerability was fixed on Trezor devices but it broke the compatibility with HWI and other 3rd party software, like Wasabi and BTCPay server. As a result, Trezor devices updated with the newest firmware version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) are not working with Wasabi and other software wallets.

How does this affect Wasabi Wallet users with a Trezor device?

First, before we go into the gory details of the vulnerability, we need to have a primer on how your Wasabi Wallet interacts with your Trezor hardware wallet.

In a nutshell, a Hardware Wallet’s primary function is to hide all the necessary Bitcoin secrets like your private keys away from systems that is inherently more insecure like your PC, Laptop or Smartphone while also allowing the user to receive and spend the coins as they see fit.

It does that by utilizing a Software Wallet that can communicate with the Bitcoin network. Whenever a user wants to spend their coin, Wasabi Wallet will construct a Partially-Signed Bitcoin Transaction (PSBT) and it sends the request to the Trezor device to be authenticated by the user.

After authentication, it sends back a fully signed PSBT to Wasabi Wallet, which in turn broadcasts it to the Bitcoin network, effectively completing the spending transaction.

The latest firmware upgrade of Trezor has deviated from the normal implementation of the PSBT specification in BIP-174. The hardware wallet now expects that all inputs of a PSBT include its prior transaction data. This information is then used to verify the fees paid to the miner, and thus eliminates the attack.

However, this poses a multitude of problems:

• Because the original specification did not specifically allow for additional prior transaction data; The interface layer between Wasabi and Trezor devices strips down that prior transaction data from the PSBT, which in turn makes the Trezor wallet think that the PSBT it received is invalid because of the missing data, hence rejecting its authentication and effectively preventing the user in spending their bitcoin.
• The software wallet may also not have the required previous transaction data from the Bitcoin blockchain and thus it may need to acquire that whilst preserving the privacy of the user. This may be impossible or resource-intensive.
• The PSBT file size might increase significantly in case the input coins was from a CoinJoin or any other large transaction. Imagine if you’ve included 2 coins from your recent Wasabi CoinJoin, the wallet will then need to include the large CoinJoin transaction data twice. The enlarged PSBT could cause problems in transmission to the Trezor device or other hardware wallets that may not necessarily support the large PSBT sizes.

In light of the aforementioned problems, we at Wasabi Wallet are urging our users with Trezor hardware wallets to hold off updating their devices to firmware version 2.3.1 (Trezor Model T) and version 1.9.1 (Trezor One) and also avoid updating their Wasabi Wallet installation until the team can make a proper fix to this issue.

Until then, we hope for your continued patience amidst this issue. Thank you.

Addendum: We are advising users to not update Wasabi Wallet until the fixes are out due to the potential of bad actors distributing a malicious copy of Wasabi Wallet and exploiting the vulnerability.

The post Wasabi Wallet’s advisory for Trezor users appeared first on Wasabi Wallet - Blog.