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 6AECBC016F for ; Sun, 31 May 2020 02:31:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 58D4887FA4 for ; Sun, 31 May 2020 02:31:04 +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 Pu9kL7MQTTD0 for ; Sun, 31 May 2020 02:31:02 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 5B7C787E65 for ; Sun, 31 May 2020 02:31:02 +0000 (UTC) Date: Sun, 31 May 2020 02:30:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590892259; bh=VpJIAASVaHwxlDPd/GO9fvF/h/IoFWX7RG9oHI6B7C0=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=xdn/1rK0X3ey+6dODstIalZ8BuIYG32sY6p4NofoVLYYoaf/M/cmeXJHJNKkATD71 ybk2Qv2JTsgNU2W0hGWDJ/RNp37ZqY9M1fx7/2Bu7podcZdFCfE5PJXQ+quRwG7jYw muGWOMBLU2tIs0zBfhoBzgXzba8Vz7+9YPJS8zIc= To: Ruben Somsen , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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: Sun, 31 May 2020 02:31:04 -0000 Good morning Ruben and Chris, > >For a much greater anonymity set we can use 2-party ECDSA to create 2-of= -2 multisignature addresses that look the same as regular single-signature = addresses > > This may perhaps be counter-intuitive, but SAS doesn't actually require m= ultisig for one of the two outputs, so a single key will suffice. ECDSA is = a signing algorithm that doesn't support single key multisig (at least not = without 2p-ECDSA), but notice how for the non-timelocked SAS output we neve= r actually have to sign anything together with the other party. We swap one= of the two keys, and the final owner will create a signature completely on= their own. No multisig required, which means we can simply use MuSig, even= today without Schnorr. Just to be clear, you mean we can use the MuSig key-combination protocol fo= r the non-timelocked SAS output, but (of course) not the signing protocol w= hich is inherently Schnorr. Then knowledge of both of the original private keys is enough to derive the= single combined private key. > Of course the other output will still have to be a 2-of-2, for which you = rightly note 2p-ECDSA could be considered. It may also be interesting to co= mbine a swap with the opening of a Lightning channel. E.g. Alice and Bob wa= nt to open a channel with 1 BTC each, but Alice funds it in her entirety wi= th 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult t= o tell Bob entered the Lightning Network, especially if the channel is open= ed in a state that isn't perfectly balanced. And Alice will gain an uncorre= lated single key output. Dual-funding could be done by a single-funding Lightning open followed by a= n onchain-to-offchain swap. Though the onchain swap would have to be done, at least currently, with has= hes. > >=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D > > While it's probably clear how to do it on the timelocked side of SAS, I b= elieve PayJoin can also be applied to the non-timelocked side. This does re= quire adding a transaction that undoes the PayJoin in case the swap gets ab= orted, which means MuSig can't be used. Everything else stays the same: onl= y one tx if successful, and no timelock (=3D instant settlement). I can exp= lain it in detail, if it happens to catch your interest. I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much priv= acy. These transactions: +---+ +---+ Alice ---| |--| |--- Bob Alice ---| | | | Bob ---| | +---+ +---+ Are not really much different in coin ownership analysis from these: +---+ +---+ Alice ---| |----| |--- Bob Alice ---| | +--| | +---+ | +---+ Bob ---------+ The latter is possible due to private key handover, the intermediate output= becomes owned solely by Bob and Bob can add many more inputs to that secon= d transaction unilaterally for even greater confusion to chain analysis, ba= sically private key handover gets us PayJoin for free. It also removes the need for Bob to reveal additional UTXOs to Alice during= the swap protocol; yes PoDLE mitigates the privacy probing attack that Ali= ce can mount on Bob, but it is helpful to remember this is "only" a mitigat= ion. Now of course things are different if Alice is paying some exact amount to = Carol, and Alice wants to dissociate her funds from the payment. The difference is then: +---+ +---+ Alice ---| |----| |--- Bob Alice ---| |--+ | | Bob ---| | | +---+ +---+ +--------- Alice Change +---+ +---+ Bob ---| |----| |--- Carol | |--+ +---+ +---+ | +--------- Bob Change Versus: +---+ +---+ Alice ---| |----| |--- Bob Alice ---| | +--| | +---+ | +---+ Bob ---------+ +---+ +---+ Bob ---| |----| |--- Carol | |--+ | |--- Alice Change +---+ | +---+ +--------- Bob Change In the above, with PayJoin on the first-layer transaction, the Alice Change= is correlated with Alice and Bob inputs, whereas with the PayJoin on the s= econd the Alice change is correlated with Bob inputs and Carol outputs. But if Alice, using commodity CoinSwap wallets, always has a policy that al= l sends are via CoinSwap (a reasonable policy, similar to the policy in Joi= nMarket of ensuring that all spends out of the wallet are via CoinJoin), th= en the above two trees are not much different for Alice in practice. The Alice Change will be swapped with some other maker anyway when it gets = spent, so what it correlates with will not be much of a problem for Alice. At the same time, with PayJoin on the second-layer transaction (possible du= e to private key turnover, which is an inherent part of the SAS protocol): * Bob does not have to reveal any other coins it owns to Alice other than w= hat it is directly swapping, removing a privacy probe vector. * Bob can unilaterally combine more than one input to the second transactio= n going to Bob, which further increases the uncertainty of clustering aroun= d the inputs from Alice than just adding *one* input. --- A thing I have been trying to work out is whether SAS can be done with more= than one participant, like in [S6](https://joinmarket.me/blog/blog/multipa= rty-s6/). So far, I have not figured out a way to make it multiparty (multihop?). Because the secret being transported is a private key that protects a speci= fic UTXO, it seems it is not possible to safely use the same secret across = more than two parties. Perhaps others have come ideas? Regards, ZmnSCPxj