Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9E856C016F for ; Sat, 13 Jun 2020 13:38:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9378B88A08 for ; Sat, 13 Jun 2020 13:38:38 +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 6LPgJF5lEQai for ; Sat, 13 Jun 2020 13:38:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by whitealder.osuosl.org (Postfix) with ESMTPS id DC82C88A06 for ; Sat, 13 Jun 2020 13:38:37 +0000 (UTC) Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 49kdwF4Qb3zFf2w; Sat, 13 Jun 2020 06:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1592055517; bh=kXAiN+n59KCdn0iRfNJTJmwznKwd69naK9v7bUb3iWs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QV5w3t3cimVVGNCi8tH2enribxfwVFQ4A5sH3Vl8D9hs0DlbSotrU2L7J7zic1cm/ SDJ6VwDFLtzSjorSaFboTQWk7Zi9fyk/ru4rqAoQqS8QEnT/jBCF6LTbHfzpAGo4lT vuzW/qJKjqHBkEzx4oSX4ObpRsiFkDt3m8wtoqi4= X-Riseup-User-ID: 51F33C5EAC855C1BF9A281562AA381D27251ACCE7953B6FCED2D9FFD3AD8C416 Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 49kdwD6FDpzJnd1; Sat, 13 Jun 2020 06:38:36 -0700 (PDT) To: ZmnSCPxj , bitcoin-dev References: From: Chris Belcher Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM 1aSoTg== Message-ID: <9a2e9ba4-1dda-e5bb-2587-bfe589d24c70@riseup.net> Date: Sat, 13 Jun 2020 14:38:35 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [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: Sat, 13 Jun 2020 13:38:38 -0000 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.