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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 66AB1C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Sep 2021 21:59:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 5434440215
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Sep 2021 21:59:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5
tests=[BAYES_50=0.8, 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, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id u3x9jpBIechm
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Sep 2021 21:59:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25])
by smtp2.osuosl.org (Postfix) with ESMTPS id 1125D400DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Sep 2021 21:59:29 +0000 (UTC)
Date: Wed, 29 Sep 2021 21:59:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1632952766;
bh=FBiQ88fTTjnGwzMqq9IcQH38T/oSTXmZbq6D7mReqUU=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=wCSE5ZyOwWUjO7sgAb6MQNfRt4GokbEjpwB+5fPlAVQbtkHlAzGNnBgIS2LTckwgk
dt+xfStJjXWh99gIXGO61OQcY58nJK+2x0/2MIsTuA2U/S9VaAm0un5jpHr7MpBPsk
Kh/nQ5vWNkX9g+HMxQ1CvTdY/BvohlDOsJzkZYWk=
To: trilemabtc <trilemabtc@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <W_italE75FlmiJhJiUXVVnk47tiBwHiesTwipmNXxZQNUy7flrixctwvag5kxIrLg-oVWbIn03WlTr1QEZXC_C5M0HZqzSCpMZK6wJ16kG0=@protonmail.com>
In-Reply-To: <ognT3T2_QMnYOMCKFtV2u36lMIQVYS_gai_YzjKY9I0BycsChp02oGg1vcRWIzBiIggr28ZT2YaNnPhOVRdfBLvl_L4-4lkCfyOnUeZSfoY=@protonmail.com>
References: <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@protonmail.com>
<ognT3T2_QMnYOMCKFtV2u36lMIQVYS_gai_YzjKY9I0BycsChp02oGg1vcRWIzBiIggr28ZT2YaNnPhOVRdfBLvl_L4-4lkCfyOnUeZSfoY=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of
creation)
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: Wed, 29 Sep 2021 21:59:31 -0000
Good morning trilemabtc,
> Hash: SHA256
>
> In search of more freedom, I thought of a hardwallet that makes the funds=
unseizable, using proof of creation (another step with key file), only the=
creator can reveal the private keys, more details about the idea can be fo=
und in the directory: https://github.com/trilemabtc/safedime I'm not a dev,=
but the concept is well defined and I believe that the elements to execute=
the project already exist. Hugs!
Comparing it to OpenDime is somewhat confusing, especially when you insist =
that creator is the only one who can reveal the privkey.
It seems to be more of the old saw of "what you have + what you know" i.e. =
"the correct way to 2-factor", where the device itself is the "what you hav=
e" and your "key file" is "what you know".
In particular: "Dime" is a kind of physical coin, and the point of physical=
coins is to transfer ownership of the coin to other people in exchange for=
goods and services; the device you describe sacrifices this transfer of ow=
nership due to the key file.
From what I can see, the basic idea is to generate a simple 2-of-2, possibl=
y by "just" combining the private key on the device plus a private key gene=
rated from the key file.
They can be simply added or multiplied together, I believe.
Then the device stores the key generated from the entropy you provide and e=
xposes a public key to the software.
Then the software generates a private key from the key file the user provid=
es and tweaks the device pubkey to generate the Bitcoin address.
In order to spend from that address, both the key file and the device have =
to be put together.
I believe that with multiplication of two privkeys, you can use 2p-ECDSA to=
even have the device provide a signature share that the software can combi=
ne with a signature share with the privkey from the keyfile, creating a sin=
glesig ECDSA signature.
This allows spending without having to enter revealed state.
The above allows the device to be configured with random entropy *separatel=
y* from the keyfile: when leaving "new unit" state it does *not* require th=
e key file to be given.
This is good since it reduces the possibility of malware getting access to =
both the entropy you feed to the device, and the key file, which would be a=
ble to reconstruct the final privkey and steal funds.
That is: have the entropy-giving stage ***not*** require the key file (and =
in particular, strongly recommend to do it on a computer that has never tou=
ched the key file).
This would be required anyway if you want to have "backups", i.e. separate =
device units with the same device privkey.
I also would not recommend or even mention the use of brainwallets, at all,=
even for keyfiles.
Unless you generated it with sufficient entropy (e.g. dice) and chant it ev=
ery day to yourself (to keep it fresh in your memory, assuming the user is =
human, anyway) the risk of loss with any kind of brainwallet is too high, e=
ven in a 2-of-2 with a hardware device.
Regards,
ZmnSCPxj
|
