From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1WUxqz-00021Z-Se for bitcoin-development@lists.sourceforge.net; Tue, 01 Apr 2014 12:31:46 +0000 X-ACL-Warn: Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WUxqy-0004qG-2t for bitcoin-development@lists.sourceforge.net; Tue, 01 Apr 2014 12:31:45 +0000 Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D02FE17208C; Tue, 1 Apr 2014 14:31:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fMn391HOEhC1; Tue, 1 Apr 2014 14:31:36 +0200 (CEST) X-Originating-IP: 178.50.86.156 Received: from [10.53.22.156] (ptra-178-50-86-156.mobistar.be [178.50.86.156]) (Authenticated sender: chris.dcosta@meek.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id EDA96172089; Tue, 1 Apr 2014 14:31:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <5339418F.1050800@riseup.net> <51C10069-5C3B-462A-9184-669ABC6CD9D0@meek.io> From: Chris D'Costa Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Tue, 1 Apr 2014 14:20:37 +0200 To: Jeff Garzik X-Mailer: iPhone Mail (11B651) 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: 1WUxqy-0004qG-2t Cc: "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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:31:46 -0000 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 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 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 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/