path: root/7a/6e89d42560971c1dee714c418dfda958696bdd

Return-Path: <prayank@tutanota.de>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 226E1C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <prayank@tutanota.de>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <M8G151E--3-2@tutanota.de>
In-Reply-To: <jrsxyefXxsLMundu38HnLPf8f_SnedDldcopEiFUZj0A4rsdm6NtdkNQsI3fvUd34Nf2LcLt1vnv5aAJR2bmY4keM69Xsu0uoIng2ILh9t4=@protonmail.com>
References: <M87d6RV--3-2@tutanota.de>
 <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com>
 <M8AkjX3--3-2@tutanota.de>
 <jrsxyefXxsLMundu38HnLPf8f_SnedDldcopEiFUZj0A4rsdm6NtdkNQsI3fvUd34Nf2LcLt1vnv5aAJR2bmY4keM69Xsu0uoIng2ILh9t4=@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 <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: 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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div><br></div><div>Hello&nbsp;ZmnSCPxj,<br></div><div><br></div><div>Thank=
s for your response.<br></div><div><br></div><ol><li>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.<br></li><li>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.<br></li><li>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.<br></li><li>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<br></li></ol><div>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.</div><div><br></div><div>Thanks for this link:&nbsp;<a href=3D"https://=
zmnscpxj.github.io/offchain/generalized.html">https://zmnscpxj.github.io/of=
fchain/generalized.html</a>&nbsp;<br></div><div><br></div><div>Looks intere=
sting.</div><div><br></div><div>Prayank</div><div><br></div><div><br></div>=
<div>May 26, 2020, 08:16 by ZmnSCPxj@protonmail.com:<br></div><blockquote c=
lass=3D"tutanota_quote" style=3D"border-left: 1px solid #93A3B8; padding-le=
ft: 10px; margin-left: 5px;"><div>Good morning Prayank,<br></div><div><br><=
/div><blockquote>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.<br></blockquote><=
div><br></div><div>It is not clear in the article, but you mention using a =
2-of-3, and show 3 participants.<br></div><div>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.=
<br></div><div><br></div><div>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.<br></div><div><br></div><div>Unless I have misunderstood =
your article, which is why I asked for clarification.<br></div><blockquote>=
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.<br></blockquote><=
div><br></div><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.<br></div><div> * 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.<br></div><div>* 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.<br></div><div> The advantage you describe is largely h=
ad only if the technique is significantly different.<br></div><div> For ins=
tance, CoinSwap and CoinJoinXT are different enough from CoinJoin to be val=
uable in this respect.<br></div><blockquote><div>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.&nbsp;<br></div><div><br></div><div>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.<br></div></blockquote><div><br></div><div>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).<br></div><div>Taproot allows to hide explicit m-of-n in a scr=
ipt behind some kind of n-of-n or m-of-m.<br></div><div><br></div><div>So m=
ultisignature usage would automatically gain such advantage once Taproot ge=
ts deployed.<br></div><div><br></div><div>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<br></div><div><br></div><div>What exactly is your goal here.<=
br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blo=
ckquote><div><br></div>  </body>
</html>

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