I'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…
Stellar Consensus Protocol: Proof and Code
41–50 of 99 posts
Re: Stellar Consensus Protocol: Proof and Code
#42"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::Sigh:: This sounds like it does not even speak to one of the major fundamental issues of their approach; which I pointed out in 2013 ( https://bitcointalk.org/index.php?topic=144471.msg1548672#ms... ) and appeared to play a critical role in Stellar's spontaneously faulting, and has been avoided in ripple by using effectiv…
You are correct that safety requires overlapping quorums. However, the trust decisions are public, as this is what allows participants to discover quorums. The scenario you describe of two groups of 100 participants overlapping at one node might or might not be a problem. The most likely cause of such a topology is a Sybil attack, in which an attacker with one seat at the table gloms an extra 99 nodes onto the system…
Ah. What mechanism assures this consistency of this information?
> at one node might or might not be a problem
How could it not be a problem? If that is the totality of the network, and the network is 1-fault tolerant, what prevents spontaneous divergence of the state?
> most likely cause of such a topology is a Sybil attack
"likely"? It's not clear what you mean there. What statistical model have you adopted that allows you to reason about the likelihood of various topologies?
Social networks usually appear to have small word behavior where its usually very easy to draw lines that describe disjoint local-majorities (or fairly large local-super-majorities).
I agree that a sybil sticking on a bunch on a bunch of extra 'nodes' and the sybil nodes diverging as a result isn't interesting case. What I do think is interesting is what mechanism will prevent user's honestly stated trust (much less politically manipulated trust) being a bad topology?
What is the procedure that I can follow, that if everyone else follows it, results in the correct global behavior (with high probability)? What are the additional assumptions required to achieve that and make it secure? Why are they plausible? Do they provide decentralization? (I can suggest on procedure which works: Stellar tells everyone who to trust; but it completely fails at decentralization so I assume that isn't the goal.)
In Bitcoin our security assumption is that the computational majority of participants conform to the protocol ('are honest') and these participants are not completely partitioned from each other. People can then think about-- or debate-- how reasonable those assumptions are.
(There are alternative formulations of Bitcoin's security which also argue about how plausible these assumptions are given economic incentive assumptions; but even this most simple set of assumptions gives people something easy to reason about.)
Can you give a parallel (informally stated, but equally comprehensive) version of the security assumptions for your consensus system?
> But there is certainly precedent for building a robust network out of pairwise relationships, namely inter-domain routing on the Internet.
The Internet is _wildly_ inconsistent. Asymmetric routing is the norm, the internet frequently suffers small partitioning and loops; single malicious parties at the edge can frequently inject bad state that is accepted globally, congestion and blocking happens multiple hops away from users where they have no recourse. The internet is not a consensus system, and these issues are not usually hugely problematic; someones brokenness doesn't involve your traffic generally effect you, you can route around problems locally. Ephemeral routing and ledgers are fairly different problems. Ambiguity about the ownership of a coin eventually effects almost everyone. I'm not seeing the connection you're making there.
I certainly agree that useful systems can be built from pairwise relationships: The original ripple design for pure IOUs without creating its own cryptocurrency prior to opencoin buying the ripple name was such a system, it had no need for a global consensus (except perhaps in certain atomic unwind cases)-- only the participants in a particular IOu transfer needed to be involved. It is not at all clear to me that a safe global consensus system can be built from pairwise trust.
Re: Stellar Consensus Protocol: Proof and Code
#43I'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…
When your software aspires to move billions of dollars of value, it would ideally be written in Ada. That said, I agree that C# and Java are good options. What's hilarious is all of the Bitcoin startups that are running on node.js and mongodb. Would you put your kids on a flight if you knew the control system was written with javascript and mongodb? Yikes.
Re: Stellar Consensus Protocol: Proof and Code
#44Re: Stellar Consensus Protocol: Proof and Code
#45Earlier quoted context omitted.
> I believe the same kind of attacks to be plausible with the Bitcoin network This isn't anyone elses understanding. Can you suggest a mechanism by which it would be possible for a minority conspiracy to perpetually exclude a transaction in Bitcoin?
Well in bitcoin, of course, trust would map to computing power.
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.
Re: Stellar Consensus Protocol: Proof and Code
#46"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::Sigh:: This sounds like it does not even speak to one of the major fundamental issues of their approach; which I pointed out in 2013 ( https://bitcointalk.org/index.php?topic=144471.msg1548672#ms... ) and appeared to play a critical role in Stellar's spontaneously faulting, and has been avoided in ripple by using effectiv…
> "It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". Failing to ensure quorum intersection in my quorum slices choice will have local repercussion and may befoul nodes that depend on me but does not prevent global functioning if the rest of the topology has quorum intersection. I think your argument here is sane, but I also believe that under reasonable circumstance we can…
Re: Stellar Consensus Protocol: Proof and Code
#47"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::Sigh:: This sounds like it does not even speak to one of the major fundamental issues of their approach; which I pointed out in 2013 ( https://bitcointalk.org/index.php?topic=144471.msg1548672#ms... ) and appeared to play a critical role in Stellar's spontaneously faulting, and has been avoided in ripple by using effectiv…
You are correct that safety requires overlapping quorums. However, the trust decisions are public, as this is what allows participants to discover quorums. The scenario you describe of two groups of 100 participants overlapping at one node might or might not be a problem. The most likely cause of such a topology is a Sybil attack, in which an attacker with one seat at the table gloms an extra 99 nodes onto the system…
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) maintains a centralized list of who owns which AS number), and bogus route announcements are easy for an AS operator to detect since they coincides with floods of angry tech support calls asking why www.foo.com no longer loads (or loads www.bar.com instead). By contrast, it seems that Stellar is geared towards environments with neither of these properties--large worlds with hard-to-notice failure modes.
I ask because I'd love to hear your thoughts on how to select quorum slices when considering the political and economic incentives that might influence which node operators I choose to trust. Specifically, do you foresee the emergence of a small set of big-player node operators that application developers almost universally (and blindly) select for their programs' quorum sets, like how web browsers and OEMs regard CA operators today? How can Stellar help users do better than blindly trusting a small set of operators? I'm assuming that the fact that big-player node operators must nevertheless externalize the same slot values in order to enjoy liveliness makes it easy for the application to automatically detect any equivocation? If so, how would nodes be deployed to resist DDoS attacks that try to break the vast majority of usres' quorum sets? I'm getting the impression that there's a missing precondition here that for a large-scale Stellar deployment to be successful, there must be a very diverse set of quorum sets.
Thanks again!
Re: Stellar Consensus Protocol: Proof and Code
#48"It is the responsibility of each node v to ensure Q(v) does not violate quorum intersection". ::Sigh:: This sounds like it does not even speak to one of the major fundamental issues of their approach; which I pointed out in 2013 ( https://bitcointalk.org/index.php?topic=144471.msg1548672#ms... ) and appeared to play a critical role in Stellar's spontaneously faulting, and has been avoided in ripple by using effectiv…
Re: Stellar Consensus Protocol: Proof and Code
#49Re: Stellar Consensus Protocol: Proof and Code
#50Earlier quoted context omitted.
The attackers' 100 nodes might of course diverge if they are so configured, but nobody will care. The person who is being attacked cares, right? Is there a way for a Stellar node to realize that it has been partitioned from the real network?
Yes, and this is kind of the whole point of the protocol. It just hinges on defining the real stellar network. An analogous question is, "Is there a way for a computer to realize it has been partitioned from the real Internet?" Well, sure. Pick 50 web sites you think are really important--maybe a bunch from Alexa, plus your bank, employer, etc.--and make sure you can reach the vast majority of them (using https, of c…
This requires you to trust the 50, correct?