Related: #31, #30, #38

Update: I started this specification, but I gave up, because it is a hack that results in blockchain space wasting and a painful user experience. I came to the conclusion that we must find a hardware wallet vendor who is willing to cooperate with us to implement autosign. In fact in order to not cripple us in the future, for example with Reverse CoinJoins what we must do is to make the hardware wallet to autosign EVERYTHING that Wasabi feeds it with for a time period the user chooses (hours, days, weeks).

Motivation

While hardware wallet integration was originally not planned in the near future, it was the most requested feature so far and a pattern has emerged where many of our users sent out their money to their hardware wallets, with this potentially jeopardizing their privacy and their peers', too. For these reasons hardware wallet integration became high priority.

The Problem

The main issue with hardware wallet integration in Wasabi is that, hardware wallets cannot do coinjoins, because the wallet must sign when user is at the computer. To resolve this, autosign idea has been proposed, however it requires support from the hardware wallet company and it possibly makes hardware wallets insecure.

Proposed Solutions

1. Disable CoinJoin

Wasabi should disable the CoinJoin tab for hardware wallets altogether.

1.1 To Wallet And To Extpubkey Send

Users will want to move their coins to their mixing Wasabi wallet. This should happen in a way that they avoid coin merging, which Wasabi should facilitate To Wallet and To Extpubkey Send.

1.2 Multi-wallet load

2. Confirmation For Send

When the user clicks "Send", Wasabi should tell the user that it is waiting for confirmation of the transaction on the hardware wallet.

Wasabi is being used with Hardware wallet to protect privacy but when unlocking most hardware wallet the xpubs can be read by every other app running on the machine and any website open in a browser. Given some people can have tons of crypto related website open this is a significant privacy risk.

A basic private messaging app built into the wallet would be also a good addition. BIP47 payment codes could be used for identifying users: zkSNACKs/WalletWasabi#477

PGP could be used to facilitate encryption: zkSNACKs/WalletWasabi#479

This is just a list of features I miss the most from Wasabi for my personal use.

• Full Node Integration
• Private Key Sweep
• Send from one wallet to another wallet (or extpubkey) with merge avoidance
• Daemon for mixing
• Temporary wrapped segwit receive address (instantly sweep to the wallet from this)

People can lose their privacy by checking their transactions in a block explorer over the clearnet. Wasabi could help mitigate this risk by adding an in-wallet block explorer query over Tor.

Would be very cool if we could coinjoin w a hardware wallet

Also a clear confirmation in ux that wasabi is connected to local node could be useful

This is a list of issues I would like to solve in Wasabi before I get hit by a bus. This is not only a list that only I can do, rather this is a list that consists of long term decisions and fixes those can make the job of the developers coming after me easier.

• Bitcoin Core Integration: This is not a work that can be justified by any kind of business logic, however it is utmost important for the future of Bitcoin, I feel like if I don't push it myself, it will not be done.
• Password Bruteforcer - It'd lower the number of "I lost my password" support tickets: zkSNACKs/WalletWasabi#1035
• Fix our RBF policy - The way we accept transactions to the mempool is not perfect, this'd lower the chance of future surprises: zkSNACKs/WalletWasabi#474
• Mempool filters? - A way to recognize unconfirmed transactions after wallet start would lower the number of support requests regarding this topic.
• Incorporate WindowsInstaller project into the Packager project - This would make the packaging process simpler. zkSNACKs/WalletWasabi#691
• Cache some stuff so loading the wallet would be faster - Valuable development time is spent waiting for wallet loading: zkSNACKs/WalletWasabi#444
• Speed up wallet by disabling address reuse - Same logic as above: zkSNACKs/WalletWasabi#1190
• Toast Notifications - So the dev won't have to keep finding places on the UI for error showing: zkSNACKs/WalletWasabi#845
• Tidy XAML Code: zkSNACKs/WalletWasabi#1056
• Dangerous Clearnet feature - Another tool in our toolbox to handle support requests when there are Tor issues: zkSNACKs/WalletWasabi#996
• Figure out proper sync mechnaism for terms, privacy and legal documents with website: zkSNACKs/WalletWasabi#596

Introduction

Wasabi users need to let the computers turned on if they want to participate in coinjoins because they need to sign the coinjoin transaction with the corresponding private keys that are under their exclusive control. This creates some usability issues and could be preventing to reach a higher level of liquidity in Wasabi coinjoin rounds.

During the latest Wasabi devs meeting @danwalmsley suggested that it would be beneficial for our user base if they could participate in coinjoins while disconnected or their computers are turned off. I think it is possible to implement such a system.

Goal

Describe the mechanisms that can allow Wasabi users to participate in coinjoin rounds without loosing control over their private keys, delegating the participation in a trustless third party (in this case I think it should be a Wasabi service).

Description

This proposal is based on atomic swaps and just for the sake of the simplicity we will describe it here in its simplest version.

