Mixing while computer is turned off

[lontivero]

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.

[nopara73]

1. Alice generates X.
2. Alice sends to Wasabi AND HASH(X).
3. Alice gives output scripts (Alice and HASH(X)) to Wasabi. -> so privacy against Wasabi is not a requirement?
4. Wasabi mixes.
5. When Alice spends an (Alice and HASH(X)) script, by this Alice reveals X, so Wasabi can spend Wasabi AND HASH(X).

In this case anyone can correlate scripts (Alice and HASH(X)) with Wasabi AND HASH(X) and ultimately with Alice's first UTXO.

I may also misunderstand the proposed scheme though. Can you write it down again in a less novel-ish form with some illustrations?

[lontivero]

Okay, there I go:

• I think it is possible to implement a mechanism to allow getting mixed coins without needing to be connected.
• The idea is about using atomic swaps. In this way users don't need to lose control over their money.
• The atomic swap scheme used in the description is not the one we should use. It was used in this text just for simplicity.
• Key aggregation and MAST I think make possible to create an atomic swap where Alice doesn't need to reveal the secret X so, there is no way for an observer to match anything. This is because if Alice acts properly them the script branch where the X is use doesn't need to be revealed.
• I don't know if it is possible to create an scheme where Wasabi cannot learn anything, I should think more about that.

[ZmnSCPxj]

A (partial) solution available now is to use a 2-of-2 to hide the script on one of the UTXOs. https://zmnscpxj.github.io/offchain/generalized.html

Rather than Alice paying to (Wasabi AND HASH(X)), it pays to (Wasabi AND Alice), then provides a transaction spending that (Wasabi AND Alice) to ((Wasabi AND HASH(X)), and the signature for that transaction from Alice. That transaction is kept offchain by Wasabi.

Wasabi still has to pay to (Alice AND HASH(X)) post-coinjoin though; the same technique cannot be done until the coinjoin is onchain, unless we are willing to use SIGHASH_NOINPUT, which Bitcoin Core wants to restrict to specific "tagged" outputs (and which probably loses privacy simply because of the tagging, as well as not being available now).

In any case: when Alice comes online and claims the (Alice AND HASH(X)), then Alice also needs to provide a finalizing transaction from the previous (Wasabi AND Alice) output to a new Wasabi output. In the best case Alice sends this and Wasabi signs it and broadcasts that transaction instead of the offchain transaction. If Alice does not provide the finalizing transaction in a timely manner to Wasabi after claiming the (Alice AND HASH(X)) output, then Wasabi will publish the previous offchain transaction and reveal the link between post- and pre- mixed coins, so Alice is incentivized to perform this.

Liabilities are still:

1. Wasabi can still link Alice pre- and post- mixed coins.
2. Wasabi can choose to use the offchain transaction even if Alice gives the finalizing transaction in a timely manner.
3. The coin that is semantically owned by Wasabi cannot be used by Wasabi unless Alice spends the coin semantically owned by her, thus, possibly allowing a DoS vector if Alice is richer than Wasabi and is willing to lock coins indefinitely. This can be fixed by adding a timelock to the condition so that Alice is forced to spend the post-mix coin or retain ownership of pre-mix coin.

Thus still highly undesirable.

---

It is also the possibility, to use 2p-ECDSA (today) to implement Scriptless Script "hashlocks" (really pointlocks), which lets a signature leak the private key of another pubkey as long as some data (part of 2p-ECDSA) is given by Alice to Wasabi. Then Alice, by the simple act of signing to spend the post-mix coin, also leaks to Wasabi the information needed for Wasabi to redeem the Alice pre-mix coin.

Unfortunately I cannot give much details as I do not understand the math in detail, so here is the paper instead: https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf

If my understanding of the conclusion is correct, then essentially it does not require special script and can be implemented onchain by P2WPKH only.

[lontivero]

Thanks @ZmnSCPxj. I am going to read the material carefully very soon.

[cryptal]

I was also wondering if coinjoining would keep working after exiting Wasabi.

Until this feature is implemented, could Wasabi alert the user when exiting the app that coinjoning will stop?