[vbuterin]

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.

[nullc]

> "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"

[swamp12]

(Jed from stellar here) The fork you are describing occurred in the previous protocol when all the nodes had the same UNL; the failure had everything to do with that previous protocol's response to overloading (it diverges based on timeouts, rather than getting stuck, and discards the losing fork on healing) and nothing to do with trust topology. So it didn't have anything to do with improperly set up trust.

In SCP the topology is public and conveyed with each consensus packet. So people will be able to tell when the graph is vulnerable.

Improving the definition of topology requirements for correct consensus is, far from being 'ignored', exactly what Mazieres has been working on all this time. And as you admit, those requirements have now been formalized and the information to check them is conveyed in the consensus packets; they are just not trivial to check by hand, and we have not yet implemented a check for them in stellar-core (this will be forthcoming, see roadmap).

[rfugger]

Hey Jed. I'd be interested in a post mortem on the fork, how the network broke down, and how the new protocol addresses those issues. Reading the paper, I can believe the new protocol works, but it's difficult for me to pinpoint how exactly it differs from the old protocol.

I'm also interested in how the explicit quorum slice data for each node can be used to maintain quorum intersection over the entire network as new nodes join.

[JoelKatz]

I'd be interested in a post mortem on the fork as well. During the split, either one side has a supermajority or neither side does. If one side has a supermajority, that side will win on rejoin, so no problem. If neither side has a supermajority, then one side or the other will win on rejoin, but nobody's been relying on either side. In every case, there should be no problem.