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
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 77462F30
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 13:59:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 745D08A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 13:59:20 +0000 (UTC)
Date: Thu, 08 Aug 2019 13:59:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565272757;
bh=Ti25AjaepT2xyFBaGN0i6ysw8gv7Sk07GVkmZOc2dUo=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=qqLKvP7EILWmTlbJhwEyM1958dV44ONdiQ9MG/2p0SsWF119m8glU98m+oYi5KM+v
Be3mRjTK9BURhxy1c/FORhVM8ys1c1EXwTLQAGgpK49gzS6J4Bgju/7cRv8Z0A5hao
En1EJYzVj9BHrUrP7HQ+8AEyHth9TZdxp9O5ppxQ=
To: Dmitry Petukhov <dp@simplexum.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ybzcv93zmtmV9rve96W4Sti2pip5WSqzMgDsCXUOB4nFSd3EIfZ7IEmVAQNeF7VTIEY9giHjX_Xisnw2h9lCp7ZzQ_jUT043pblf-jW_J3Q=@protonmail.com>
In-Reply-To: <20190808163750.57f4e620@simplexum.com>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
<ad501873-8912-765e-8df5-c9b0451fcd0a@riseup.net>
<20190807015541.3d8aa849@simplexum.com>
<20190807023742.73750ba3@simplexum.com>
<483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
<20190807201017.2a03b971@simplexum.com>
<jyEbDqD57bjrjd1QF72bLHmubrQxdc-WVqONP0gx-PjixLnQrLwWn9A2W_MkWwkTi_aJHSuUcLfxh2JnRp71110TtNNv8ZoDIhWAXFmuT5c=@protonmail.com>
<-6u9Ut_oYRThO21GIO1G8u4LpKavq2okw0Z7KoIM0tgwg4mAYXt2TP-SgiigMofdvLhvRuwX_q7Op6DUDM_eWUCjGmIEL_VTLpAeYDNOl5c=@protonmail.com>
<20190808163750.57f4e620@simplexum.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
attacks using fidelity bonds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 08 Aug 2019 13:59:21 -0000
Good morning Dmitry,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, August 8, 2019 7:37 PM, Dmitry Petukhov <dp@simplexum.com> wro=
te:
> =D0=92 Thu, 08 Aug 2019 09:35:24 +0000
> ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>
> > <MuSig(all participants except this participant)> OP_CHECKSIGVERIFY
> > <participant_snitch_key> OP_CHECKSIG
>
> This anti-snitch protection won't work if there are two snitches, which
> is concievable in the case of a large-scale consolidated bonds (one
> entity can pretend to be two independent entities with two different
> TXO). The snitch co-conspirator will refuse to sign the punishment
> transaction.
>
> If you change the MuSig(all_except_snitch) to 1-of-n multisig
> construction so that anyone other than the actual 'snitch' can
> confiscate the snitch-bond, then there's possibility that that a
> co-conspirator can get that bond before others - even before
> the sntich transaction is distributed to takers.
The correct way to do this, as with any offchain technique, is to have the =
punishment transactions signed by the MuSig-of-everyone-other-than-punishme=
nt-target before you even sign the funding transaction.
If consolidation is subsidized by paying rent out to the consolidators, the=
n the lessee of the UTXOs adds its rent payment in the same transaction tha=
t atomically instantiates the fidelity bond and all revocable bonds as a si=
ngle CoinJoined transaction.
If any participant refuses to sign the punishment transactions of their co-=
consolidators, then the lessee refuses to sign the funding transaction and =
nobody earns any rent and the lessee goes look for another set of UTXO owne=
rs (or just kicks out the participant who refuses to sign and lives with th=
e smaller fidelity bond, no big deal).
Of course, anyone renting consolidated bonds can themselves be unironic vic=
tims of sybil attackers who split up their funds to smaller parts so that t=
heir liability when later snitching is reduced, possibly to a level that is=
comfortable to them.
The sybil attacker then pretends to be lessors of UTXOs.
>
> It seems that to reasonably protect from more than one snitch with this
> punishment scheme, you want to make a multitude of taproot leaves where
> each leaf can be spent by cooperation of N entities, where N is the
> size of expected non-snitch participant set.
>
> > Finally, aggregation is still possible to insure by off-blockchain
> > agreements, possibly with legal consequences, and thus entities like
> > exchanges might still be able to aggregate funds and acquire an
> > undeservedly large weight in the fidelity bond system.
>
> This seems to me like the most immediate problem for the discussed
> system.
>
> Since the centralized exchanges or other custodial services already
> control TXOs of their customers who sent their funds there, they can
> use them to make extra profit with joinmarket, and create fidelity
> bonds out of these TXO with (or without) consent of the customers, and
> pay them (or not) the amount according to their UTXO, while getting the
> consolidation benefit of V^2 for themselves. It is also more probable
> that such centralized custodial services would be willing to
> participate in a deanonymization efforts, so that they can explain
> their participation in coinjoins to regulators.
Yes, down with the V^2 superlinearity, it is too strongly centralizing.
Regards,
ZmnSCPxj
|
