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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8C3FCC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 12:44:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 776B341832
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 12:44:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 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, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
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 atV6PdjgBj5d
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 12:44:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by smtp4.osuosl.org (Postfix) with ESMTPS id 6CC1641764
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 12:44:20 +0000 (UTC)
Date: Fri, 13 May 2022 12:44:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1652445857; x=1652705057;
bh=/SHOW1PGmWIk0bD2KCdkAJi5+MVVEUrXB4yxpdTD77Y=;
h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=OAWzR+yMbB/DjpXOhN8b2Cb+x3DwgunZIanVS6MGOcJ5WjGmmNbOXSk6hqwM965VV
5CK+4MKJpEwmjdLGw+LeV10WzkU1/m6ypDQZZXthvJ1bYA1Azb3a1DsxLtwGCXY5XN
2tI/+ua4qil3FKZMvXWezxyD+H/nc0dSXZte8/ZN4UfExXUpNm0p2aekQ4AyECMAZ5
2Vly0ro7Ocw1ls7AvSCqXdYt3bNK9mDRjw8K7/FEz+fQJS+XC30HTY4ViQ1PKP73nK
X6UkMI4DR1boHWDlNLoEtTSCZ3TSeZkByBv3EJWOrSbYpeeyvhZft2rvEQrusVl4Vs
Q7ecVf2P5O8tw==
To: Chris Belcher <belcher@riseup.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FiQ49v3gOISKrdhs08_rsoYj9pwwcLRvwXbXPgGV3ulDGW70Wsfk3AMAX1KpOByW3iTm_aQdi6tECdMmDcycl1qIM2KNlJz4DiHZ8omhT8U=@protonmail.com>
In-Reply-To: <05fdc268-1701-cd62-181d-906b6b5d4f9d@riseup.net>
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>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 13 May 2022 12:44:21 -0000
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 bon=
d between both Teleport and Joinmarket has a single identity in both system=
s.
Recall that not only makers can be secretly surveillors, but takers can als=
o be secretly surveillors.
Ideally, the maker should not tie its identity in one system to its identit=
y 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 JoinM=
arket 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 ident=
ify UTXOs of particular makers.
And it can perform attacks on both systems to identify the ownership of mak=
er coins in both systems.
Since the coins in one system are tied to that system, this increases the i=
nformation available to the surveillor: it is now able to associate coins i=
n 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
|
