Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

From: Chris Belcher <belcher@riseup•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Date: Tue, 28 Apr 2020 14:03:36 +0100	[thread overview]
Message-ID: <0e1c0287-617c-976c-9fd4-16683881d5d5@riseup.net> (raw)
In-Reply-To: <-_xRcjb8H_0Bck71k4VkeukEBgHT-03ikLTIdyTG2P0rt0T_mvN4b4FejmWobwnAUCGNaDpFQlPc3TMwlml1gjnZ1lwSumeEYQpXSyijND0=@protonmail.com>

On 24/04/2020 02:34, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Germán,
> 
> 
>> With regards to trying to tackle the problem of value-based correlations, wouldn't it be possible to try to model the solution after the equal-sum-subset problem (np complete problem)( https://www.cs.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf  )? 
>> That is, a pair of individuals with a set of UTXOs that both add up to similar if not equal value perform a swap of similar-(total)value sets. In this way the values of the UTXOs can be broken up essentially at random (following some nominal distribution so that it doesn't stand out; e.g. https://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction and decorrelated by using different keys + randomized locktimes.
> 
> There are a number of issues to simply modeling this to the subset-sum problem.
> 
> * There is a practical limit to the number of UTXOs you would be willing to receive in the swap.
>   * Every UTXO you receive increases the potential fee you have to pay to spend them, meaning you would strongly dislike receiving 100 UTXOs that sum up to 1mBTC.
>   * Thus, a practical blockchain analyst can bound the size of the sets involved, and the problem becomes less than NP in practice.
> * If you have a single UTXO and split it, then swap, anyone looking at the history can conjecture that the split involved is part of a CoinSwap.
>   * The split is now a hint on how the subset sums can be tried.
> * If after the CoinSwap you spend the UTXOs you received in a single transaction, then you just published the solution to the subset sum for your adversary.
>   * This ties in even further to the "practical limit on the number of UTXOs".
>     * Because it is not safe to spend the UTXOs from a single CoinSwap together, you want to have fewer, larger UTXOs for more flexibility in spending later.
> 
> I believe belcher and waxwing and nopara73 have been working far longer on privacy tech, and you should try to get in contact with them as well, they may know of other issues (or solutions to the above problems).
> 
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Hello list,

A couple of thoughts on multi-transaction coinswaps:

* Users should never split up a single UTXO before doing a coinswap,
instead they should send the one UTXO to a coinswap address and get back
multiple UTXOs.

For example, this 1-to-3 TXO coinswap (The symbol ----> means bitcoin
transaction).

    AliceA (10 BTC) ----> CoinSwap AddressA ----> BobA (10 BTC)

    BobB (3 BTC) ----> CoinSwap AddressB ----> AliceB (6 BTC)
    BobC (2 BTC) ----> CoinSwap AddressC ----> AliceC (3 BTC)
    BobD (5 BTC) ----> CoinSwap AddressD ----> AliceD (1 BTC)

Note that the Bob-to-Alice set of transactions add up to 10 BTC, the
entire CoinSwap is swapping the same amount.

Or written another way:

    Alice TXO (10 BTC) ----> Coinswap Protocol ----> Alice TXO1 (6 BTC)
                                               ----> Alice TXO2 (3 BTC)
                                               ----> Alice TXO3 (1 BTC)

This kind of thing could also be used for consolidation of many UTXOs
without necessarily leaking information that the same person owns them.
For example, if Alice owns 5 UTXOs:

    Alice TXO1 ----> Coinswap Protocol ----> Alice TXO
    Alice TXO2 ---->
    Alice TXO3 ---->
    Alice TXO4 ---->
    Alice TXO5 ---->

* It's helpful if any CoinSwap app is actually used for spending rather
than just mixing back to yourself. That will help avoid the problem of
users inadvertently co-spending all their coinswap outputs in the same
transaction.
An example of Alice paying for a VPN anonymously:

    Alice TXO (10 BTC) ---> Coinswap Protocol ---> VPN Payment (0.1 BTC)
                                              ---> Change1 (6 BTC)
                                              ---> Change2 (3 BTC)
                                              ---> Change3 (0.9 BTC)

In this case Alice will never accidentally merge all her TXOs together,
because the VPN Payment TXO doesn't belong to her. Also this could
improve privacy because unlike in normal transaction the VPN provider
might not be able to figure out the lower bound of Alice's balance (10
BTC in this case).

* Multi-transaction CoinSwaps aren't truly an example of a subset-sum
problem, but "sparse subset sum", a related and easier problem.

The way its normally formulated, subset sum is about finding a subset
that adds up to a target value. But in multi-transaction coinswap
there'd only be three or four CoinSwap outputs, so the problem is
finding just three or four integers in a big set that add up to the target.

You could think of it mathematically that the n-choose-k function is
near-polynomial when k is near 0 or near n, and the function is
exponential when k is near n/2.

A more promising way to build privacy is to create a situation where an
adversary would find a huge amount of false positives which are very
close the amount being sent. So even if the adversary has enough
computational power to iterate all the amounts it won't help them much
due to the huge number of false positives.

Regards
CB