From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 250D5C016E for ; Wed, 3 Jun 2020 04:53:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 205CF8880C for ; Wed, 3 Jun 2020 04:53:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F+E5fN2xTND for ; Wed, 3 Jun 2020 04:53:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by hemlock.osuosl.org (Postfix) with ESMTPS id C040A887D1 for ; Wed, 3 Jun 2020 04:53:56 +0000 (UTC) Date: Wed, 03 Jun 2020 04:53:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1591160033; bh=uWHSL2zSVfDESPxmcnNI4XHkvEjyHLwWEJoz2/WPe2c=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=NXxGfmh2aaBhKg2mYqjU81xJzJPs8nctP83gFHUmHV0211gTCEGFpCaYiC8UMUFuJ rTBRf8rEOpz/yinyskLyRTeTk1NDIlV80xaWLrFDxsqo/rXct3mMjtiF9B0T1ga6Af F5YB2K1VuSsbA8o+J5WT4Yu4Q76nrhjpvsNVS0Dw= To: Chris Belcher , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com> In-Reply-To: References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility 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: Wed, 03 Jun 2020 04:53:59 -0000 Good morning Chris, > > Good morning Ruben and Chris, > > > I am not in fact convinced that PayJoin-with-CoinSwap adds that much pr= ivacy. > > These transactions: > > > > +---+ +---+ > > Alice ---| |--| |--- Bob > > Alice ---| | | | > > Bob ---| | +---+ > > +---+ > > > > > > Are not really much different in coin ownership analysis from these: > > > > +---+ +---+ > > Alice ---| |----| |--- Bob > > Alice ---| | +--| | > > +---+ | +---+ > > Bob ---------+ > > > > The main benefit of PayJoin-with-CoinSwap is it breaks the > common-input-ownership heuristic, which is a major widely used > heuristic. It would be a big win if that heuristic could be broken. > > PayJoin-with-CoinSwap would be useful if Alice is trying to recover some > privacy which was previously degraded, for example if she is spending > from a reused address or from an address linked to her identity. If she > does a PayJoin with the reused address then some other economic entity > would have his activity linked with Alice's. > > Just the fact that PayJoin-with-CoinSwap exists would improve privacy > for people who don't use it, for example if someone buys bitcoin from an > exchange that knows their identity and then co-spends it with other > coins they obtained another way. The fact that PayJoin exists means an > adversary cannot assume for sure that this user really owns that other > address which was co-spent. This doesn't apply for regular CoinSwap, > which only ever breaks the transaction graph heuristic, so in our > example the destination the coins are sent to would be uncertain, but > that the co-spent inputs are owned by the same person would be certain > in a world where PayJoin didn't exist. Alice can do PayJoin with a payee Carol that supports normal PayJoin, for s= imilar overall results. Though I suppose there is a mild advantage still with supporting it on the = funding tx of the first transaction, as you noted. > > But S6 has the mild advantage that all the funding transactions paying = to 2-of-2s can appear on the same block, whereas chaining swaps will have a= particular order of when the transactions appear onchain, which might be u= sed to derive the order of swaps. > > On the other hand, funds claiming in S6 is also ordered in time, so > someone paying attention to the mempool could guess as well the order of > swaps. > > I think this is wrong, and that it's possible for the funding > transactions of chained/routed swaps to all be in the same block as well. > > In CoinSwap it's possible to get DOS'd without the other side spending > money if you broadcast your funding transaction first and the other side > simply disappears. You'd get your money back but you have to waste time > and spend miner fees. The other side didn't spend money to do this, not > even miner fees. > > From the point of view of us as a maker in the route, we know we won't > get DOS'd like this for free if we only broadcast our funding > transaction once we've seen the other side's funding transaction being > broadcast first. This should work as long as the two transactions have a > similar fee rate. There might be an attack involving hash power: If the > other side has a small amount of hash power and mines only their funding > transaction in a manner similar to a finney attack, then our funding > transaction should get mined very soon afterwards by another miner and > the protocol will continue as normal. If the other side has knowledge of > the preimage and uses it to do CPFP and take the money, then we can > learn that preimage and do our own CPFP to get our money back too. How about RBF? A taker Alice can broadcast the funding tx spending its own funds. The funding tx spends funds controlled unilaterally by Alice. Alice can sign a replacement transaction for those funds, spending them to = an address with unilateral control, and making the funding tx output with a= ll the obligations attached never get confirmed in the first place. The chances may be small --- Bob can certainly monitor for Alice broadcasti= ng a replacement and counter-broadcast its own replacement --- but the risk= still exists. TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice c= ould arrange the replacement by other means, such as not using the RBF-enab= led flag, broadcasting the self-paying replacement near miner nodes, and br= oadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob full= node will then reject attempts to replace it, but miners will also reject t= he CoinSwap-expected funding tx and it will not confirm anyway. With the pre-SAS 4-tx setup, this potentially allows Alice to steal the fun= ds of Bob; after Alice gets its funding-tx-replacement confirmed together w= ith the Bob honest-funding-tx, Alice can use the contract transaction and p= ublish the preimage to take the Bob funds. Since the Alice-side funding tx has been replaced, knowledge of the hash pr= eimage will not help Bob any: the Alice funding tx has been replaced and Bo= b cannot use the preimage to claim it (it does not exist). With SAS Alice cannot outright steal the Bob funds, but the Bob funds will = now be locked in a 2-of-2 and Alice can take it hostage (either Bob gives u= p on the funds, i.e. donates its value to all HODLers, or Bob gives most of= the value to Alice). For the avoidance of theft, it is probably better for Bob to wait for Alice= -side funding tx to confirm, probably deeply because reorgs suck. This at least makes it costly to perform this attack; you have to lock more= of your funds longer in order to induce a competitor to lock its funds. Come to think of it, the same issue probably holds for S6 as well, the fund= ing tx with the longest timelock has to confirm first before the next is ev= en broadcast, bleah. > An interesting tangent could be to see if it's possible to make private > key handover work with S6. A nice side-effect of private key handover is > that the transfer of possession of the coins happens off-chain, so then > paying attention to the mempool won't help an adversary much. It certainly seems quite possible; each participant in S6 has a fixed "prev= ious" and "next" participant. Of course, this requires a secure tunnel, and my understanding of your plan= for SwapMarket is that the taker Alice serves as the broadcast medium betw= een all makers and itself. So, in an S6 sequence of Alice -> Bob1 -> Bob2 -> Alice, after Alice provid= es the preimage, Bob2 encrypts the private key being handed over in an asym= metric encryption that only Alice can open (e.g. using some known pubkey of= Alice, there are many to choose from), Bob1 similarly encrypts its privkey= for Bob2, and Alice encrypts the private key to Bob1, and Alice can then b= roadcast all those data to all participants, and only the correct participa= nt will be able to decrypt it. --- On another privacy-related note, S6 mildly leaks to each maker its position= in the route, via the timelocks. Each Bob has to know the timelocks it is offered and which it will offer to= the next participant, and the timelocks will be larger the further away th= at Bob is from the Alice taker. This is a mild privacy leak, one that seems unremovable to me. (It also exists in Lightning Network as well: we suggest the use of "shadow= routes" to artificially increase the distance of forwarding nodes, as a mi= tigation.) Regards, ZmnSCPxj