Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
References: <5339418F.1050800@riseup.net>
	<51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io>
	<CAJHLa0MfV0RnVh1niG4vUGUUvB_Vd8HccTys4bf1ApnwuBUd1g@mail.gmail.com>
From: Chris D'Costa <chris.dcosta@meek.io>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAJHLa0MfV0RnVh1niG4vUGUUvB_Vd8HccTys4bf1ApnwuBUd1g@mail.gmail.com>
Message-Id: <C818247C-6422-4F55-A324-826EC5C6A455@meek.io>
Date: Tue, 1 Apr 2014 14:20:37 +0200
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] secure assigned bitcoin address directory
Precedence: list

The code will be available as soon as we are ready, and apologies again for i=
t not being a more meaningful conversation - I did say I hesitated about pos=
ting it ;)

I think it is fair to say that we have not assumed anything about other tech=
nologies, without asking if they can answer all (not just some) of the quest=
ions I raised. I have yet to be convinced that anything existing meets those=
 requirements, namecoin included, hence why we are looking at creating an al=
ternative (non-coin by the way) but this alternative has some  of the import=
ant properties that the distributed ledger provides.

To answer the question about expiry, we're looking at something we'll call p=
roof-of-life for the device keys. In a nutshell on of the pieces of informat=
ion stored with the device public key will be a last heard from date - a dat=
e which is sent only by the device from time to time. Records that are expir=
ed are devices that have not been heard from for a given period (to be decid=
ed). As the device keys are not related to the Bitcoin keys it will be safe t=
o expire a device key by default. An expired device would require reinitiali=
sation, which would make a new device key set, a new proof of life date and t=
hen the Bitcoin keys (BIP32) can be restored.=20


Regards

Chris D'Costa

Sent from my iPhone

> On 1 Apr 2014, at 13:32, Jeff Garzik <jgarzik@bitpay.com> wrote:
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20
>> On Mon, Mar 31, 2014 at 7:14 AM, 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
>=20
>=20
>=20
> --=20
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/