From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 92296C016F for ; Thu, 11 Jun 2020 11:51:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 7BC388873A for ; Thu, 11 Jun 2020 11:51:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALQeZCWBhOB0 for ; Thu, 11 Jun 2020 11:51:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by whitealder.osuosl.org (Postfix) with ESMTPS id 55BF988736 for ; Thu, 11 Jun 2020 11:51:15 +0000 (UTC) Date: Thu, 11 Jun 2020 11:51:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591876272; bh=bssnrwZ+/FCBqtMDq7Aiw2C+wOs5z1ounJTBZbGUumk=; h=Date:To:From:Reply-To:Subject:From; b=Ebpth57f532FP8+VGBZHBfkWh2/+EaaBbfvitZfbRciiSHiXAhsGdT+c1KgjVZHnm uLxEkWlGgGo+Kqg8/I8c4SMs3TyhqLM/IxGYOLk0tyAzrH2MDBsLVKQIY8Y7mJDGug 8O4fAIMiQlJqQEliVT3jHn1h5rpuLlAPrIf3kN0I= To: Chris Belcher , bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 11:51:17 -0000 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