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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.


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>
* While JoinMarket has *a* PayJoin implementation, what = I described in the previous email was not a PayJoin, it is standard CoinJoi= n where one of the equal-valued outputs is to the payee.
* I= n particular, PayJoin requires the cooperation of the payee, what I describ= ed does *not* require anything from the payee other than a destination addr= ess and an amount to pay.
* Your described technique (as I un= derstand it) is not too different from what JoinMarket already does for nor= mal sends, with the JoinMarket technique having the advantage that it works= with the current paradigm of "send payment to this address" without reconn= ecting to the payee.
The advantage you describe is largely h= ad only if the technique is significantly different.
For ins= tance, CoinSwap and CoinJoinXT are different enough from CoinJoin to be val= uable in this respect.
3. Also one such setup mig= ht not make a huge difference but a chain of such mixers will surely work b= etter if everything done correctly. 

4. M= aybe 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 mult= isig will make it possible for lot of ideas to be implemented on Bitcoin us= ing different multisig setups and combination of other things that we alrea= dy have.

Schnorr (which is introd= uced 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 so= me kind of setup (possibly untrusted I think, but I am not enough of a math= ist to describe this, in any case my base understanding is that the setup f= or m-of-n Schnorr requires a complex ritual involving a number of communica= tion rounds).
Taproot allows to hide explicit m-of-n in a scr= ipt behind some kind of n-of-n or m-of-m.

So m= ultisignature usage would automatically gain such advantage once Taproot ge= ts deployed.

In any case, if you are still int= erested in protocol design with some amount of focus on privacy, please con= sider reading this article as well: https://zmnscpxj.github.io/offchain/gen= eralized.html

What exactly is your goal here.<= br>

Regards,
ZmnSCPxj

------=_Part_148858_1297327866.1590497403804--