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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id CF7ABC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 19:28:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id BD9AA6106B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 19:28:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id MDMUxqqI9Pt4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 19:28:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22])
by smtp3.osuosl.org (Postfix) with ESMTPS id DF5B261047
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 19:28:13 +0000 (UTC)
Date: Tue, 10 May 2022 19:28:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail2; t=1652210891;
bh=tSKTIced7VBuXBciOzGSdlsWXGhfQcIbyrnvSqIT/Jw=;
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=qCnQDuYFeKsCsKbBIgCwwlkS0VwQ+h+Nd/Sg4ynlGvyWAZRUlRYt+RnVT5f6iL6+z
r1C9lIeANICpl5ob0I1Yv9fUeoSQKtWQP+T83EEEY+Vi2VZS0m9R+rTV0jkroEkEfY
Rj7HQXsxSJWbscx5+CbE8j1Fs9gna/SMXHK1EQbiR2LetaFYxrdYO9laPHUYuglTk/
5NHQ12VGFNybCzYt5dMve3sXmDkYUYdPBKVOU2J1MRErYY/V7Ld3NVHZ9/SCikM6rq
aNwE76yBcbqZq82ka6uW0bTHY1Aq284SATX1iimzhWykw7quBsjnOZMHu4DRedmRgf
37uuEUER7InRA==
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <PFBgbTn4_7JXQaRMlMjZDVrGBIr4OKfMK1ftW38cY-8Qu6tm_GllxDOWEj7K4zHkmQz9jA9NO_9rT_UzTSw9rr3RneEKTNhz826LmEIWF7w=@protonmail.com>
In-Reply-To: <6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@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>
<Xjq4gzy3me86tG6sYumDq16JE8EpRSnC90Ao-02Fyz3i55vRlLY7QKbW9TdaSJg8hiclxpBqhW93CtNgeCzVmbN3CDaW35P3BZwYp1o54H0=@protonmail.com>
<6IPqvNW2vQcHQLhUgSmQQLqtnV0RGrsUfnoUMKgv0SDQpVvKh7PIqJOKNazzgEzGE2W5OHHrlEtmg9lapjbiSjTpUuxqPmsiFua2P_ZN_FY=@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: Tue, 10 May 2022 19:29:34 +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: Tue, 10 May 2022 19:28:14 -0000
> I suppose ultimately this brings up the question of the scope of this BIP=
. The abstract points out that the BIP contains both a definition of addres=
s derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that t=
he 'Motivation' section gives motivation for standardisation of derivation =
(this includes things like time schedule), but not the second area - certif=
icate signing. I think the second area is much more tricky, but much more t=
o the point is, isn't it the case that that second area, can be interpreted=
without consensus between wallet developers? So say you were a hardware wa=
llet provider, or a "node in a box" provider - your customers want you to p=
rovide the ability move funds around, including e.g. moving funds out of an=
old Joinmarket wallet (in which say there is a now expired timelock addres=
s utxo) by just entering its BIP39 seed. If this BIP addresses that, it sho=
uld be enough.
>
> I don't doubt that there's gains to be had from a broader community discu=
ssing and agreeing the details of how to create a fidelity bond certificate=
, but it's a separate, and more difficult, task.
>
> Cheers,
> waxwing/AdamISZ
Further to that last point, as the BIP draft currently says:
" Almost all wallets implementing this standard can use their
already-existing "Sign Message" function to sign the certificate
message. As the certificate message itself is always an ascii string,
the wallet may not need to specially implement this section at all but
just rely on users copypasting their certificate message into the
already-existing "Sign Message" user interface. This works as long as
the wallet knows how to use the private key of the timelocked address
for signing messages."
So, isn't that an argument that we don't need to specify the certificate me=
ssage format here?
On the other hand, I can hardly disagree that it's worth presenting a kind =
of 'default' way of doing it. But I fear it is not at all simple to decide =
what a secure, general format should be (as per the discussion we started h=
aving here about domain separation tags).
Cheers,
waxwing/AdamISZ
|
