Return-Path: <ZmnSCPxj@protonmail.com> Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3007AC0733 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 17 Jul 2020 06:02:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 1BA4720395 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 17 Jul 2020 06:02:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4LJs9CXiwbU for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 17 Jul 2020 06:02:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by silver.osuosl.org (Postfix) with ESMTPS id 334FD2026D for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 17 Jul 2020 06:02:17 +0000 (UTC) Date: Fri, 17 Jul 2020 06:02:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1594965734; bh=5pEN8uO3ktlgeRRY9dw3v0cKBxK/ylIPacEc5QcZUtk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ArQjhQ/PYdJ6HDYhuN4iDSdQiG6rYM8B+cAFAGeXR/GOmUAgtPDLardsVyrEdLFOp d1WXc9SI/VC+7OKStlxWHuT6i4lFEaAFgjHT4K25X8gtFcfN+Wkj23r+mh+bKMUfJg MiSFfvaOA641cjslszDd3jftOMxekCHifL4Fgqv0= To: Chris Belcher <belcher@riseup.net> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <vXSbIZMHm9WBKOy0WpUVrvZdF2RDVeAsqGNTGzwq4LJV8NWz00nAKi7nNT_gsMuLCxMiI6AZ2zGxq0B75-asNbsHKs6gdCMpDRiE_j9mGIo=@protonmail.com> In-Reply-To: <c55d8195-fe1b-0b60-fee9-d3c69fec239c@riseup.net> References: <fQt0iIzsA5QprW64lX4SR1R78Aj6e-WqIgSMvk75mdiagQmAchIUqCpXzDjD4jPBhorg0i-oGlrYz7ot2xWMgJiha-eGFzl3PxbtZ-mbjSc=@protonmail.com> <9a2e9ba4-1dda-e5bb-2587-bfe589d24c70@riseup.net> <_I7GJG-KA7UpwUenI2qekxB8Ocut7i3oCAdBilv7VeycuUuflLEmJRakMCI9qCJkg3vfNW_0TZGRQOSO8EOL_mhq4Rvyb7q8LtML1-sxTdI=@protonmail.com> <c55d8195-fe1b-0b60-fee9-d3c69fec239c@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Fri, 17 Jul 2020 06:02:20 -0000 Good morning Chris, > On 13/06/2020 15:06, ZmnSCPxj wrote: > > > Good morning Chris, > > > > > 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. > > > > I think so. > > Regards, > > ZmnSCPxj > > It's definitely a good idea. As well as improving privacy by pretending > to be a service provider which uses batching, it may also be practical > just because CoinSwap takers will want to slow down the process for > greater privacy so that an adversary would have to search more of the > blockchain to attempt to deanonymize them. Also, by being prepared to > wait longer the takers will also save miner fees. Despite the subject title, I have realized belatedly that the same kind of = batching can be done by the taker as well. For example, the taker can contact two makers in parallel to setup separate= CoinSwaps with them. Then the taker produces a transaction spending its funds and sending them o= ut to two outputs. If the taker uses P2PKH for receiving and change, and we use (via 2p-ECDSA)= P2PKH 2-of-2 to anchor the swaps, then if both CoinSwap operations are suc= cessful, the transaction looks exactly like an ordinary pay-to-someone-and-= get-back-change transaction. Indeed, each of the two makers contacted, if they are not themselves collud= ing with each other, cannot really differentiate this from somebody doing a= CoinSwap only with them, since the other output is indistinguishable from = change. I am uncertain how much extra privacy (or cheapness) this buys the taker, h= owever. Regards, ZmnSCPxj