Where should we first see Stellar deployed in a major way?
Stripe? ( https://stripe.com/blog/stellar )
What significant application of Stellar do they have?
Stellar Consensus Protocol: Proof and Code
81–90 of 99 posts
Re: Stellar Consensus Protocol: Proof and Code
#82Earlier quoted context omitted.
At it's core, the question of whom to trust is of course crucial, as there are clearly at least straw-man answers that have undesirable effects. But the trust topology affects more than safety, it affects the scenarios in which a consensus protocol is useful. E.g., if I issue some scrip and trade it on the Stellar network, I don't necessarily want to depend on mining rigs in other parts of the world for my ledger saf…
> I don't necessarily want to depend on mining rigs Indeed, the security model provided by Bitcoin consensus system may not be fit for any particular purpose. But it has one, and so we can think about it and decide what purposes it may or may not be fit for, and think about under what conditions it will be safe or not safe. > is to leave such policy questions up to the market and see what kind of architecture emerges…
You're saying "how do we know that that quora will sufficiently overlap?". David seems to be saying "how do we know they won't?". At this point, I think just about everyone can agree that the security depends on a set of empirical assumptions that we currently simply do not know how they will play out into the real world. So my plan at least is to simply sit back and see how it actually ends up evolving in real life; if it fails, the Stellar Foundation was centralized enough to temporarily take back the reins for itself the last time, so I don't see why it can't do it again.
That said, my _prediction_ is that it will work fine mostly, occasionally there will be concerns about people splitting off into islands, and a resulting second-order consequence is that people will start putting the Stellar equivalent of blockchain.info onto their trust list in order to ensure connectivity to the "main graph" (I had actually cited The Tyranny of Structurelessness in my own responses already :) ), and this will just have to be the social-network-consensus version of the GHash.io scare and we'll be fighting against people's private interests to be lazy to reduce the risk of that happening.
Re: Stellar Consensus Protocol: Proof and Code
#83Earlier quoted context omitted.
In Bitcoin we can make a pretty concrete statement about computing power that one can reason about; the blocking attacker will not be successful without a majority of it. Whats the similar statement for 'trust' which is sufficient for security? Obviously "attacker is partitioned from the network" is sufficient, but not very plausable. I'm sure there is a better statement possible, but its not clear to me what it is.
Why wouldn't this be plausible? Let's say one day China had enough of Bitcoin, and used their essentially limitless resources to gain enough hashing power at will, to block transactions or rewrite them or what have you. Entirely plausible with Bitcoin (in this case, China doesn't care about the coin reward and therefore is not a "rational attacker" as the popular game theoretic model of Bitcoin security presupposes).…
> Let's say one day China had enough of Bitcoin, and used their essentially limitless resources to gain enough hashing power at will, to block transactions or rewrite them or what have you. Entirely plausible with Bitcoin
That's the Maginot Line attack, at Tim Swanson calls it. The more realistic attack is that China just hacks into five data centers and serves a warrant to another ten. An interesting property of the PoW incentive structure is that there is actually fairly little incentive to protect oneself against hacks, so I would not be surprised if it was fairly easy.
> By hacking enough organizations to take control of their nodes?
The key point in Stellar consensus is that even if enough nodes are hacked, then users can just stop trusting them and switch to other nodes, and so the network would "route around" the damage. With Bitcoin PoW, there's no way to exclude an attacker from participating; you have to accept their work just as much as everyone else's.
Re: Stellar Consensus Protocol: Proof and Code
#84I'm excited for the ideas here and have been following Stellar. But I'm hugely disappointed to see that they went with C and C++ for their new core codebase. This is the kind of code that needs strong safety, security, and correctness guarantees, and here in 2015 we have several mature languages with better safety & correctness guarantees. C# and Java are both mature and mainstream, and either would have been a sane…
I'm not sure I'd call Java for systems programming is a "sane" choice, but ok! I think with a very modern C++ approach and very careful coding you can rock out. Yeah not everyone has this, but the losses from using Java is just so huge!
A consensus algorithm targeted for use in a globally distributed OLTP is hardly "systems programming".
Re: Stellar Consensus Protocol: Proof and Code
#85Earlier quoted context omitted.
Why wouldn't this be plausible? Let's say one day China had enough of Bitcoin, and used their essentially limitless resources to gain enough hashing power at will, to block transactions or rewrite them or what have you. Entirely plausible with Bitcoin (in this case, China doesn't care about the coin reward and therefore is not a "rational attacker" as the popular game theoretic model of Bitcoin security presupposes).…
> Let's say one day China had enough of Bitcoin, and used their essentially limitless resources to gain enough hashing power at will, to block transactions or rewrite them or what have you. Entirely plausible with Bitcoin That's the Maginot Line attack, at Tim Swanson calls it. The more realistic attack is that China just hacks into five data centers and serves a warrant to another ten. An interesting property of the…
Maginot Line attack, I like that. And yep, that's basically the point I've been trying to make in my posts. IMO Bitcoin isn't "trustless" - you need to implicitly trust those with hashing power aren't colluding to screw you.
Re: Stellar Consensus Protocol: Proof and Code
#86Earlier quoted context omitted.
> I don't necessarily want to depend on mining rigs Indeed, the security model provided by Bitcoin consensus system may not be fit for any particular purpose. But it has one, and so we can think about it and decide what purposes it may or may not be fit for, and think about under what conditions it will be safe or not safe. > is to leave such policy questions up to the market and see what kind of architecture emerges…
I'm out of my league here technically, but I'm having a hard time seeing how your critiques don't apply to the entire market economy just as well. The collective actions of all participants result in an effective price model, the causes of which are unknown to any of its participants and likely unknowable to any one human mind, and which changes over time in ways that are highly opaque. In the market at large, partic…
Markets are frequently manipulated and distorted, they fail and fault and such.
But they're not keeping consensus ledgers for limited supply cryptocurrencies. Any of these failures or faults can allow a coin to be spent twice (or other mutually excluded transaction) with parties that have different views of the system, the result-- and any transaction which is casually depended on the conflict-- can never be part of a common system.
So it's like someone manipulates the market economy to convince you to buy a cheeseburger most other parties think they sold to someone else, and now your hand cannot interact with your neighbor's door because your hand contains atoms that-- as far as your neighbor's door is concerned-- aren't part of your hand but are instead part of my foot.
Markets are a tool. They have their applications and limitations, building the security of a cryptocurrency in an adversarial environment out of them sounds like a plan for failure. No less than using a cryptosystem in a place where you really needed a market may not give great results.
But you don't have to take my word for it, the prior consensus model in Stellar _already_ faulted, all on its own when, the requirement for the trust topology was violated. This fault wasn't a surprise, I (and others) called it out years before-- but the vulnerability of the system was publicly ignored by Stellar's creators while they ran Ripple and Stellar's advisers (including Mazieres, who was an adviser listed on the Stellar site on day one) even as they facilitated the sale of their ripple-reboot asset to the general public. It was not acknowledged until it knocked their system out. The improved consensus may better confines the failure domain, but retains the property that the safety of the consensus is largely external and depends on particular topological constraints without a procedure that provides any assurance the constraints are likely to be met.
Another response to me argues that it will probably be fine; but this flys in the face of reason. The same property existed before and it demonstratively wasn't fine.
If you look at the old BCT thread, I was a big fan of the original ripple IOU system, before ripple labs bought the name, and had recommended it as a potentially fruitful area to many people. The original system could potentially have been implemented without any global consensus at all, which was a large part of why I found it interesting-- Global consensus is enormously costly. But functionality like a new cryptocurrency currency for the purpose of funding the company and the integrated non-interactive rippling (which apparently has been largely turned off in ripple now due to other security vulnerabilities) brought back in the global consensus requirement. (The result was that I felt I had to go edit all my old posts to remove my recommendations, since the system was wildly changed to be something else)
Re: Stellar Consensus Protocol: Proof and Code
#87Earlier quoted context omitted.
> I don't necessarily want to depend on mining rigs Indeed, the security model provided by Bitcoin consensus system may not be fit for any particular purpose. But it has one, and so we can think about it and decide what purposes it may or may not be fit for, and think about under what conditions it will be safe or not safe. > is to leave such policy questions up to the market and see what kind of architecture emerges…
You're saying "how do we know that that quora will sufficiently overlap?". David seems to be saying "how do we know they won't?". At this point, I think just about everyone can agree that the security depends on a set of empirical assumptions that we currently simply do not know how they will play out into the real world. So my plan at least is to simply sit back and see how it actually ends up evolving in real life;…
> "how do we know they won't?"
Because the prior version _already_ faulted in production as a result of having a trust graph that didn't meet the prior criteria needed for safety. The prior version also resulted in centralization in practice (in it's ripple instantiation; kind of neat that the ripple->str-reboot let us see both of the predicted failure modes play out, even though they were largely mutually exclusive)
The latest work is intended to relax the requirements/consequences but still provides no guidance or tools for achieving the required topology in practice.
By all means, clearly label these efforts that have have taking a "you haven't yet proved its broken" approach to safety/security; and I won't complain about them. Absent that, I just normally expect that when someone produces a cryptographic product that they've actually given some care to their security.
> consequence is that people will start putting the Stellar equivalent of blockchain.info onto their trust list in order
Then if they're anything like the Bitcoin world's blockchain.info-- which is regularly in a confused state--, I'm may soon find myself the proud owner of infinity STR, I guess? ( Screenshot someone else sent me of the actual BC.i site one day a while back: http://people.xiph.org/~greg/21mbtc.png )
"testing is making sure it does what it should, security auditing is making sure that is all it does"
Re: Stellar Consensus Protocol: Proof and Code
#88I'm finding the graphic novel explaining federated consensus to be really entertaining: https://www.stellar.org/stories/adventures-in-galactic-conse...
Joyce from Stellar here. Thanks! As we were working on the white paper, we realized how difficult it was to explain complex concepts like federated Byzantine agreement. We know it’s part of our jobs to make these ideas understandable. That way more people can join the dialogue and think of ways this infrastructure can be used to build services for their communities, which may be really far from the nearest computer s…
The hard part is often explaining something. And if you want to change how money works, you need to be very good at explaining.
Re: Stellar Consensus Protocol: Proof and Code
#89Earlier quoted context omitted.
Hello Dr. Mazieres, thank you for making the Stellar whitepaper available! While inter-domain route agreements show precedent for building a robust network out of pairwise relationships, might this particular class of agreement also work because it happens to be a "small world" where failures are obvious? That is, the set of major AS operators is small enough that all the major players know one another (since ICANN)…
So first, a lot of problems with Internet routing do not really affect SCP's safety--for example bogus route announcements. Part of the reason is that SCP depends on transitive reachability. And of course part of the reason is that SCP is built on top of the Internet, so can already assume a basically running network underneath. I can't predict the future, but I do think it is likely that a bunch of de facto importan…
Why would I ever want to depend on Citibank?
Re: Stellar Consensus Protocol: Proof and Code
#90Earlier quoted context omitted.
Graydon also created monotone, which was a big influence on git. http://www.monotone.ca/monotone.pdf https://en.wikipedia.org/wiki/Monotone_%28software%29#Monoto...
I think Monotone was an alternative to BitKeeper and BitKeeper was the inspiration of Git and Mercurial. It even seems to suggest that in the link you posted.
BitKeeper not being available anymore was the impetus for starting Git and Mercurial (as replacements for BK), but many of the concepts in Git and Hg come from Monotone, most importantly the use of merkle trees (according to /u/ggherdov Matt Mackall[0] recently mentioned this explicitly on IRC). Linus also mentioned Monotone by name as "the most viable alternative" before starting/publishing git[1] and as pgeorgi noted contributed to the same.
[0] https://www.reddit.com/r/programming/comments/31yi7d/graydon...