From pde at eff.org Tue Jan 10 13:48:33 2012 From: pde at eff.org (Peter Eckersley) Date: Tue, 10 Jan 2012 13:48:33 -0800 Subject: [Sovereign Keys] NameCoin In-Reply-To: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> References: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> Message-ID: <20120110214833.GB21163@xylophonic> BitCoin and the Sovereign Keys design share an important common component, which is a decentralised, append-only data structure. When I first told Ben Laurie about the SK idea, he went and wrote a paper arguing that a SK-like data structure would be a good way to implement digital currencies: http://www.links.org/files/distributed-currency.pdf The main advantages of the SK approach are: - no exposure to attacks by botnets that have more CPU than the legitimate users of the system - no need to do proof-of-work at all (it's wasteful!) - (as I understand it) the append-only data structure is significantly smaller; we aim to keep it smaller than 2TB for the forseeable future. One advantage of the BitCoin/NameCoin approach is that it doesn't have the 10-20 timeline servers. Although timeline servers aren't much of a security risk in the SK design, they /are/ an availability bottleneck. If someone could succeed in compromising all of them or DOSing most of them for an extended period, that would be pretty bad for SK clients. It seems to me that in practice BitCoin has come to depend on a bunch of important servers even though the protocol itself doesn't require it. So I'm not sure how big an advantage the lack of Timeline servers is for BC/NC. A solid advantage of BitCoin/NameCoin is that there is an implementation. We don't have one yet :) On Thu, Dec 29, 2011 at 09:03:28AM +0700, ??????? ???? wrote: > Hello! > > There is a project having something in common with Sovereign Keys. > > NameCoin is a distributed DNS or, more generally it's a > cryptocurrency with a built-in JSON storage. For instance, it can be > used to store GPG keys as well. It took me 3 month to mine 1 NMC on > CPU, and I can buy ~5 entries now. Pretty affordable, I think. Of > course, NMC can be bought, the price is low. Entries expire but > renewal is free. > > All the history of operations is available on every node. However, > merkle trees make it possible to omit detailed information in a > particular NameCoin implementation. > > NameCoin has a built-in SSL verification method: issue self-signed > certificate and store hash in the NameCoin blockchain. However, > browsers and other software are not modified to operate this way. > > I think NameCoin might be useful for Sovereign Keys as well. > NameCoin is also an append-only database and there are lots of nodes > around already. Timeline servers are still needed to ensure evidence > of control in the DNS. > > If there will ever be a browser supporting this feature, I'd like it > to support .bit native SSL verification method as well. .bit domain > owners are going to have first-class service. Conventional TLD > owners ought to rely on trusted 3rd party servers to verify evidence > of control. > > > P. S. Please mirror this mailing list in GMANE. It is inconvenient > to read from mail or web. NNTP is better. Even with regards to web, > GMANE interface is superior. > > -- > If you want to get to the top, you have to start at the bottom > > -- Peter Eckersley pde at eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From octagram at bluebottle.com Wed Jan 11 11:09:04 2012 From: octagram at bluebottle.com (=?KOI8-R?B?7MXXwdvF1yDp18HO?=) Date: Thu, 12 Jan 2012 02:09:04 +0700 Subject: [Sovereign Keys] NameCoin In-Reply-To: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> References: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> Message-ID: <403D85BE-8EA1-49DB-807E-9D1F6C9958C9@bluebottle.com> > The main advantages of the SK approach are: > > - no exposure to attacks by botnets that have more CPU than the > legitimate > users of the system Since the introduction of merged mining this is not a big issue. Major BTC mining pools have enabled merged mining at the moment. This makes NMC strong enough against freeze attacks. A project like SK can't live purely in a blockchain. As I've said, trusted timeline servers are still required to check usual TLD: whois and dns. > Although timeline servers aren't much of a security > risk in the SK design, they /are/ an availability bottleneck. If > someone > could succeed in compromising all of them or DOSing most of them > for an > extended period, that would be pretty bad for SK clients. Timeline servers cross-sign the certificates and these signatures go to NMC blockchain which is highly available. Something like this. I agree that standalone design makes sence, but redundancy will help a lot. Well, maybe let it be optional? -- If you want to get to the top, you have to start at the bottom From zooko at zooko.com Fri Jan 13 09:30:48 2012 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Fri, 13 Jan 2012 10:30:48 -0700 Subject: [Sovereign Keys] NameCoin In-Reply-To: <20120110214833.GB21163@xylophonic> References: <60399307-F7C1-4FDF-BBE7-BAF08550CABC@bluebottle.com> <20120110214833.GB21163@xylophonic> Message-ID: On Tue, Jan 10, 2012 at 2:48 PM, Peter Eckersley wrote: > > It seems to me that in practice BitCoin has come to depend on a bunch of important servers even though the protocol itself doesn't require it. Do you mean the servers operating the big mining pools? There exists an alternative (actually implemented and deployed) which would prevent such servers from performing rollback attacks: https://en.bitcoin.it/wiki/P2Pool It is plausible that this will eventually become larger than the traditional pools, since it also prevents the servers from stealing from their clients. > So I'm not sure how big an advantage the lack of Timeline servers is for BC/NC. If BC/NC has an advantage here, it is that it doesn't *require* Timeline servers, rather than that it doesn't *have* them. This is a useful distinction to make because maybe BC/NC could add Timeline servers in addition to its current longest-blockchain technique. (Precisely how to merge the two criteria, I don't know. For example, the rule could be "longest-blockchain unless a quorum of the timeline servers agree to switch to a shorter blockchain". There are probably better rules than that.) Conversely, of course, a future version of SK could add a proof-of-work system in addition to the quorum of Timeline servers. Regards, Zooko