Users point of view

An user Alice (A) wants to get private coins from the next coinjoin rounds but she doesn't want to let her machine turned on for many hours. Alice opens Wasabi wallet, goes to Coinjoin tab, selects the coins and enqueue them and turns off her computer. Next time she opens Wasabi wallet she sees the new clean coins arrived.

Wasabi point of view

When Alice enqueue her coins and presses the button to start the the process Wasabi client generates a secret number X and creates a transaction tx-alice-to-wasabi that spends all those coins to a scriptPubKey that can be spent only by Wasabi (Alice sends the coins to a well-known Wasabi pubkey) and only if wasabi can demonstrate it knows the secret value X. Clearly Wasabi can only know the value of X from Alice. Finally the Wasabi client sends two things to the Wasabi backend (HASH(X) and the tx-alice-to-wasabi). Using a different identity Alice sends to the Wasabi coordinator the list of pubkeys where it must send the resulting coins.

The Wasabi coordinator participates, with its own money, in the coinjoin transactions on behalf of Alice and creates outputs that can be only spent by Alice but only if she reveals the secret X that Wasabi needs in order to be able to spend the coins that Alice sent to it in the first step.

Wasabi client reveals the secret value X to the Wasabi coordinator to allow it to unlock the coin in the first transaction.

Note: there are different schemes available but not all of them are suitable for Wasabi because some of them can be canceled in anytime by one of the parties while we cannot. This scheme is the simplest one and also the more rigid one.

What if Alice doesn't reveal the secret value X?

Alice can only spend her money if she reveals the secret value so, once Alice spends the coins, Wasabi can recover its money too.

What if Alice doesn't reveal the secret value X and doesn't spend her coins?

We have no answer to this case yet.

Other uses in Wasabi

Atomic swaps can be implemented to create a way for users to exchange coins. Imagine someone who has 1,000 bitcoins and wants to get clean coins right now. That person could exchange his coins with Wasabi users who has mixed coins. That could generate a market.

Is your feature request related to a problem? Please describe.

Change outputs are currently nearly always unique and each output can therefore be associated with its corresponding input(s). However, looking at some CoinJoin transactions, there are many change outputs that are close to each other in value, and very often close to 0.1 BTC. If the values could be slightly adjusted to match other outputs, these outputs could become part of an anonymity set, or even contribute to the main anonymity set.

Describe the solution you'd like

I'd like to propose the idea of having the coordinator issue long-lived ecash tokens of a relatively small denomination, which users may cash in to increase their effective input, and which are paid out if an output is decreased to match other outputs. The ecash tokens obtained in one round may be used anonymously in a later round.

The client needs to trust the coordinator with the validity of these tokens, so they should only be used for small amounts and the client should only accept holding up to a certain amount of tokens at any time (e.g. up to 100k sat worth).

Ecash tokens should all be of the same denomination, e.g. 10k sat, for maximum anonymity. However, fractions of the token denomination may be handled by using provably fair stochastic rounding.

These tokens might be used in other ways: What about, instead of only adjusting output values to match, each output value is randomised a little, exchanging tokens to compensate? Outputs are no longer exactly equal, yet anonymity is preserved.

Describe alternatives you've considered

An alternative might be to allow for small output adjustments without exchanging ecash tokens, but the tolerated range of such adjustments would probably be smaller.

Adjustments via LN? I think it would get more complicated in several respects.

CT would of course fix this whole issue, but I don't think this is coming to Bitcoin anytime soon.

edit: I guess this issue rather belongs in ZeroLink.

In some areas Tor is unreliable (China). It'd be nice if we'd provide a VPN service so they'd be able to use our wallet without relying on external VPNs.

The zero link framework coin join protocol works by breaking the link between inputs and outputs of a transaction where the user is paying himself. I propose following scheme for providing the same privacy results, but in the case where sender and receiver are two different parties. Basically, it is the same flow as zero link, but there are some additional details when Alice and Bob are two separate entities.

1. Receiver generates an address, blinds it and sends it to the sender
2. Sender provides input proofs, blinded output and change output to the coordinator
3. Coordinator checks inputs, signs the blinded output and sends it back to the sender
4. Receiver unblinds the cj output and sends it back to the coordinator, but not to the sender
5. Coordinator checks the blind signatures, builds the cj transaction and sends it to sender and receiver
6. Receiver verifies if his output is included, and authorizes the signer to sign the cj transaction. Sender must trust that the receiver has verified address inclusion
7. Coordinator verifies and combines all signatures and broadcasts the signed cj transaction

Pro

• The sender does not reveal his previous transaction history.

• The receiver does not reveal his future transaction history.

• The coordinator can not link inputs to outputs, he does not even know if Alice and Bob are one same or two different parties.

Con

• Zero link output values are set at a fixed denomination, thus the sender/receiver can not negotiate the precise value transferred.

• Additional communication between the sender and the receiver, maybe also between receiver and coordinator.

