From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 47B2BC016F for ; Tue, 26 May 2020 02:46:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 3566A85D72 for ; Tue, 26 May 2020 02:46:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlvzg3irSxQu for ; Tue, 26 May 2020 02:46:14 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 43FDF85D6C for ; Tue, 26 May 2020 02:46:14 +0000 (UTC) Date: Tue, 26 May 2020 02:46:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590461171; bh=fBEsXk0PYRbKCAiAYIVWOIXs73yIMKQuC78gZwjwKyA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=U7ZJdoMGQcEECVr+eCHMkHemghxkCpuKyhRU/I4OXsl6pFr/Yxcg0kYhHAObRns/r DxKlAm7sJk0Gqwm4H35a7fkVcj3eBkgXa6NgrDlcZrfz0/qopE7YOF+Eeqqiv637Vu W4gJLbbkFT3p/sxn3TJtzSulvx8IqxuGlysp5pF4= To: "prayank@tutanota.de" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet 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: Tue, 26 May 2020 02:46:16 -0000 Good morning Prayank, > 1. Peer 1 doesn't need to be a trusted third party, it can be implemented= in a way that some peers involved in this system can provide liquidity for= others and incentives can be a small fee. It is not clear in the article, but you mention using a 2-of-3, and show 3 = participants. It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the= funds coming from Peer 2, and split the funds of Peer 2 among them, withou= t getting input from Peer 2. That is the reason why I consider this tr\*sted --- Peer 2 has to trust Pee= r 1 does not collude with Peer 3 to steal the funds of Peer 2. Unless I have misunderstood your article, which is why I asked for clarific= ation. > 2. Yes joinmarket is awesome and its payjoin will be better to achieve th= e same but I was trying to contribute and add more options for people to im= prove privacy on Bitcoin. If we have different ways to mix it will be harde= r for spy companies to analyze of some of the transactions. * While JoinMarket has *a* PayJoin implementation, what I described in the = previous email was not a PayJoin, it is standard CoinJoin where one of the = equal-valued outputs is to the payee. * In particular, PayJoin requires the cooperation of the payee, what I de= scribed does *not* require anything from the payee other than a destination= address and an amount to pay. * Your described technique (as I understand it) is not too different from w= hat JoinMarket already does for normal sends, with the JoinMarket technique= having the advantage that it works with the current paradigm of "send paym= ent to this address" without reconnecting to the payee. The advantage you describe is largely had only if the technique is signif= icantly different. For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin = to be valuable in this respect. > 3. Also one such setup might not make a huge difference but a chain of su= ch mixers will surely work better if everything done correctly.=C2=A0 > > 4. Maybe multisig usage is not ideal for such things right now and I am n= ot the best person when it comes to coding but think that better privacy fo= r multisig will make it possible for lot of ideas to be implemented on Bitc= oin using different multisig setups and combination of other things that we= already have. Schnorr (which is introduced as a package deal with Taproot) already makes = all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden= m-of-n possible with some kind of setup (possibly untrusted I think, but I= am not enough of a mathist to describe this, in any case my base understan= ding is that the setup for m-of-n Schnorr requires a complex ritual involvi= ng a number of communication rounds). Taproot allows to hide explicit m-of-n in a script behind some kind of n-of= -n or m-of-m. So multisignature usage would automatically gain such advantage once Taproo= t gets deployed. In any case, if you are still interested in protocol design with some amoun= t of focus on privacy, please consider reading this article as well: https:= //zmnscpxj.github.io/offchain/generalized.html What exactly is your goal here. Regards, ZmnSCPxj