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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id ED6BEC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 May 2022 21:36:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id CAF6241909
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 May 2022 21:36:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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 (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 G2gfUY43lC8a
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 May 2022 21:36:16 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
[185.70.40.134])
by smtp4.osuosl.org (Postfix) with ESMTPS id A20D6418FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 May 2022 21:36:16 +0000 (UTC)
Date: Sat, 21 May 2022 21:36:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1653168974; x=1653428174;
bh=wkT1e1CEfy5tAJT3REj/mDnO1/BjUQ0ZkRz0G+mEFkM=;
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=qk+zVPZjfI7x+qy/WKSS3sgpEsGclmMEsyiAm5Aj6vokR/IzzuvJlmeOlhiskiMnE
1+h+2DfR0r6hMevxuBzzH05iJYXcqG0aIOOAAQ5PyQ3eUx4YFd8y928fJ/dewPACiY
lfOh8l87b2b2va4vDCc+i8CyHZ8MYNHQyqrWlVtLTLDWectJ2Y9rjreg0GCOZdviDx
vbHIqy35dDIVi7niQBPncC3J3yqXZrbI08vKFvLhWqBKqoTWCg1vY/fhuOFgQTt1Oh
j2/i+PRHSy4sIDaKU7w+f6Zrbpczjy3RuC6efLeleHLvXM9YFNDUFkghBaH3JNWUlH
MY00IcEbWhdGQ==
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <olCBTQ6jYBZcIxtLRZP32QmJrLF4j9jfzR5SSXwwUJp-J85H3usIGmNaWT5DIQV9DnuDEl9Noo9nEJ593dpgqipSRAwGkggCB0eHZhuD6nI=@protonmail.com>
In-Reply-To: <tG19tbinpV6rx5WtwbP3fIilB3lvJvhoUSpj6eJIw5VKWykeG72TErCvF1ZzVotiLsat0iosK2xdomXMppDK2AzTUe864tQIg5hz4fSuJvw=@protonmail.com>
References: <f3892570-6c45-47ee-2804-9988ff18bdf5@riseup.net>
<48D4B621-D862-4031-AE43-3F54D34FB0B5@voskuil.org>
<ipHZZpEipF7oliIh-RlPP2e6rcWkIFW22jEOwaCPIfJUuoDh4JfmzvGC2i7tZK-kT0o0osyxFyWxZKDRZOWI_dqdSWNWOLR7KpN3CsN6BRE=@protonmail.com>
<01c401d86a5c$956ddbd0$c0499370$@voskuil.org>
<01d901d86a64$452ef9d0$cf8ced70$@voskuil.org>
<tG19tbinpV6rx5WtwbP3fIilB3lvJvhoUSpj6eJIw5VKWykeG72TErCvF1ZzVotiLsat0iosK2xdomXMppDK2AzTUe864tQIg5hz4fSuJvw=@protonmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 22 May 2022 14:29:01 +0000
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: Sat, 21 May 2022 21:36:18 -0000
> > > As a better analogy: I am borrowing a piece of gold, smelting it down=
to make
> > > a nice shiny advertisement "I am totally not a bot!!", then at the en=
d of the
> > > lease period, re-smelting it back and returning to you the same gold =
piece
> > > (with the exact same atoms constituting it), plus an interest from my=
business,
> > > which gained customers because of the shiny gold advertisement claimi=
ng "I
> > > am totally not a bot!!".
> > >
> > > That you use the same piece of gold for money does not preclude me us=
ing
> > > the gold for something else of economic value, like making a nice shi=
ny
> > > advertisement, so I think your analysis fails there.
> > > Otherwise, your analysis is on point, but analyses something else ent=
irely.
Back to this analogy, I think it's imprecise in a way that's important to n=
ot overlook: you cannot re-use the same gold atoms in two different adverti=
sements. Use of a fidelity bond, being basically a signature, is completely=
'non-rivalrous' as I think the economists say.
> Yes, that is why Tamas switched to defiads, as I had convinced him that i=
t would be similar enough without actually being a covenant scam like you d=
escribed.
>
> > In any case, I tend to agree with your other posts on the subject. For =
the burn to be provably non-dilutable it must be a cost provably associated=
to the scenario which relies upon the cost. This provides the global uniqu=
eness constraint (under cryptographic assumptions of difficulty).
>
>
> Indeed.
> I suspect the only reason it is not yet a problem with existing JoinMarke=
t and Teleport is simply that no convenient software currently exists which=
allows the same bond to be used by both, thus making it safe in practice b=
ut not in theory.
> But the theory implies that if somebody does make such software, effectiv=
ely both systems will become joined as effectively only a single identity e=
xists in both systems.
> This may not be a problem either since the intent is that Teleport will o=
bsolete JoinMarket someday, but if other applications start using the same =
scheme without requiring a commitment to a specific application, this may a=
lso effectively render Teleport less useful as well.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
So, general comment: it seems like both you and Eric agree with my uncertai=
n intuition up-thread and therefore do we all agree that the correct soluti=
on (to whatever extent there is one) is something like domain separation ta=
gs, as we discussed earlier? It's still a matter of social consensus: if ap=
pending "JM" to the end of a certificate signature is intended to mean that=
this fidelity bond can only be used in Joinmarket and not anywhere else, w=
ell we can only as individual users demand that (i.e. *I* might not accept =
it in Teleport, but what if Fred down the street does? It's not enough for =
me to rely on my own criteria!), and more subtly, it makes sense only if we=
all have an unambiguous definition of what Joinmarket *is* - ironically it=
is precisely the thing brought most into question by the achievement of re=
al decentralization in a system.
Cheers,
waxwing/AdamISZ
|