Implementation

• Maybe, the receiver can generate and automatically blind a new address directly in the GUI, so that the blinded cyphertext or QR can be copied and send to the sender.

• The sender provides this blinded cyphertext in the input registration phase.

• Receiver checks every proposed cj transaction if his address is included, if yes, then sends authorization to the sender.

With BIP47 payment codes we could facilitate merge avoidance in our wallet: bitcoin/bips:bip-0047.mediawiki@master

As of now everybody opening the machine wasabi is running on can see transaction history (coin join history) of all wallets.

The easiest way (UX related) to password protect the whole wallet would be to offer a checkbox when setting up the wallet password that says "encrypt wallet" so if a user ticks the box he will be asked at every launch of wasabi to enter this password to gain access and prevent unauthorised users to open the wallet, check the balance, see the history, etc...

It would love to use this wallet but I prefer to store everything using cold storage with my Ledger Nano S. If you guys could add support so this wallet is useable with a Ledger Nano S I would begin using this as my primary wallet instead of electrum.

Problem

Wasabi is a privacy focused wallet, and it is succeeding on many fronts already. However, for every wallet, the master public key - the information needed for COMPLETE deanonymization of the transaction history - is in clear text within the .walletwasabi folder. An attacker would need access to the disk, and yes, when that is the case, we assume that everything is screwed, but we should do our best to defend as much as possible.

Solution

When the wallet is closed, encrypt the sensitive data [zpub, labels, anonset etc, probably everything other than wallet name and fingerprint] with the password the user set at wallet creation.

When loading a wallet, the password is required to decrypt this sensitive information, and then load the wallet.

Advantages

• Better privacy, even if hard drive is compromised
• Less risk of loss of funds, because password is required before an address can be generated
• Much more...

Protecting privacy from malicious users who gained access to the OS.

- very draft, ignore

Introduction

The team has decided to focus on achieving a more stable code base of Wasabi and for that reason most of the development effort is being invested on bug fixing and building an uniform experience across the different platforms.

It is my personal opinion that if well the goal is the right one, it is necessary to approach the task with a more delimited set of practices and processes. I will propose here what I think should be done.

Background

- this section can be skipped

Wasabi wallet was developed using a novel technology unknown for two out of three team members and with a challenging due date for the first working version, the goal was to have it done to present it during the Building Bitcoin (Lisbon, August 2018). The most important parts of the UI were coded in less that two weeks in a learn while doing approach.

After the first release version (1.0.0) the development continued driven feedback from users who requested improvements and features so, most of the development effort was invested in the development of new features under a highly frequency release cycle, that's why since October 31, 2018 (release date of the first stable version) there were 10 releases, most of them containing new features and also bug fixes, most of which were introduced in the previous release.

Hands on

A few things that I write here had already been implemented but It is important to put them here explicitly. The list of

Develoment

Code Reviews

All code has to be reviewed before being merged to the master branch. It could be good to have all the code reviewed by more than just one developer when possible.

Code complexity

Wasabi design is not complex but its code is. There is a bit high level of coupling in the components that makes it no so easy to isolate to test and there is a low cohesion intra-component because they use to work at different level of abstraction. Also, the cyclomatic complexity looks high mainly because of the null reference checking code, and exception handling.

In order to reach an agreement on what cleaning code means, this is what I understand that has to be done:
Decouple code, break dependencies, avoid passing/returning null, reduce cyclomatic complexity, refactor for achieving higher cohesion intra component.

Configuration management

We should define clearly what is supported and what is not, which dependencies we work with, which versions, etc. This is to avoid the introduction of breaking changes.

First of all we have to keep dependencies under strict control. No new dependencies should be allowed and do not upgrade components to unstable versions. If possible it could be a good idea to stick to those we know work okay and only upgrade after we are sure the new versions also work.

Define what OS/distributions/versions we support "officially". This is important for testing and support.

Q: What criteria needs to be met to say that a new release is "ready"?

Testing

Testing is unavoidable and it is critical to achieve a product with a minimum level of quality. We should implement testing in different of different types

