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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0607BC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 16:54:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E704182BC8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 16:54:40 +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: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 45CB8NHWiJCM
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 16:54:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27])
by smtp1.osuosl.org (Postfix) with ESMTPS id E572382B49
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 16:54:39 +0000 (UTC)
Date: Tue, 10 May 2022 16:54:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1652201677;
bh=nZD4DHTOXcN9vCcWyzcs1l54Lft31QeXe5FpXLkC8i4=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=QSb5tSlZhXYJfv4D83RpMaDpp3LX5FmYXw+19v1AkKiOeXAp1ARrcyzJ/p91pZ07H
z5CJIKM+DlXNnO1AVnsjIGeUzbTgTXF1iZc7nPSOxpN+1LcYgTd1YUbZWetIiystV5
bVy9buUNFq7gd6QVbaBRgvm+ei1l8SbkCcmU1UjHhgX5B0rzT0jKnvbEG3wKQRepKI
DTacXgSRKILkn9EochblASo5mAuCAUcDd2mE1+YbMyZrZs18bYInIBnuVFbW9Ye7O1
20likVu+1jggah37Q5DHKkqRxKAKOjrOCDtlfW4/M4lW5ZyHK5VR2m0DS5Q2xWs2Tm
6Stsyf1IPandw==
To: AdamISZ <AdamISZ@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com>
In-Reply-To: <dI-CkifjUyQssT-JzKmv09W6NggL89orF78qz1AOFlBL7Kmxo6z5BVBEr6aZha_nbnBQHFcN1hqC5EZM7lB0U0jiBtE3ZWCiIR_dGBJMsDA=@protonmail.com>
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>
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: Tue, 10 May 2022 16:54:41 -0000
Good morning waxwing,
> ------- Original Message -------
> On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev bitcoin-=
dev@lists.linuxfoundation.org wrote:
>
> > Hello ZmnSCPxj,
> > This is an intended feature. I'm thinking that the same fidelity bond
> > can be used to running a JoinMarket maker as well as a Teleport
> > (Coinswap) maker.
> > I don't believe it's abusable. It would be a problem if the same
> > fidelity bond is used by two makers in the same application, but
> > JoinMarket takers are already coded to check for this, and Teleport
> > takers will soon as well. Using the same bond across different
> > applications is fine.
> > Best,
> > CB
>
> Hi Chris, Zmn, list,
> I've noodled about this a few times in the past (especially when trying t=
o figure out an LSAG style ring sig based FB for privacy, but that does not=
seem workable), and I can't decide the right perspective on it.
>
> A user sacrifices X amount of time-value-of-money (henceforth TVOM) by co=
mmitting 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 think=
s 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 advanc=
e, 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.)
>
> As I mentioned in https://github.com/JoinMarket-Org/joinmarket-clientserv=
er/issues/993#issuecomment-1110784059 , I did wonder about domain separatio=
n tags because of this, and as I vaguely alluded to there, I'm really not s=
ure about it.
>
> If it was me I'd want to include domain separation via part of the signed=
message, since I don't see how it hurts? For scenarios where reuse is fine=
, reuse can still happen.
Ah, yes, now I remember.
I discussed this with Tamas as well in the past and that is why we conclude=
d that in defiads, each UTXO can host at most one advertisement at any one =
time.
In the case of defiads there would be a sequence counter where a higher-seq=
uenced advertisement would replace lower-sequenced advertisement, so you co=
uld update, but at any one time, for a defiads node, only one advertisement=
per UTXO could be used.
This assumed that there would be a defiads network with good gossip propaga=
tion so our thinking at the time was that a higher-sequenced advertisement =
would quickly replace lower-sequenced ones on the network.
But it is simpler if such replacement would not be needed, and you could th=
en commit to the advertisement directly on the UTXO via a tweak.
Each advertisement would also have a specific application ID that it applie=
d to, and applications on top of defiads would ask the local defiads node t=
o give it the ads that match a specific application ID, so a UTXO could onl=
y be used for one application at a time.
This would be equivalent to domain separation tags that waxwing mentions.
Regards,
ZmnSCPxj
|
