From: Chris D'Costa <chris.dcosta@meek•io>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] secure assigned bitcoin address directory
Date: Tue, 1 Apr 2014 10:13:31 +0200 [thread overview]
Message-ID: <DBE4339F-0F27-4D18-91FC-4685E5AFB387@meek.io> (raw)
In-Reply-To: <20140331185751.GD59714@giles.gnomon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
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?".
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.
[-- Attachment #2: Type: text/html, Size: 2506 bytes --]
prev parent reply other threads:[~2014-04-01 8:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 10:21 vv01f
2014-03-31 10:49 ` Natanael
2014-03-31 11:14 ` Chris D'Costa
2014-03-31 11:46 ` Natanael
2014-03-31 16:53 ` Chris D'Costa
2014-04-01 11:32 ` Jeff Garzik
2014-04-01 12:20 ` Chris D'Costa
2014-04-01 18:16 ` Daryl Banttari
2014-04-01 22:26 ` Chris D'Costa
2014-04-02 0:59 ` Daryl Banttari
2014-04-02 5:16 ` Chris D'Costa
2014-04-02 12:01 ` Mike Hearn
2014-03-31 11:21 ` Peter Todd
2014-03-31 17:07 ` Jeff Garzik
2014-03-31 18:57 ` Roy Badami
2014-04-01 8:13 ` Chris D'Costa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DBE4339F-0F27-4D18-91FC-4685E5AFB387@meek.io \
--to=chris.dcosta@meek$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox