Prayank

May 2= 5, 2020, 12:24 by ZmnSCPxj@protonmail.com:

Good morning Prayank
I have ex= plained the whole idea with a proof of concept in this link: https://m= edium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a= 1

The article is not clear I think, so = please confirm my understanding below.

Partici= pants:

* "Peer 3" - Payee
* "Pee= r 2" - Payer
* "Peer 1" - Enabling tr\*sted third party

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

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 of Payer, Payee, and Third Party.
2. Payer and T= hird Party individually pay their owned funds to the 2-of-3 address.
3. After confirmation, they consume the new outputs into another t= ransaction with equal-valued outputs, hiding who owns which coins.

Is my understanding correct?

<= 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).

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.
The destination address need not be one the mar= ket taker controls, it can be to a payee.
This technique is t= he only out-of-the-box way that a JoinMarket wallet can spend funds from a = JoinMarket wallet.

JoinMarket as well already = includes how to get in touch with enabling third parties (called "market ma= kers").

Regards,
= ZmnSCPxj

------=_Part_95414_1402029184.1590408970272-- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 226E1C016F for ; Tue, 26 May 2020 12:50:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 5106922CC6 for ; Tue, 26 May 2020 12:50:16 +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 5Q4HtmrVasVs for ; Tue, 26 May 2020 12:50:07 +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 silver.osuosl.org (Postfix) with ESMTPS id 9F2AC20497 for ; Tue, 26 May 2020 12:50:06 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id C97C0FA03BE; Tue, 26 May 2020 12:50:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1590497403; 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=myCybCZg0r8QvIF912ergS+SZm6f3C4sN6xeC4lHbg4=; b=NhYkaI3jPPbEjaBsb/QCTbQ9Gz54UfL3UOFXmpHnYUciL4o2/YRaU92XPdj61sda bmd6aMWH7QIIXAFwNAd7GnHm8ftDiA0qGHT+E6tuLaQ0d1scRJ3gPnhZD+OyCzIxdFP qHLHxR/ghWei2m01TeOMSc1jpbGpYrFM3m4tvEBKrM+HoQjrn9LFNa6xrpyk9lVkyK3 lJvt4gta/4lzZcdOVmIcfg7f9xdkrQeFBWavRRVeezSm5QP9++fqcbOFudlC0lGVQMi BeWJbP30wk7wUqT9TJlyqOmhXrmkJSg1dLsneo7DUhKPIJDsriGx3BLRJsDi5m9VvZu gbM8SZj2yA== Date: Tue, 26 May 2020 14:50:03 +0200 (CEST) From: Prayank To: ZmnSCPxj Message-ID: In-Reply-To: References: <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_148858_1297327866.1590497403804" X-Mailman-Approved-At: Tue, 26 May 2020 13:04:58 +0000 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 12:50:17 -0000 ------=_Part_148858_1297327866.1590497403804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello=C2=A0ZmnSCPxj, Thanks for your response. The spending tx of multisig can be decided earlier and all three can review= the outputs involved in it. All 3 txs involved in the system if we conside= r only one mixer and not a chain will get confirmed in the same block as we= are using CPFP so child pays for 2 parent txs. However, disputes are possi= ble and to manage it we will have to make the system complex with things li= ke Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some othe= r incentives structure. Initially we can try to keep it simple and a way to= spend coins after coinjoin with the help of another person you trust. Yes, you described coinjoin in joinmarket but the problem I am trying to so= lve is: spend coins after coinjoin because post-mix usage is as important a= s coinjoin. Some users dont follow the best practices after coinjoin and it= makes coinjoin useless or less effective in that case and sometimes for ot= hers involved in the process as well. Samourai has few options for users to do this and one of them is: Stonewall= x2 which is a mini coinjoin and similar to what I was trying with this idea= . End goal is to create more options for users to spend UTXOs easily in diffe= rent ways after coinjoin which makes it difficult for people trying to anal= yze transactions or algorithms monitoring, flagging, reporting txs 24/7 Its just an idea for now and maybe I might find better ways to solve this p= roblem once I start working on it. For me it makes sense to experiment with= things and provide more options for users but I wanted to see what others = think about it who are more experienced and skilled to develop bitcoin rela= ted projects. Thanks for this link:=C2=A0https://zmnscpxj.github.io/offchain/generalized.= html=C2=A0 Looks interesting. Prayank May 26, 2020, 08:16 by ZmnSCPxj@protonmail.com: > Good morning Prayank, > > >> 1. Peer 1 doesn't need to be a trusted third party, it can be implemente= d in a way that some peers involved in this system can provide liquidity fo= r 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 t= he funds coming from Peer 2, and split the funds of Peer 2 among them, with= out getting input from Peer 2. > > That is the reason why I consider this tr\*sted --- Peer 2 has to trust P= eer 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 clarif= ication. > >> 2. Yes joinmarket is awesome and its payjoin will be better to achieve t= he same but I was trying to contribute and add more options for people to i= mprove privacy on Bitcoin. If we have different ways to mix it will be hard= er for spy companies to analyze of some of the transactions. >> > > * While JoinMarket has *a* PayJoin implementation, what I described in th= e previous email was not a PayJoin, it is standard CoinJoin where one of th= e equal-valued outputs is to the payee. > * In particular, PayJoin requires the cooperation of the payee, what I d= escribed does *not* require anything from the payee other than a destinatio= n address and an amount to pay. > * Your described technique (as I understand it) is not too different from= what JoinMarket already does for normal sends, with the JoinMarket techniq= ue having the advantage that it works with the current paradigm of "send pa= yment to this address" without reconnecting to the payee. > The advantage you describe is largely had only if the technique is signi= ficantly 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 s= uch 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 f= or multisig will make it possible for lot of ideas to be implemented on Bit= coin using different multisig setups and combination of other things that w= e already have. >> > > Schnorr (which is introduced as a package deal with Taproot) already make= s all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidd= en 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 underst= anding is that the setup for m-of-n Schnorr requires a complex ritual invol= ving 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 Tapr= oot gets deployed. > > In any case, if you are still interested in protocol design with some amo= unt of focus on privacy, please consider reading this article as well: http= s://zmnscpxj.github.io/offchain/generalized.html > > What exactly is your goal here. > > Regards, > ZmnSCPxj > ------=_Part_148858_1297327866.1590497403804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello ZmnSCPxj,

