summaryrefslogtreecommitdiff
path: root/b9/27665a8259f2913e31189716e4c33a7efd1781
blob: bd4b9a4901b13b0ad08475101323505acbb8d343 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 47B2BC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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" <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
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 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