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
159
160
161
162
163
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1WUwwH-0002RK-Qp
for bitcoin-development@lists.sourceforge.net;
Tue, 01 Apr 2014 11:33:09 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.213.43 as permitted sender)
client-ip=209.85.213.43; envelope-from=jgarzik@bitpay.com;
helo=mail-yh0-f43.google.com;
Received: from mail-yh0-f43.google.com ([209.85.213.43])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WUwwG-0000Y6-1t
for bitcoin-development@lists.sourceforge.net;
Tue, 01 Apr 2014 11:33:09 +0000
Received: by mail-yh0-f43.google.com with SMTP id b6so8814222yha.16
for <bitcoin-development@lists.sourceforge.net>;
Tue, 01 Apr 2014 04:33:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type:content-transfer-encoding;
bh=/3Mn+BGrnQobHyzzIKeasL5CZxBapVm/fbB+OW4/OK8=;
b=OG0b4cfvGB55V5YW4a7fqn+NrMeU5jZZHzNejfsQJxJGusrMIU3gkRA3Zyhn4doHAl
++36NDGI5wW0MUogAfFWrVZVq1WCZy6GTI++E6JEnl3ez/ASSz2OXXHub6zOtbXkQqdg
7c1q2JFeXYVo+tQdC5uaihpf2fxp1ZKn9ZtXXH5gHPvmACTmvX16lpiZ7y8+ITB+qfN+
OMTm668Lwa1SzLo2krV2U2pGxtmTsmLw44fPLhHgUWxDDL1mEXaB9tuQQjr3PmsqFgic
fovNHIO9Le95aOCssD3YvsDqEDp4d0eNdkfkCCyme3iofpWvTMv2Da/xPLkhf5AzkSyC
OeGw==
X-Gm-Message-State: ALoCoQnh/uRyI4A7GOdzFr5AW94+8AdP7q9FshHyg4uvT4HKHYpFU5GyC/ncWYKyuWTKTVsekRDp
X-Received: by 10.236.156.65 with SMTP id l41mr12609998yhk.9.1396351981948;
Tue, 01 Apr 2014 04:33:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.162.214 with HTTP; Tue, 1 Apr 2014 04:32:41 -0700 (PDT)
In-Reply-To: <51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
References: <5339418F.1050800@riseup.net>
<51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Tue, 1 Apr 2014 07:32:41 -0400
Message-ID: <CAJHLa0MfV0RnVh1niG4vUGUUvB_Vd8HccTys4bf1ApnwuBUd1g@mail.gmail.com>
To: "Chris D'Costa" <chris.dcosta@meek.io>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WUwwG-0000Y6-1t
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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: Tue, 01 Apr 2014 11:33:10 -0000
Re-reading this, even with the most recent message, is still isn't
clear _precisely_ how your technology works, or why it is better than
namecoin. User profiles (and distributed ledgers) need to reflect the
latest updates, and a stream of updates of over time is precisely what
bitcoin technology secures.
Keys expire or are compromised, and the public ledger needs to reflect
that. There is a lot of computer science involved in making sure the
public ledger you see is not an outdated view. A log-like stream of
changes is not the only way to do things, but other methods need less
hand-wavy details (show the code) before they are well recognized as
useful.
On Mon, Mar 31, 2014 at 7:14 AM, Chris D'Costa <chris.dcosta@meek.io> wrote=
:
> 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.
>
> I have yet to finish the paper but in a nutshell it uses a decentralised =
ledger of, what we refer to as, "device keys".
>
> 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 id=
entify 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 thin=
k it is this that would allow you to communicate a pay-to address to someon=
e without seeing them in a secure way.
>
> 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 sen=
se : advanced knowledge of all pubkeys. Indeed all devices could easily che=
ck their own record to identify problems on the ledger.
>
> There is of course more to this, but I like to refer to the "distributed =
ledger of device keys" as the "Web-of-trust re-imagined" although that isn'=
t strictly true.
>
> 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 lis=
t.
>
> Regards
>
> Chris D'Costa
>
>
>> On 31 Mar 2014, at 12:21, vv01f <vv01f@riseup.net> wrote:
>>
>> 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.
>>
>> Is that use case taken care of in any plans already?
>>
>> 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.
>>
>> [0] https://bitcointalk.org/index.php?topic=3D502538
>> [1] https://bitcointalk.org/index.php?topic=3D505095
>>
>> ------------------------------------------------------------------------=
------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> -------------------------------------------------------------------------=
-----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--=20
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
