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
|
Return-Path: <belcher@riseup.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 02950C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 10:02:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id F3016408DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 10:02:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
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 MnjUTzeYjdz3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 10:02:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp4.osuosl.org (Postfix) with ESMTPS id A7B2E408C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 10:02:22 +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 mx1.riseup.net (Postfix) with ESMTPS id 4L04260CNBzDs7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 03:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1652436142; bh=8AKI4DByb4ZIXY0oz8jGIcuDqObaBoxiDMAm+MmwujA=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=lBMDT/vySc6asTYB7ceYgeRrZV767NKLZvpxL4+tKm6yUZ6JDPp6oBGvTmdHTQl7Z
MMgKuMRRzoWR7Rqa2DJ332B8IXS10idkVQzJxgSqCv53NuZJD2FTog7svXMfrIG4fK
EqFH5pSbZStG2Vu43bdOzsOwmO0+yhXqhcYfzH00=
X-Riseup-User-ID: 4721C70C8B1BCA3ADC9A128EE7EE69BE7014889A1E045EF000B6513D29AF13F7
Received: from [127.0.0.1] (localhost [127.0.0.1])
by fews2.riseup.net (Postfix) with ESMTPSA id 4L04254TDVz1y9N
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2022 03:02:21 -0700 (PDT)
Message-ID: <05fdc268-1701-cd62-181d-906b6b5d4f9d@riseup.net>
Date: Fri, 13 May 2022 11:02:20 +0100
MIME-Version: 1.0
Content-Language: en-US
To: 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>
From: Chris Belcher <belcher@riseup.net>
In-Reply-To: <PFBgbTn4_7JXQaRMlMjZDVrGBIr4OKfMK1ftW38cY-8Qu6tm_GllxDOWEj7K4zHkmQz9jA9NO_9rT_UzTSw9rr3RneEKTNhz826LmEIWF7w=@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: Fri, 13 May 2022 10:02:24 -0000
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".
Regarding fidelity bonds being used for both, I expect that most
fidelity bond owners will use their bonds with both Joinmarket and
Teleport, to not do that is just leaving money on the table.
If an attacker locks up the 100k btc or whatever the requirement is now,
and actually does a successful sybil attack against Joinmarket, then
they could at the same time do a successful sybil attack against
teleport with little added cost. So both markets form a single fidelity
bond ecosystem. This is a similar situation to merge-mining bitcoin with
an altcoin that also uses SHA256^2 for proof of work. The two or more
coins form one mining ecosystem. This results in the users of the small
altcoin benefiting from having their transactions protected by bitcoin's
massive hashrate. In this analogy the new small Teleport system can very
quickly benefit from the large amount of fidelity bonds already used in
Joinmarket.
Yes the hypothetical attacker can attack all systems at once, but the
defenders can defend all systems at once (and we can say not just that
they "can" do it, but that they "will" do it, or else they leave money
on the table). The mathematics which gives a huge advantage to the
defender still applies.
----
You've convinced me that specifying the exact form of the fidelity bond
certificate is a bad idea. I'll leave it more general, saying just that
wallets should be able to do SignMessage using the timelocked privkey.
And I'll leave the example signature in the test vectors.
I've made edits to this effect on the gist:
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e/revisions#diff-4f1f364f340b78bdfe9dca2ff50784bd312d49be220e5e5c2e4675447f79c6e8
It's worth noting that even if the certificate message is different
across the two systems, a fidelity bond owner can still create two
signatures over two different messages (e.g.
"fidelity-bond-cert|<pubkey>|<expiry>" and
"fidelity-bond-cert-teleport|<pubkey>|<expiry>").
|
