Date: Tue, 26 May 2020 02:46:07 +0000
To: "prayank@tutanota.de" <prayank@tutanota.de>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <jrsxyefXxsLMundu38HnLPf8f_SnedDldcopEiFUZj0A4rsdm6NtdkNQsI3fvUd34Nf2LcLt1vnv5aAJR2bmY4keM69Xsu0uoIng2ILh9t4=@protonmail.com>
In-Reply-To: <M8AkjX3--3-2@tutanota.de>
References: <M87d6RV--3-2@tutanota.de>
 <3K6kmk75oNFwNf_E4xqPgf5URJOf4c64Iyxi1HOgEpvvZrdn_wBWxbx3hRBEDfu2MjC5kF6N0ejpjqeG_5FTGIFD_45sFyhLCtMvhJNdq3E=@protonmail.com>
 <M8AkjX3--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

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