+Return-Path: <prayank@tutanota.de>

+Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id 8BCC9C016F

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 25 May 2020 12:16:14 +0000 (UTC)

+Received: from localhost (localhost [127.0.0.1])

+ by hemlock.osuosl.org (Postfix) with ESMTP id 7420A87DB0

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 25 May 2020 12:16:14 +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 D2L888nVBDGL

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 25 May 2020 12:16:12 +0000 (UTC)

+X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6

+Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])

+ by hemlock.osuosl.org (Postfix) with ESMTPS id 3BBDA87E25

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 25 May 2020 12:16:12 +0000 (UTC)

+Received: from w3.tutanota.de (unknown [192.168.1.164])

+ by w1.tutanota.de (Postfix) with ESMTP id 49302FA030C;

+ Mon, 25 May 2020 12:16:10 +0000 (UTC)

+DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1590408970;

+ s=s1; d=tutanota.de;

+ h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;

+ bh=lozN64Hv5f7rXzjG7cgvWqEZkX35gOCAjziA9MeXsII=;

+ b=XJhsgR4j1WIQ5DDLHu21Y/HbGp+f9N2izpmxIEhCM2Rl8gcc/nhE4DTzjhSSV+VS

+ l5e7MdebYH35ODa3ZRDxSmVGNJ1qdWrEsnBhgBqP0MihUbU/dYLTFMTVHoYhlI5ZdEp

+ qoS3mVryHJ2ybnnUrWTgk+yIyu2DyUdhF1CyMVcNJQw0qot7Cp62YzvAFUuCR68+4A1

+ iFjXgE24lqoYeBvgXgj+/XZvF8z/4yYKpkp9tftk7O+em19GWIsw3RearxJf4Eh5lSK

+ l6hN1JcG8BUK/5XVg8IwbG/MtRreMdv8IlCmlFGqIN+6XXW8F/dLC7BrLq0gPHigWVu

+ 7YMJGOlOUA==

+Date: Mon, 25 May 2020 14:16:10 +0200 (CEST)

+From: prayank@tutanota.de

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+Message-ID: <M8AkjX3--3-2@tutanota.de>

+In-Reply-To: <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com>

+References: <M87d6RV--3-2@tutanota.de>

+ <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com>

+MIME-Version: 1.0

+Content-Type: multipart/alternative;

+ boundary="----=_Part_95414_1402029184.1590408970272"

+X-Mailman-Approved-At: Mon, 25 May 2020 12:39:11 +0000

+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

+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 <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: Mon, 25 May 2020 12:16:14 -0000

+

+------=_Part_95414_1402029184.1590408970272

+Content-Type: text/plain; charset=UTF-8

+Content-Transfer-Encoding: quoted-printable

+

+Hello=C2=A0ZmnSCPxj,=20

+

+

+Thanks for the feedback.

+

+

+1. Peer 1 doesn't need to be a trusted third party, it can be implemented i=

+n a way that some peers involved in this system can provide liquidity for o=

+thers and incentives can be a small fee.

+

+2. Yes joinmarket is awesome and its payjoin will be better to achieve the =

+same but I was trying to contribute and add more options for people to impr=

+ove privacy on Bitcoin. If we have different ways to mix it will be harder =

+for spy companies to analyze of some of the transactions.

+

+3. Also one such setup might not make a huge difference but a chain of such=

+ 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 not=

+ the best person when it comes to coding but think that better privacy for =

+multisig will make it possible for lot of ideas to be implemented on Bitcoi=

+n using different multisig setups and combination of other things that we a=

+lready have.=C2=A0

+

+

+Prayank

+

+

+May 25, 2020, 12:24 by ZmnSCPxj@protonmail.com:

+

+> Good morning Prayank

+>

+>> I have explained the whole idea with a proof of concept in this link:=C2=

+=A0https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp=

+-e6ce1fdd57a1

+>>

+>

+> The article is not clear I think, so please confirm my understanding belo=

+w.

+>

+> Participants:

+>

+> * "Peer 3" - Payee

+> * "Peer 2" - Payer

+> * "Peer 1" - Enabling tr\*sted third party

+>

+> Goal: Payer wants to pay to the payee 0.006BTC

+>

+> Current Conditions:

+>

+> * Payer owns 0.01 BTC in a single UTXO

+> * Third Party owns 0.05 BTC in a single UTXO

+>

+> Protocol:

+>

+> 1. Payer and Third Party compute a 2-of-3 address with the public keys o=

+f Payer, Payee, and Third Party.

+> 2. Payer and Third Party individually pay their owned funds to the 2-of-=

+3 address.

+> 3. After confirmation, they consume the new outputs into another transac=

+tion with equal-valued outputs, hiding who owns which coins.

+>

+> Is my understanding correct?

+>

+> If so, I believe JoinMarket has a superior technology, which does not req=

+uire a tr\*sted third party; it simply requires one or more UNtrusted third=

