.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*- .. -*- indent-tabs-mode: nil -*-
LAFS Tesla Coils & Corpses, 2014-08-08 ====================================== in attendance: Taylor, Zooko (scribe), Nathan Ripple consensus mechanism: ??? Zooko has heard second-hand that there has never been documentation of the consensus mechanism. Zooko assumes that it is effectively a simple federated-centralized mechanism, where there are a small number of special organizations, and everyone relies on that set of organizations for double-spend-protection. So it isn't really "decentralized" in the Bitcoin sense. (But it isn't a bad architecture, in Zooko's opinion! (Zooko got most of his opinions about Ripple from Andrew Miller.)) Nathan wants to back off from Bitcoin-style distributed consensus and consider whether there are other paths through the design space. So here's a nice narrowly-scoped section of the design space: there is a cryptoledger system in which people control private keys and can sign over some of their assets to other public keys, and there's only one ledger server. And we assume that it is partially corrupt in that would engage in rollback/replay/double-spend attack if it were profitable. Now, can we make it unprofitable? Nathan was frustrated with Ripple.com. There's a note that says "It will be open-sourced soon.". Nathan can't find actual protocol docs, etc. etc. Zooko says "I have a suggestion for you: stop looking at ripple.com; look at stellar.org.". Nathan looked at stellar.org and saw a github link at the top of the front page. He felt better. Then he found an actual API doc, and felt much better. I think there might have been a lot more discussion in this session, but I stopped taking notes and a week later when I looked back at it, I couldn't remember. Sorry! _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
