fintechophile examined the stellar consensus modifications and found that when he fed identical inputs into the code, that the stellar consensus implementation produces different results than the ripple implementation.
Read his analysis.
I do not understand the consensus code well enough to explain based on the code itself, but I will direct your attention to the Stellar code commit that made the change and let it speak for itself:
https://github.com/stellar/stellard/commit/067d7158720331937fc782cbb230e8d422cd7341
The title of the commit is as follows:
Quote
consensus changes: faster catch up, delay when out of sync
The title and location of the change indicate that stellard is no longer using the same consensus algorithm as rippled.
Now, examine the actual commit comment:
Quote
* Consider there is consensus when we detect that we've fallen behind (old code was waiting to reach consensus with other part of the network); this increases the chance that we catch up to the network.
* If we can't catch up to the last closed ledger in SQL consider ourselves syncing
* If we can't catch up to the last closed ledger in SQL consider ourselves syncing
When David Schwartz described why the Ripple algorithm would not fork, it was because nodes that found themselves in the minority would wait to rejoin the consensus before advancing.
However, the plain English reading of this stellar commit comment implies that this behavior was discarded and that in the Stellar consensus algorithm, nodes plow forward blindly instead of actually waiting to reach consensus with the rest of the network. This sounds like a recipe for a fork.
Regardless, it appears that the two systems are no longer using the same consensus algorithm.
The Ripple Labs response is here:
https://ripple.com/why-the-stellar-forking-issue-does-not-affect-ripple/