+ parties to participate in signing a single transaction that does not requi=

+re paying to an intermediate m-of-n address (thus all inputs are singlesig)=

+.

+>

+> Basically JoinMarket allows the market taker to decide how much the equal=

+-value outputs are, and to define the address it goes to.

+> The destination address need not be one the market taker controls, it can=

+ be to a payee.

+> This technique is the only out-of-the-box way that a JoinMarket wallet ca=

+n spend funds from a JoinMarket wallet.

+>

+> JoinMarket as well already includes how to get in touch with enabling thi=

+rd parties (called "market makers").

+>

+>

+> Regards,

+> ZmnSCPxj

+>

+

+

+------=_Part_95414_1402029184.1590408970272

+Content-Type: text/html; charset=UTF-8

+Content-Transfer-Encoding: quoted-printable

+

+<html>

+ <head>

+ <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=

+">

+ </head>

+ <body>

+<div>Hello&nbsp;ZmnSCPxj, <br></div><div><br></div><div><br></div><div>Than=

+ks for the feedback.<br></div><div><br></div><div><br></div><div>1. Peer 1 =

+doesn't need to be a trusted third party, it can be implemented in a way th=

+at some peers involved in this system can provide liquidity for others and =

+incentives can be a small fee.<br></div><div><br></div><div>2. Yes joinmark=

+et is awesome and its payjoin will be better to achieve the same but I was =

+trying to contribute and add more options for people to improve privacy on =

+Bitcoin. If we have different ways to mix it will be harder for spy compani=

+es to analyze of some of the transactions.<br></div><div><br></div><div>3. =

+Also one such setup might not make a huge difference but a chain of such mi=

+xers will surely work better if everything done correctly.&nbsp;<br></div><=

+div><br></div><div>4. Maybe multisig usage is not ideal for such things rig=

+ht now and I am not the best person when it comes to coding but think that =

+better privacy for multisig will make it possible for lot of ideas to be im=

+plemented on Bitcoin using different multisig setups and combination of oth=

+er things that we already have.&nbsp;<br></div><div><br></div><div><br></di=

+v><div>Prayank</div><div><br></div><div><br></div><div><br></div><div>May 2=

+5, 2020, 12:24 by ZmnSCPxj@protonmail.com:<br></div><blockquote class=3D"tu=

+tanota_quote" style=3D"border-left: 1px solid #93A3B8; padding-left: 10px; =

+margin-left: 5px;"><div>Good morning Prayank<br></div><blockquote>I have ex=

+plained the whole idea with a proof of concept in this link:&nbsp;https://m=

+edium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a=

+1<br></blockquote><div><br></div><div>The article is not clear I think, so =

+please confirm my understanding below.<br></div><div><br></div><div>Partici=

+pants:<br></div><div><br></div><div>* "Peer 3" - Payee<br></div><div>* "Pee=

+r 2" - Payer<br></div><div>* "Peer 1" - Enabling tr\*sted third party<br></=

+div><div><br></div><div>Goal: Payer wants to pay to the payee 0.006BTC<br><=

+/div><div><br></div><div>Current Conditions:<br></div><div><br></div><div>*=

+ Payer owns 0.01 BTC in a single UTXO<br></div><div>* Third Party owns 0.05=

+ BTC in a single UTXO<br></div><div><br></div><div>Protocol:<br></div><div>=

+<br></div><div>1. Payer and Third Party compute a 2-of-3 address with the =

+public keys of Payer, Payee, and Third Party.<br></div><div>2. Payer and T=

+hird Party individually pay their owned funds to the 2-of-3 address.<br></d=

+iv><div>3. After confirmation, they consume the new outputs into another t=

+ransaction with equal-valued outputs, hiding who owns which coins.<br></div=

+><div><br></div><div>Is my understanding correct?<br></div><div><br></div><=

+div>If so, I believe JoinMarket has a superior technology, which does not r=

+equire a tr\*sted third party; it simply requires one or more UNtrusted thi=

+rd parties to participate in signing a single transaction that does not req=

+uire paying to an intermediate m-of-n address (thus all inputs are singlesi=

+g).<br></div><div><br></div><div>Basically JoinMarket allows the market tak=

+er to decide how much the equal-value outputs are, and to define the addres=

+s it goes to.<br></div><div>The destination address need not be one the mar=

+ket taker controls, it can be to a payee.<br></div><div>This technique is t=

+he only out-of-the-box way that a JoinMarket wallet can spend funds from a =

+JoinMarket wallet.<br></div><div><br></div><div>JoinMarket as well already =

+includes how to get in touch with enabling third parties (called "market ma=

+kers").<br></div><div><br></div><div><br></div><div>Regards,<br></div><div>=

+ZmnSCPxj<br></div></blockquote><div><br></div> </body>

+</html>

+

+------=_Part_95414_1402029184.1590408970272--

+