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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <belcher@riseup.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 38E65C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 May 2022 09:13:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 1E7764099B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 May 2022 09:13:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=riseup.net
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Iug_J-xaRPqo
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 May 2022 09:13:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6])
by smtp4.osuosl.org (Postfix) with ESMTPS id B99CF40942
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 15 May 2022 09:13:43 +0000 (UTC)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "mail.riseup.net", Issuer "R3" (not verified))
by mx0.riseup.net (Postfix) with ESMTPS id 4L1Gs26Qxjz9tDC;
Sun, 15 May 2022 02:13:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1652606023; bh=keG6zyvdtFSG+GAjcAcBziuiK4/1tWjKbLd5K4JvgjM=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=Asmr0iZgAeCR2CKQRZsv0UAJgCIKyCC2I04Xy4ga5jL6NU3b9oo7QmGPCVQ6VkDrk
tN7GpTbdI9kpIKK9E67I8mYu+6BXv+irK/fM+/UEeqz4srMEdqCemJAHaqnpA6/dF8
qFkfNef6pIZQ5xUbppNy4Use3uD5vBYTI9I2+ouM=
X-Riseup-User-ID: 2C3EC3AB5AF811B56F8A59910C9DCED70A79D68F2CD50D0BE85EAC3705C11B7E
Received: from [127.0.0.1] (localhost [127.0.0.1])
by fews2.riseup.net (Postfix) with ESMTPSA id 4L1Gs168ljz1yBZ;
Sun, 15 May 2022 02:13:41 -0700 (PDT)
Message-ID: <f4dc955f-4cae-bc4f-7d85-ec2ae1fcf546@riseup.net>
Date: Sun, 15 May 2022 10:13:39 +0100
MIME-Version: 1.0
Content-Language: en-US
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <22c80504-e648-e021-866e-ca5a5db3b247@riseup.net>
<bsOJ-OnnA4FutVmPqtg1xY-k0notwX4OqqIpdMsymXR9-KnS2iXGUE8o7kDVeYBMCqAX0v3oEAmiVMhUIB25gupx6l_bLff2_CNsLK_sk-U=@protonmail.com>
<82948428-29a3-e50a-a54a-520a83f39bba@riseup.net>
<dI-CkifjUyQssT-JzKmv09W6NggL89orF78qz1AOFlBL7Kmxo6z5BVBEr6aZha_nbnBQHFcN1hqC5EZM7lB0U0jiBtE3ZWCiIR_dGBJMsDA=@protonmail.com>
<Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com>
<6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@protonmail.com>
<PFBgbTn4_7JXQaRMlMjZDVrGBIr4OKfMK1ftW38cY-8Qu6tm_GllxDOWEj7K4zHkmQz9jA9NO_9rT_UzTSw9rr3RneEKTNhz826LmEIWF7w=@protonmail.com>
<05fdc268-1701-cd62-181d-906b6b5d4f9d@riseup.net>
<FiQ49v3gOISKrdhs08_rsoYj9pwwcLRvwXbXPgGV3ulDGW70Wsfk3AMAX1KpOByW3iTm_aQdi6tECdMmDcycl1qIM2KNlJz4DiHZ8omhT8U=@protonmail.com>
From: Chris Belcher <belcher@riseup.net>
In-Reply-To: <FiQ49v3gOISKrdhs08_rsoYj9pwwcLRvwXbXPgGV3ulDGW70Wsfk3AMAX1KpOByW3iTm_aQdi6tECdMmDcycl1qIM2KNlJz4DiHZ8omhT8U=@protonmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond
for BIP39 seeds
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: Sun, 15 May 2022 09:13:48 -0000
Hello ZmnSCPxj,
You say "A taker can be a surveillor as well", as though that's simple
and easy to achieve. In reality there are many defenses against that.
Defending against the attack of a malicious taker aborting at the last
step is the purpose of the podle commitments which joinmarket has
implemented since 2016. This was in response to this attack actually
taking place. Another important point is that this attack cant happen
secretly, it is very obvious to everyone operating a maker that it
happens. The podle defense means that an attacker doing this will
constantly have to spend money on miner fees to create new UTXOs. Here's
a writeup with links to other blog posts about the whole thing:
https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b
As well as podle as mitigation, the multiple mixdepths in the joinmarket
wallet also helps a lot because it's not trivial for an attacker to
actually learn all the UTXOs in all 5 mixdepths, which is necessary for
the attack to work.
Mitigation in Teleport works in a slightly different way: takers can
only see UTXOs or transactions belonging to the maker once they have
already gotten their own transaction confirmed. So if they were to abort
the protocol early they would not only have spent miner fees but also
waste their own time waiting for the OP_CSV timeout.
It's worth remembering that the fidelity bond UTXOs are not linked to
any resulting coinjoin or coinswaps on-chain.
Yes linking the two identities (joinmarket maker and teleport maker)
together slightly degrades privacy, but that has to be balanced against
the privacy loss of leaving both systems open to sybil attacks. Without
fidelity bonds the two systems can be sybil attacked just by using about
five-figures USD, and the attack can get these coins back at any time
when they're finished.
Regards
CB
On 13/05/2022 13:44, ZmnSCPxj wrote:
> Good morning Chris,
>
>> Hello waxwing,
>>
>>> A user sacrifices X amount of time-value-of-money (henceforth TVOM)
>>
>> by committing in Joinmarket with FB1. He then uses the same FB1 in
>> Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket,
>> and benefit Z in Teleport, then presumably he'll only do it if
>> (probabilistically) he thinks Y+Z > X.
>>
>>> But as an assessor of FB1 in Joinmarket, I don't know if it's also
>>
>> being used for Teleport, and more importantly, if it's being used
>> somewhere else I'm not even aware of. Now I'm not an economist I admit,
>> so I might not be intuit-ing this situation right, but it fees to me
>> like the right answer is "It's fine for a closed system, but not an open
>> one." (i.e. if the set of possible usages is not something that all
>> participants have fixed in advance, then there is an effective Sybilling
>> problem, like I'm, as an assessor, thinking that sacrificed value 100 is
>> there, whereas actually it's only 15, or whatever.)
>>
>>
>> I don't entirely agree with this. The value of the sacrifice doesn't
>> change if the fidelity bond owner starts using it for Teleport as well
>> as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run
>> any maker at all the sacrifice would still be 100, because it only
>> depends on the bitcoin value and locktime. In your equation Y+Z > X,
>>
>> using a fidelity bond for more applications increases the
>> left-hand-side, while the right-hand-side X remains the same. As
>> protection from a sybil attack is calculated using only X, it makes no
>> difference what Y and Z are, the takers can still always calculate that
>> "to sybil attack the coinjoin I'm about to make, it costs A btc locked
>> up for B time".
>
> I think another perspective here is that a maker with a single fidelity bond between both Teleport and Joinmarket has a single identity in both systems.
>
> Recall that not only makers can be secretly surveillors, but takers can also be secretly surveillors.
>
> Ideally, the maker should not tie its identity in one system to its identity in another system, as that degrades the privacy of the maker as well.
>
> And the privacy of the maker is the basis of the privacy of its takers.
> It is the privacy of the coins the maker offers, that is being purchased by the takers.
>
>
> A taker can be a surveillor as well, and because the identity between JoinMarket and Teleport is tied via the single shared fidelity bond, a taker can perform partial-protocol attacks (i.e. aborting at the last step) to identify UTXOs of particular makers.
> And it can perform attacks on both systems to identify the ownership of maker coins in both systems.
>
> Since the coins in one system are tied to that system, this increases the information available to the surveillor: it is now able to associate coins in JoinMarket with coins in Teleport, via the shared fidelity bond identity.
> It would be acceptable for both systems to share an identity if coins were shared between the JoinMarket and Teleport maker clients, but at that point they would arguably be a single system, not two separate systems, and that is what you should work towards.
>
>
> Regards,
> ZmnSCPxj
|
