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
154
155
156
157
158
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <chris.dcosta@meek.io>) id 1WUfT1-0001Yh-9p
for bitcoin-development@lists.sourceforge.net;
Mon, 31 Mar 2014 16:53:47 +0000
X-ACL-Warn:
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WUfSz-0002RZ-Cb
for bitcoin-development@lists.sourceforge.net;
Mon, 31 Mar 2014 16:53:47 +0000
Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147])
by relay3-d.mail.gandi.net (Postfix) with ESMTP id EFCBBA80CB
for <bitcoin-development@lists.sourceforge.net>;
Mon, 31 Mar 2014 18:53:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195])
by mfilter19-d.gandi.net (mfilter19-d.gandi.net [10.0.15.180])
(amavisd-new, port 10024) with ESMTP id d-oao8WeWUyn
for <bitcoin-development@lists.sourceforge.net>;
Mon, 31 Mar 2014 18:53:37 +0200 (CEST)
X-Originating-IP: 94.224.236.133
Received: from [192.168.1.102] (94-224-236-133.access.telenet.be
[94.224.236.133]) (Authenticated sender: chris.dcosta@meek.io)
by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3F366A80D3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 31 Mar 2014 18:53:37 +0200 (CEST)
References: <5339418F.1050800@riseup.net>
<51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
<CAAt2M1-ACsJewKnhnPQqn8L7L54WzDyRAjfiGv7eB2LvL_p0Sw@mail.gmail.com>
From: Chris D'Costa <chris.dcosta@meek.io>
Content-Type: text/plain;
charset=us-ascii
X-Mailer: iPhone Mail (11B651)
In-Reply-To: <CAAt2M1-ACsJewKnhnPQqn8L7L54WzDyRAjfiGv7eB2LvL_p0Sw@mail.gmail.com>
Message-Id: <4304E924-B4B1-4B9B-B551-FC1B02777D5D@meek.io>
Date: Mon, 31 Mar 2014 18:53:34 +0200
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WUfSz-0002RZ-Cb
Subject: Re: [Bitcoin-development] secure assigned bitcoin address directory
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 16:53:47 -0000
The idea was not to register profiles or any human identity, or associate it=
with any other identity directly. Neither was it to have a massive BlockCha=
in, or use proof of work. In this case proof of work is detrimental to secur=
ity - you want as many people to know about your keys as quickly as possible=
. I want to add that this implies a shadow p2p network.
Also it's just a point if view, but I thought it better not to have any spec=
ific link to a person's identity, or their Bitcoin "identity" by which I mea=
n no connection to their public addresses. The device keys are not meant to b=
e a permanent identity or to store encrypted data either (think what happens=
if the device changes hands), so the use case is only to establish secure c=
ommunications, and to verify signatures whilst still in use by the owner. A n=
ew owner would need to establish a new device key - again this is in the det=
ails and probably more specific to the project.
Regards
Chris D'Costa
> On 31 Mar 2014, at 13:46, Natanael <natanael.l@gmail.com> wrote:
>=20
> This sounds like Namecoin. You can already register profiles with it,
> including keypairs. onename.io is a web-based client you can use to
> register on the Namecoin blockchain.
>=20
>> On Mon, Mar 31, 2014 at 1:14 PM, Chris D'Costa <chris.dcosta@meek.io> wro=
te:
>> Security of transmission of person-to-person pay-to addresses is one of t=
he use cases that we are addressing on our hardware wallet.
>>=20
>> I have yet to finish the paper but in a nutshell it uses a decentralised l=
edger of, what we refer to as, "device keys".
>>=20
>> These keys are not related in any way to the Bitcoin keys, (which is why I=
'm hesitating about discussing it here) neither do they even attempt to iden=
tify the human owner if the device. But they do have a specific use case and=
that is to provide "advanced knowledge" of a publickey that can be used for=
encrypting a message to an intended recipient, without the requirement for a=
third-party CA, and more importantly without prior dialogue. We think it is=
this that would allow you to communicate a pay-to address to someone withou=
t seeing them in a secure way.
>>=20
>> As I understand it the BlockChain uses "time" bought through proof of wor=
k to establish a version of the truth, we are using time in the reverse sens=
e : advanced knowledge of all pubkeys. Indeed all devices could easily check=
their own record to identify problems on the ledger.
>>=20
>> There is of course more to this, but I like to refer to the "distributed l=
edger of device keys" as the "Web-of-trust re-imagined" although that isn't s=
trictly true.
>>=20
>> Ok there you have it. The cat is out of the bag, feel free to give feedba=
ck, I have to finish the paper, apologies if it is not a topic for this list=
.
>>=20
>> Regards
>>=20
>> Chris D'Costa
>>=20
>>=20
>>> On 31 Mar 2014, at 12:21, vv01f <vv01f@riseup.net> wrote:
>>>=20
>>> Some users on bitcointalk[0] would like to have their vanity addresses
>>> available for others easily to find and verify the ownership over a kind=
>>> of WoT. Right now they sign their own addresses and quote them in the
>>> forums.
>>> As I pointed out there already the centralized storage in the forums is
>>> not secury anyhow and signed messages could be swapped easily with the
>>> next hack of the forums.
>>>=20
>>> Is that use case taken care of in any plans already?
>>>=20
>>> I thought about abusing pgp keyservers but that would suit for single
>>> vanity addresses only.
>>> It seems webfinger could be part of a solution where servers of a
>>> business can tell and proof you if a specific address is owned by them.
>>>=20
>>> [0] https://bitcointalk.org/index.php?topic=3D502538
>>> [1] https://bitcointalk.org/index.php?topic=3D505095
>>>=20
>>> ------------------------------------------------------------------------=
------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>=20
>> -------------------------------------------------------------------------=
-----
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
