From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WUtpn-0006CB-Jo for bitcoin-development@lists.sourceforge.net; Tue, 01 Apr 2014 08:14:15 +0000 X-ACL-Warn: Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WUtpl-0001jy-Uh for bitcoin-development@lists.sourceforge.net; Tue, 01 Apr 2014 08:14:15 +0000 Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id B632BFB8DC for ; Tue, 1 Apr 2014 10:14:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id uizMaEOx1VCk for ; Tue, 1 Apr 2014 10:13:35 +0200 (CEST) X-Originating-IP: 94.224.235.124 Received: from 94-224-235-124.access.telenet.be (94-224-235-124.access.telenet.be [94.224.235.124]) (Authenticated sender: chris.dcosta@meek.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9C3A2FB8D5 for ; Tue, 1 Apr 2014 10:13:34 +0200 (CEST) From: Chris D'Costa Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2--726499229 Date: Tue, 1 Apr 2014 10:13:31 +0200 In-Reply-To: <20140331185751.GD59714@giles.gnomon.org.uk> To: Bitcoin Dev References: <5339418F.1050800@riseup.net> <20140331185751.GD59714@giles.gnomon.org.uk> Message-Id: X-Mailer: Apple Mail (2.1085) X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WUtpl-0001jy-Uh 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 08:14:15 -0000 --Apple-Mail-2--726499229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31 Mar 2014, at 20:57, Roy Badami wrote: > Is namecoin actively maintained these days? That's a very good quest. It was one of the reasons why we ruled out = namecoin, but not the only one. Although in principle it is a similar concept to namecoin + PGP, in = practice at least for our device, that felt like a hammer to crack a = nut, "How could this operate if the device was carried to one of the = non-3G countries i.e. with no direct internet access? How could we = syncronise the chain in a low bandwidth environment, if at all? Could at = least some of the chain be pre-loaded at the factory? What would the = risks be if it was?".=20 These are just a few of the practical considerations that we are = addressing, and our feeling is that when we can get the proposed = distributed ledger to work properly at "the lowest common denominator" = level, then everything above is easier.=20 On one other point, I don't ever see the Bitcoin software using a second = blockchain, like namecoin, in order just to provide safe communication = of a non-face-to-face, person-to-person, pay-to address (far too many = hyphens), but I do see some other standard emerging that provides the = equivalent of BIP70 for this use case. =20 In this context, when we posed these questions, "Why do we have to = provide a reward for a ledger of information? Why do we have to wait for = confirmation when no money is at risk? What is the worst that can happen = if your device key is discovered or replaced?", it did not make sense to = include all the incumbent coin stuff just to arrive at a distributed = ledger for a set of ultimately disposable keys.= --Apple-Mail-2--726499229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Is namecoin = actively maintained these = days?

That's a very good quest. = It was one of the reasons why we ruled out namecoin, but not the only = one.

Although in principle it is a similar concept to = namecoin + PGP, in practice at least for our device, that felt like a = hammer to crack a nut, "How could this operate if the device was carried = to one of the non-3G countries i.e. with no direct internet access? How = could we syncronise the chain in a low bandwidth environment, if at all? = Could at least some of the chain be pre-loaded at the factory? What = would the risks be if it was?". 

These are = just a few of the practical considerations that we are addressing, and = our feeling is that when we can get the proposed distributed ledger to = work properly at "the lowest common denominator" level, then everything = above is easier. 

On one other point, I = don't ever see the Bitcoin software using a second blockchain, like = namecoin, in order just to provide safe communication of a = non-face-to-face, person-to-person, pay-to address (far too many = hyphens), but I do see some other standard emerging that provides the = equivalent of BIP70 for this use case. =  

In this context, when we posed these = questions, "Why do we have to provide a reward for a ledger of = information? Why do we have to wait for confirmation when no money is at = risk? What is the worst that can happen if your device key is discovered = or replaced?", it did not make sense to include all the incumbent coin = stuff just to arrive at a distributed ledger for a set of ultimately = disposable keys.
= --Apple-Mail-2--726499229--