• Unit tests
• Integration tests
• UI Tests / Mock tests (this could be manual but it doesn't scale at all and it expensive)

Unit tests

We should write unit tests for our code and cover most of the code flows. To be able to do this we need to write testeable code and be able to break dependencies. We have a debt in this point because the project has very few tests and even less unit tests in part because the code is not easy to tests.

Integration tests

Wasabi has many integration tests that are very useful. We just need to continue writing these tests when possible.

Manual test

Testing does not improve the code, reduce complexity nor improve maintainability but it is the only way to catch defects so, manual testing should be performed before merging every PR and not just at the end of the release cycle. These has to be done by the team members.

Given this kind of tests are slow, boring, very expensive and that its effectiveness decrease with the time, it would be a good idea to invest some time to research how to automate part of it.

Code freezes

We could consider to have a code freeze days before the release. This is in general a weird practice but i think it could help us temporarily.

Preview/Beta testing

We should consider to have release candidates as part of our development life cycle.
Once all the features, improvements, bug fixes have been merged to master and during the code freeze period, we could make available a release candidate or preview in order to have feedback from our user base and release a week after that.

Notes about MuSig in Wasabi coinjoin protocol

Disclaimer: This is a very preliminar document where we can discuss the topic. My current understanding of the scheme is very incomplete and the implementation in the bitcoin protocol is still unknown (we don't know where the signature will be or how the transaction hash for signing will looks like (are we going to have a new transaction id version? IDK). In summary, take this notes as preliminary understanding about the system.

It seems that MuSig is the multi-signature scheme that will be used by the bitcoin protocol, this is a schnorr-based scheme that allows key aggregation, what means that a signature produced by multiple
signers looks as the same length that one produced by only one signer.

This new multi-signature scheme can be used for improving the bitcoin protocol mainly in two ways: providing a better multisig script and allowing to have just one signature for the entire transaction instead of having one signature per input. In case the highlighted part is really implemented, it could be very important for Wallet because it could make the coinjoin transactions smaller (cheaper), which in turn
would allow us to implement some "crazy" ideas as sending anonymously "by free" (see the quotation marks)

Wasabi coinjoin protocol changes

A common misunderstanding in the team had being that given the signatures aggregation is a 3-rounds interactive process it cannot be used Wasabi coinjoin transactions. However, Wasabi coinjoin protocol is also interactive and the new signing process can be built on Wasabi.
Lets see how the Wasabi protocol could be modified to take advantage for the one signature for the entire transaction part.

At inputs registration phase

Each participant has to send the input pubkey (Xi) to the server. Wasabi doesn't need to change because those pubkeys are already available at input registration and are being extracted from the compact signatures in the input proof message.

Additionally each participant generates a new private key ri and derivates its public key Ri. The commitment ti is ti = H(Ri). The participant has to submit this commitment in the input registration message.

At confirmation phase

The coordinator shares all participants' public keys with the all the participants. With that, they can compute L as the hash of the multiplication of all the public keys: L = H(X1 * X2 +.....Xn).

Each participant computes all the values ai = H(L || Xi). And finally the aggregated public key AK = a1*X1 * a2*X2 *.....* an*Xn.

The coordinator also shares the all participants commitments ti with the all the participants. Once the commitments set is received each participant reveals its Ri to the coordinator. The coordinator verifies that each Ri received ti=H(Ri). In case it detects an error here the coordinator bans the participant and restart.

Once all the Ri were recived, the coordinator shares all the Ri with all the participants and they verify all the ti=H(Ri) as the coordinator does. Participants should not sign if that verification fails. Both coordinator and participants compute R = R1*R2*....+Rn.

At signing phase

Each participant receive the unsigned transaction and computes the signature as follow:

c= H(AK || R || m)
si=(ri + c*ai*xi) % p

Note 1 I am not sure what m represents here because participants have to sign their inputs so, the message m could be different for each one. I need to read more about this point.
Note II this will be implemented by NBitcoin by sure.

Next they send their signatures si to the coordinator who computes the final signature s as s=s1+s2+.......+sn

Interactive tutorials are great. Wasabi could directly add an interactive Bitcoin tutorial to the wallet, thus educating its users.

Is your feature request related to a problem? Please describe.

I would like to achieve plausible deniability of using any particular bitcoin address when third party has access to all my files (but without wallet password)

Describe the solution you'd like

Consider to implement local encryption of all personal files (whole client folder, I think) with wallet password

What are considerations for lowering the minimum UTXO sizes and allowing for custom lower limits?

A common size of "0.1 BTC" had to be used initially to favor large anonymity set focused at specific size.

As adoption increase a wider range of default sizes can be considered.

Fungibility can be increased by taking part in a large anonymity set coinjoin or participating in multiple coinjoin with a lower anonimity set over longer period of time.

The lower bound has to be low, not much higher than the monetary value of typical of an on-chain transactions (purchases/donations).
That size has to not be too high as to increase transaction sizes disproportionately to total amount spent.

Highlighted here are the sizes I think should be considered for mid term expansion.

An expansion plan could be done in steps to expand options while maintaining network effect via client defaults :

1. Allow client to instruct coordinator to limit a minimum size up to "0.8"
2. Keep default size to 0.1 but allow clients to participate with or select "MinSizeLimit" to one step lower. (0.05 BTC)

This assume that people limiting their min UTXO to participate in multiple 0.8 coinjoins are responsible enough to know that partaking in 10 consecutive CJ of 3 anonset is unlikely to be equivalent to a single 30 anon-set CJ.

zkSNACKs/WalletWasabi#1322
zkSNACKs/WalletWasabi#1238

Groupsends - hopefully someone can create a better cooler sounding name for this.

The idea behind GroupSends is to bring more privacy and fungibility to bitcoin by making it harder for blockchain analyst to accurately assign inputs and outputs to users. GroupSends will also lower the cost of transactions for users.

GroupSends is essentially users batching their transactions together using the same (or similar) setup as CoinJoin in WassabiWallet.

GroupSends can be setup to happen hourly, once per day and or once 100 inputs have been accumulated depending on demand.

Users would go into the GroupSends tab, select which UTXO(s) they which to use, the address(es) and amount(s) to send to and the wallet would create a change address for users. Once the target (hourly, 100, etc) for GroupSends was met then Wassabi Wallet will construct the transaction like it does for CoinJoins and transmit the transaction.

GroupSends would increase the anonymity of the outputs especially for the inputs that were previous;y CoinJoined.

Is your feature request related to a problem? Please describe.

Anybody with access to the computer will be able to have the public key of wasabi without having the password.

Describe the solution you'd like

Encrypt the wallet files with password

Describe alternatives you've considered

File path to an encrypted folder that is temporarily decrypted when using wasabi

Wasabi wallet is a very good step towards Bitcoin fungibility/privacy. However, without hardware wallets support this makes people again vulnerable against coin-stealing malware. Let's add Trezor support to Wasabi!

There is already a library for interacting with Trezor:

• https://www.nuget.org/packages/Trezor.Net/
• https://github.com/MelbourneDeveloper/Trezor.Net

Reach me via email ([email protected] - put your postal address + phone number there) if you are a Wasabi developer and you want Trezor devices for testing.

https://en.bitcoin.it/wiki/Privacy#Wasabi_Wallet

For this reason coinjoins can only be of fixed amounts of around 0.1 BTC

I know at least this is wrong.

Probably not, but the question worth to explore.

And by using some ideas from the Clusterfuck wallet: https://medium.com/@nopara73/new-bitcoin-anonymity-technique-the-clusterfuck-wallet-d48aa1787324

Would be fun to have a tool that enables users to play around with many different ways they can use RBF. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

I've just learned about Deniability via Eric Wall's post. It seems relatively simple to implement but I'm far from a crypto expert.

“Deniability” is a very simple and very old idea, that many people bring up from time to time. It does nothing “new”, it is merely a collection of “wallet-side” tools to make the shuffling process easier (ie, less labor-intensive, and with less potential for error).

I believe that it is profoundly under-appreciated. It is very effective and very easy, and painless to implement.

If so easy and useful, why don’t have it already?

Well, it is probably due to two stigmas: [1] the sigma of “wasting” block space4; and [2] the stigma of working on a privacy technology that is non-mathematically impressive and ostensibly uncreative.

Can Wasabi Wallet consider implementing this feature in addition to CoinJoin? From what I understand, deniability doesn't require other users, and it would be faster.

We could add a PGP client to our wallet, the current PGP softwares are quite clunky to use.

It is common that users lose or mistype their passwords. While we have limited capabilities to prevent it, we still can do a few things. This issue aims to gather all the improvements we had in mind to help our users avoid losing their password.

Chinese Password Box

Mistyping passwords happen, because of carelessness. Our Chinese password box aims to break the usual flow of our users, hoping they will pay more attention not to make typos when choosing a password. It is also a cool feature.

A possible improvement can be to add an info icon that would explain this experiment. However it would risk the degrading the effectiveness of this method, thus the user would calm down quickly and mistype his password anyway.

Moving Password Confirmation To Next Page

This also aims to disrupt the flow of the user. If the user does not just have to repeat the password, but rather write password, do some other task, and confirm password, then it's more likely issues are caught before they happen.

zkSNACKs/WalletWasabi#1142

Mnemonic and Password Tester

Mnemonic and Password tests can provide uncertain user certainty: zkSNACKs/WalletWasabi#1143

Password Typo Fixer

The most common issue that the user mistypes his password. We have built a yet rudimentary password typo fixer that can look for possible mistypings: https://github.com/lontivero/WasabiPasswordFinder

Even though this is just a basic tool yet, this has already been proved to be useful: https://old.reddit.com/r/WasabiWallet/comments/amw7u6/invalid_password_to_coinjoin_anything_i_can_do/efpomuv/

This should make it into the wallet:
zkSNACKs/WalletWasabi#1035

Improving Security?

Since we are working at this part of the code, we can consider some security improvements to be added here.

1. Once thing we could do is to provide additional entropy at wallet creation, for example with mouse movement?
2. Another security improvement can be to add 2FA in a less intrusive way: #43

I believe the ColdCard hardware wallet is the most underrated wallet out there.
https://coldcardwallet.com/

I know Wasabi Harware support is on the backburner but I'm putting out there in case Coinkine would want to expand it's wallet offering. I see a great synergy between the two company since the main focus is on Bitcoin and high level of professionalism.

The only hardware wallet that has support for Bitcoin Core.
https://github.com/Coldcard/firmware/blob/master/docs/bitcoin-core-usage.md

128kb of free flash for custom development.
https://github.com/Coldcard/firmware/blob/master/docs/dev-access.md

Automatically
Sign all the transactions, if
99% of the coin comes back to one of our addresses.
rate limit to 5 times a day,
feerate is lower than 2 sat/b
etc...
from
#30

Coldcard already has a Timeout feature that can be set to "Never" and a Max Network Fee protection setting.

https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6
https://medium.com/@nopara73/new-bitcoin-anonymity-technique-the-clusterfuck-wallet-d48aa1787324

General Description

After building WalletWasabi.Gui on the RaspberryPi and run it the following error occurs:
pi@raspberrypi:~/WalletWasabi/WalletWasabi.Gui $ dotnet run

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '/home/pi/WalletWasabi/WalletWasabi.Gui/bin/Debug/netcoreapp2.2/WalletWasabi.Gui.dll'. An attempt was made to load a program with an incorrect format.

How To Reproduce?

1. Install DotNet 2.2.203 ARM32
   403 mkdir -p $HOME/dotnet && tar zxf dotnet-sdk-2.2.203-linux-arm.tar.gz -C $HOME/dotnet
   404 export DOTNET_ROOT=$HOME/dotnet
   405 export PATH=$PATH:$HOME/dotnet
   406 dotnet
2. Build WalletWasabi.Gui
   git clone https://github.com/zkSNACKs/WalletWasabi.git --recursive
   cd WalletWasabi/WalletWasabi.Gui
   dotnet build
3. Run WalletWasabi.Gui
   dotnet run

Operating System

pi@raspberrypi:~/WalletWasabi/WalletWasabi.Gui $ dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca

Runtime Environment:
OS Name: raspbian
OS Version: 9
OS Platform: Linux
RID: linux-arm
Base Path: /home/pi/dotnet/sdk/2.2.203/

Host (useful for support):
Version: 2.2.4
Commit: f95848e524

.NET Core SDKs installed:
2.2.203 [/home/pi/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.4 [/home/pi/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.4 [/home/pi/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.4 [/home/pi/dotnet/shared/Microsoft.NETCore.App]

Wasabi Version

Latest version from:
commit 617f63a02301dfa21f144a6d9c86bc30156c3c03
Date: Mon Apr 22 15:04:41 2019 +0200

Just to start it looks like a variation of this topic is already being discussed, which already lays out some of my concerns. Meta/Bustapay integration

Is your feature request related to a problem? Please describe.

When trying to spend BTC from Wasabi wallet, there is no way to send BTC to BitPay backed merchants. I currently have to send to another wallet and process the payment from there.

Describe the solution you'd like

Here are some links to the "Payment Protocol" that BitPay uses. They created a JSON interface to help wallet integration.
FAQ of Payment Protocol
DEV Overview
JSON Payment Protocol Spec
This should serve as a starting point for anyone who want to look into it

Describe alternatives you've considered

Will the BitPay server be upset if the payment is received from a different IP than the one logged at the merchants website?

A work around would be exposing a private key and just sweeping/signing a transaction from the other wallet

To even test this you have to open a BitPay merchant account. Does anyone have one that can be used on the testnet?

Feel free to move this request or provide input if this is not something that would work with Wasabi

While we seem to be eligible for Bitcoin.org inclusion, I think it makes sense to bring closer improvements we were planning to do anyway, but we were not considering them as priority. It may be the right timing, because we have just completed all our "priority" issues we had and we are looking for a new direction to take our development. And you know me guys, I love to work on the basics, so working on it can be highly beneficial in the long term.
In this issue I gather all the possible improvements that can potentially improve our scoring in the website. I also include improvements and tasks those, while do not help to improve scoring, but the review of @crwatkins and @harding identified as possible improvements to our wallet.

Before that, first question should be for us to decide if this goal is worth pursuing. Please see the "Alternatives" section at the end and share your opinions @lontivero @danwalmsley @molnard @hgergoil @bharmat

Bitcoin Core Integration

a) Level.

Current: 3.

Level: Each wallet must have a level property assigned. A value must be in a range between 1 and 4. Level represents a category of a wallet:

• Level 1 - Full nodes
• Level 2 - SPV, Random servers
• Level 3 - Hybrid, Multisig wallets

We could easily make Wasabi SPV, we could just synchronize the header chain with NBitcoin, that's how HiddenWallet worked. However I believe that would be less secure, than our current way of doing things, since then Wasabi users could be Sybil attacked or miner attacked. Now, if a node sends us a block that does not match the hash we get from the backend, then we don't accept the block. This applies to our new partial Bitcoin Core integration, thus the local node is untrusted. I've seen @NicolasDorier and @petertodd share a similar concerns with SPV nodes. Thus I think working on level 2 would not make sense.

Thus if we want to improve the level we need a full node integration. One way to go about it could be to use Stratis's C# Bitcoin full node code: https://github.com/stratisproject/StratisBitcoinFullNode or go with bitcoind. While the first option is appealing, many users use and trust more bitcoind already, and it's probably more stable so it may be smarter to go down on that path. The ceveat is the difficulty of handling Core's constant changes. Shit can happen if the user upgrades its own node, but not its built-in Wasabi Core node, or the other way around. Also note that we need built-in Wasabi node. Maybe we could do the same way as we do with Tor, if the user has Tor we use that, if he doesn't we use Wasabi's. Anyway, it makes this complicated, but it's not unsolvable. It's just a detail.

I imagine this integration as an opt-out integration. Until Bitcoin Core is not fully synced, Wasabi would be used in light wallet mode, like how @jonasschnelli built his full-spv Bitcoin Core PR. However the a dialog should be shown to the user at first start that "hey, Wasabi is going to synchronize Bitcoin Core, and will work in light wallet mode until it's fully synced" and then buttons: "ok" and "no i want light wallet mode only."

b) Validation

Currently: checkfailvalidationcentralized. I believe the above improvement would make it checkneutralvalidationvariable. Or is it checkgoodvalidationfullnode? Not sure. @crwatkins can you help me out with this?

Deterministic Build

Current: checkpasstransparencyopensource. We could improve it with adding deterministic builds: checkgoodtransparencydeterministic. I still have my doubts as to how useful it is, but at the very least we can research into this topic and even if our opinion does end up it considering it unnecessary we can still add it if it does not come with considerable administration overhead or caveats: zkSNACKs/WalletWasabi#1078

Two-Factor-Auth

Current: checkfailenvironmentdesktop. This is another thing I'm not sure about if we can improve upon it. There are two levels we can target: checkgoodenvironmenthardware and checkpassenvironmenttwofactor.
@crwatkins can you help me out with this? Based on Electrum's scoring I see that opt-in two factor makes it eligible to checkpassenvironmenttwofactor, but opt-in hardware wallet integration does not make it eligible to checkgoodenvironmenthardware. Is that correct? If so, the best course of action is to add 2FA to Wasabi.
One thing to note though. We must be very careful with 2FA, because as Electrum's developer @ecdsa noted in Building on Bitcoin "users are more often losing their passwords than getting hacked." This corresponds with our experience, we didn't even yet have any user of ours who got hacked but we already had a handful of them who lost access to the wallet. (Some succeeded to gain access though.) I don't want us to end up doing more harm than good. Maybe we should consider building in our password typo fixer/bruteforcer to improve the situation before we ruin it with 2FA: zkSNACKs/WalletWasabi#1035

Network Level Privacy

I don't want to go into the details here, rather I just refer to the conversation: bitcoin-dot-org/Bitcoin.org#2788 But what we can improve here are the following:

a) Tor Integration to NBitcoin

To communicate with peers over Tor. One way to do this would be to implement Tor communication to NBitcoin, but maybe we should take NBitcoin's code, implement Tor, wait half a year or so until it stabilizes, and then contribute it back to NBitcoin. @lontivero @NicolasDorier opinions?

b) Bitcoin Core Integration with Tor By Default

If we add Bitcoin Core, then we should not at any circumstances broadcast transactions on the clearnet through it, luckily Tor comes with Wasabi, so connecting the dots here should not be difficult.

RBF and CPFP

Currently: checkpassfeecontroldynamic, next level to target: checkgoodfeecontrolfull.
This requires RBF and CPFP. They are problematic from a privacy/wallet fingerprinting point of view, (mainly the former) so if we decide to implement this we must be very careful and a comprehensive elaborate strategy is needed for them.

Audit

Wasabi did not yet receive an audit. @kristovatlas has expressed interest in doing one some time in the future. When we'll have the resources in the future we can hire him to do so.

Alternatives

While this can be a direction we could take Wasabi's development, there are others we can consider. Feel free to suggest new ones.

• Hardware Wallet Integration
• UI And UX Improvement Sprint
• Mixing Improvements: Reverse CoinJoins and P2EP with Reverse CoinJoins
• Accessibility Improvement Sprint: OSX signing, EV HTTPS, rpm, pacman, etc packages and package managers, sweep private key, sweep receive to wrapped segwit, implement bech32 to other wallets/libraries like BitcoinJ, etc...
• Just keep fixing issues in an unorganized way.
• Keep it safe and fix issues tagged with "solution is non-controversial"
• Tacking all the debug issues.
• Concentrate on to bring more users on board, which brings us more resources, so we can pay more developers so we can more effectively address issues. For this note that about 7+-2 developers should be the maximum number of devs working on Wasabi, it looks like too much devs make things get out of hand, since over 7 people the administration and collaboration makes the work less and less effective. Refer to: The Mythical Man-Month and The Magical Number Seven, Plus or Minus Two

Watch nopara73's presentation to get familiar with the history of Wasabi.
Read this blog post to get familiar with the features of Wasabi.

Beta Release

The Beta Release is planned to August 1, to the first anniversary of the UASF movement.
Issue tracker for Beta Release Milestone: https://github.com/zkSNACKs/WalletWasabi/milestone/4

The goal of the Beta Release is to build a fully functioning and stable software. This release DOES NOT include packaging, the user must build from source and must pre-install external dependencies, like Tor, by himself.

1.0 Release

The 1.0 Relase is planned to October 31, to the 10th anniversary of the Bitcoin whitepaper.

Issue tracker for 1.0 Release Milestone: https://github.com/zkSNACKs/WalletWasabi/milestone/5

The goal of the 1.0 Release is to make sure we are facilitating the usage of the software out of the box. This release must include Linux packages, pre-built binaries and also must have every dependency (like Tor) shipped.

Raising Capital Policy

We do not accept investment offers, but we will reconsider this decision of ours after the 1.0 Release. Please get in touch with me ([email protected]), if you'd like to be notified when we decide to open our doors.

That being said, we do actively seek for experienced and well-respected angel investors. We do see the opportunity of getting invaluable allies in our fight for privacy. In practice this would further strengthen our credibility and legal positions. As a real life example, a shady exchange, called Poloniex that among other things stole everyone's ETC, recently got legal immunity of its past misbehaviours, because a reputable company, called Circle bought them out.

Marketing Policy

In Bitcoin, privacy is teamwork. People can only hide in crowds. The user experience of our software directly gets better as more and more people uses it. Thus we need to put proper marketing preparations in place. We will start working on these after the Beta Release.

If we would have all the coinjoins and all the post-transactions, we could monitor how other people use the wallet and calculate anonymity sets based on the data.

It would be great if Wasabi could support sending bustapay payments.

Here's the spec: https://github.com/RHavar/bips/blob/master/bip-bustapay.mediawiki

It's actually a pretty straight forward protocol, that's a bit easier to develop than it looks -- and offers pretty powerful privacy improvements.

I have somewhat of a reference implementation here, which is pretty easy to follow along:
https://github.com/RHavar/bustapay/blob/master/send/send.go#L16

And to save anyone the trouble of setting up a bustapay receive server, I have one already running on testnet: http://test.bustapay.com

e.g. with the reference client you can go:

bustapay send $(curl http://test.bustapay.com/get-newish-address) http://test.bustapay.com  0.01

which would make a 0.01 BTC bustapayment to a (new) address on that server. I'd also love any feedback before that spec is fully finalized.

(And most importantly, I have some buy-in from some bitcoin services, so it actually stands a chance of achieving some adoption)

Problem

If one key is secure, then three keys must be thrice as secure. Right. Right?
Anyway. Multi Signature is one of the most powerful scripts in Bitcoin, a premiere wallet should support such a brilliant feature.

Solution

This might be a rather complex change, however, I'd say that PSBT is a very good tool to accomplish the task! Wasabi already utilizes HWI, and I think it includes the ability to generate an unsigned multisig PSBT. It might be more difficult to implement the signing of such multisig transactions...

Cold Card [ping @peter-conalgo] and Wasabi [ping @nopara73] are already a great combination, and it will be unbelievable when Wasabi can support the software part of the air-gapped multisig. I'll investigate the details of what must be included in the implementation, but I think it's "only" to specify the multisig input and outputs, plus all the PSBT details...

We can use the ColdCard Electrum branch as code reference.

Consideration

Schnorr MuSig will fundamentally change the concept of multi signatures, and since it will be upgraded to the protocol in #twoweeks, it might be justified to wait until this and focus developer time elsewhere...
But I think that supporting script based multisig is useful already, especially considering PSBT.

And I due think it's good to start with the comparatively easy setup of the hardware multisig, and later working on hot wallet.

Many wallet functionality could be explained with Infographics.

Friends and family can help out each other, because they already trust each other. Not with money, but probably with privacy.
There can be something like "Friends you trust your privacy with."
So every time a transaction happens a friend who happens to be online can make a coinjoin with you, both improving privacy.

https://medium.com/@nopara73/new-bitcoin-wallet-experience-thinking-outside-the-box-845b8a22a7e0

More: nopara73/ZeroLink#74, nopara73/ZeroLink#73

A way of facilitating funds to make their way into the wallet would be to introduce transitionary P2WPKH over P2SH addresses those would not be checked against Golomb-Rice filters, but rather a single backend query would establish its balance only once, then immediately sweeping the money to a bech32 wallet-managed address.

It could be a good convenient to implement a Tor client in c# for Wasabi. In this way we could avoid the necessity of distributing the official Tor software for different platforms.

A very first attempt to build a PoC client was code here: https://github.com/lontivero/Torpedo based on the also in-development project https://github.com/Marten4n6/TinyTor (an one-file python library)