Date: Thu, 11 Jun 2020 11:51:03 +0000
To: Chris Belcher <belcher@riseup.net>,
 bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <fQt0iIzsA5QprW64lX4SR1R78Aj6e-WqIgSMvk75mdiagQmAchIUqCpXzDjD4jPBhorg0i-oGlrYz7ot2xWMgJiha-eGFzl3PxbtZ-mbjSc=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services
Precedence: list

Good morning Chris, and bitcoin-dev (but mostly Chris),


I made a random comment regarding taint on bitcoin-dev recently: https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html

> For CoinSwap as well, we can consider that a CoinSwap server could make m=
ultiple CoinSwaps with various clients.
> This leads to the CoinSwap server owning many small UTXOs, which it at so=
me point aggregates into a large UTXO that it then uses to service more cli=
ents (for example, it serves many small clients, then has to serve a single=
 large client that wants a single large UTXO for its own purposes).
> This aggregation again leads to spreading of taint.

I want to propose some particular behaviors a SwapMarket maker can engage i=
n, to improve the privacy of its customers.

Let us suppose that individual swaps use some variant of Succinct Atomic Sw=
ap.
Takers take on the role of Alice in the SAS description, makers take on the=
 role of Bob.
We may be able to tweak the SAS protocol or some of its parameters for our =
purposes.

Now, what we will do is to have the maker operate in rounds.

Suppose two takers, T1 and T2, contact the sole maker M in its first ever r=
ound.
T1 and T2 have some coins they want to swap.
They arrange things all the way to confirmation of the Alice-side funding t=
x, and pause just before Bob creates its own funding tx for their individua=
l swaps.
The chain now shows these txes/UTXOs:

     42 of T1 --->  42 of T1 & M
     50 of T2 --->  50 of T2 & M
    100 of T1 ---> 100 of T1 & M

    200 of M  -

Now the entire point of operating in rounds is precisely so that M can serv=
ice multiple clients at the same time with a single transaction, i.e. batch=
ing.
So now M provides its B-side tx and complete the SAS protocols with each of=
 the takers.
SAS gives unilateral control of the outputs directly to the takers, so we e=
lide the fact that they are really 2-of-2s below:

     42 of T1 --->  42 of T1 & M
     50 of T2 --->  50 of T2 & M
    100 of T1 ---> 100 of T1 & M

    200 of M  +-->  11 of M
              +--> 140 of T1
              +-->  49 of T2

(M extracted 1 unit from each incoming coin as fee; they also live in a fic=
tional universe where miners mine transactions out of the goodness of their=
 hearts.)
Now in fact the previous transactions are, after the SAS, solely owned by M=
 the maker.
Now suppose on the next round, we have 3 new takers, T3, T4, and T5, who of=
fer some coins to M to CoinSwap, leading to more blockchain data:

     42 of T1 --->  42 of T1 & M
     50 of T2 --->  50 of T2 & M
    100 of T1 ---> 100 of T1 & M

    200 of M  -+->  11 of M
               +-> 140 of T1
               +->  49 of T2

     22 of T3 --->  22 of T3 & M
     90 of T3 --->  90 of T3 & M
     11 of T4 --->  11 of T4 & M
     50 of T4 --->  50 of T4 & M
     20 of T5 --->  20 of T5 & M

In order to service all the new takers of this round, M takes the coins tha=
t it got from T1 and T2, and uses them to fund a new combined CoinSwap tx:

     42 of T1 --->  42 of T1 & M -+--+-> 110 of T3
     50 of T2 --->  50 of T2 & M -+  +->  59 of T4
    100 of T1 ---> 100 of T1 & M -+  +->  14 of T5
                                     +->   9 of M
    200 of M  -+->  11 of M
               +-> 140 of T1
               +->  49 of T2

     22 of T3 --->  22 of T3 & M
     90 of T3 --->  90 of T3 & M
     11 of T4 --->  11 of T4 & M
     50 of T4 --->  50 of T4 & M
     15 of T5 --->  15 of T5 & M

That transaction, we can observe, looks very much like a batched transactio=
n that a custodial service might produce.

Now imagine more rounds, and I think you can begin to imagine that the magi=
c of transaction batching, ported into SwapMarket, would help mitigate the =
blockchain size issues that CoinSwap has.

Makers are expected to adopt this technique as this reduces the overall cos=
t of transactions they produce, thus they are incentivized to use this tech=
nique to increase their profitability.

At the same time, it spreads taint around and increases the effort that cha=
in analysis must go through to identify what really happened.

Regards,
ZmnSCPxj