Thank= s for your response.

The spending tx of mul= tisig can be decided earlier and all three can review the outputs involved = in it. All 3 txs involved in the system if we consider only one mixer and n= ot a chain will get confirmed in the same block as we are using CPFP so chi= ld pays for 2 parent txs. However, disputes are possible and to manage it w= e will have to make the system complex with things like Peer 1 locking some= amount in a 2 of 2 multisig with Peer 2 or some other incentives structure= . Initially we can try to keep it simple and a way to spend coins after coi= njoin with the help of another person you trust.
Yes, you descr= ibed coinjoin in joinmarket but the problem I am trying to solve is: spend = coins after coinjoin because post-mix usage is as important as coinjoin. So= me users dont follow the best practices after coinjoin and it makes coinjoi= n useless or less effective in that case and sometimes for others involved = in the process as well.
Samourai has few options for users to d= o this and one of them is: Stonewallx2 which is a mini coinjoin and similar= to what I was trying with this idea.
End goal is to create mor= e options for users to spend UTXOs easily in different ways after coinjoin = which makes it difficult for people trying to analyze transactions or algor= ithms monitoring, flagging, reporting txs 24/7

Its just a= n idea for now and maybe I might find better ways to solve this problem onc= e I start working on it. For me it makes sense to experiment with things an= d provide more options for users but I wanted to see what others think abou= t it who are more experienced and skilled to develop bitcoin related projec= ts.

Thanks for this link: https://zmnscpxj.github.io/of= fchain/generalized.html

Looks intere= sting.

Prayank

May 26, 2020, 08:16 by ZmnSCPxj@protonmail.com:

Good morning Prayank,

<= /div>
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 provid= e liquidity for others and incentives can be a small fee.
<= div>
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 a= nd Peer 3 (2-of-3) can simply sign to spend the funds coming from Peer 2, a= nd split the funds of Peer 2 among them, without getting input from Peer 2.=

That is the reason why I consider this tr\*st= ed --- Peer 2 has to trust Peer 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 clarification.
= 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.
<= div>