From: Chris Belcher <belcher@riseup•net>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services
Date: Sat, 13 Jun 2020 14:38:35 +0100 [thread overview]
Message-ID: <9a2e9ba4-1dda-e5bb-2587-bfe589d24c70@riseup.net> (raw)
In-Reply-To: <fQt0iIzsA5QprW64lX4SR1R78Aj6e-WqIgSMvk75mdiagQmAchIUqCpXzDjD4jPBhorg0i-oGlrYz7ot2xWMgJiha-eGFzl3PxbtZ-mbjSc=@protonmail.com>
Hello ZmnSCPxj,
On 11/06/2020 12:51, ZmnSCPxj wrote:
> Good morning Chris, and bitcoin-dev (but mostly Chris),
>
>
> I made a random comment regarding taint on bitcoin-dev recently: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html
>
>> For CoinSwap as well, we can consider that a CoinSwap server could make multiple CoinSwaps with various clients.
>> This leads to the CoinSwap server owning many small UTXOs, which it at some point aggregates into a large UTXO that it then uses to service more clients (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 in, to improve the privacy of its customers.
>
> Let us suppose that individual swaps use some variant of Succinct Atomic Swap.
> 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 round.
> T1 and T2 have some coins they want to swap.
> They arrange things all the way to confirmation of the Alice-side funding tx, and pause just before Bob creates its own funding tx for their individual 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 service multiple clients at the same time with a single transaction, i.e. batching.
> 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 elide 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 fictional 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 offer 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 that 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 transaction that a custodial service might produce.
>
> Now imagine more rounds, and I think you can begin to imagine that the magic 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 cost of transactions they produce, thus they are incentivized to use this technique to increase their profitability.
>
> At the same time, it spreads taint around and increases the effort that chain analysis must go through to identify what really happened.
>
> Regards,
> ZmnSCPxj
>
Would it be fair to summarize the idea in this way:
CoinSwappers can slow down the CoinSwap process which will give an
opportunity for makers to use batching.
next prev parent reply other threads:[~2020-06-13 13:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 11:51 ZmnSCPxj
2020-06-13 13:38 ` Chris Belcher [this message]
2020-06-13 14:06 ` ZmnSCPxj
2020-06-13 23:25 ` Chris Belcher
2020-07-17 6:02 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a2e9ba4-1dda-e5bb-2587-bfe589d24c70@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox