Hacker News new | past | comments | ask | show | jobs | submit | swamp12's comments login

The Stellar network did fork when we running on a fork of legacy software. Since then, we have rebuilt the entire consensus system using a completely different consensus system. The underlying consensus system was designed by Prof. David Mazieres, head of Stanford University's Secure Computing group - you can read the white paper here: https://www.stellar.org/developers/learn/concepts/scp.html A completely new implementation of SCP in the form of stellar-core was completed earlier this year. You can read about it here: http://graydon.livejournal.com/227874.html


This is an example of an approach to smart contracts that uses the Stellar model which keeps the bulk of the logic outside of the system so only people that are interested need do any processing. This should make it more scalable.

I haven't thought through it yet but I think the most common case would actually be 1 directional. Curious if people agree or have another opinion?


Yes it is a completely new codebase. No code is shared between them in either the core or the libraries.


Oh I think it was misunderstood. The full quote is: "Byzantine agreement guarantees distributed consensus despite the Byzantine failure of participants. However, it requires unanimous agreement on system membership by all participants. Each node in the network must be known and verified ahead of time." It is comparing SCP to Byzantine agreement protocols like paxos.

As in Stellar doesn't have this requirement. Here is the white paper: https://www.stellar.org/papers/stellar-consensus-protocol.pd...


The difference between a byzantine agreement and a federated byzantine agreement used in SCP is that it reaches consensus based on quorum slices rather than the whole network consensus. This is just removing the graph edges from the bitcoin node network. The real problem then is optimum quorum slicing to guarantee many possible problems that might arise, such as partition-tolerance, non-survival of a bad node etc .

Maybe you have addressed these concerns, I'll read the paper to check. Can you please answer one question though, how are the coins originated in this system?


Yes a node in the Stellar network doesn't need to know all the other nodes in the whole network and adding and removing nodes is a fluid and open process but yes there must be some transitive overlap in the quorum slices people choose. The details would be better explained in the paper.

All the coins(lumens) exist when the network starts up. The Stellar Foundation is distributing them in the following way: https://www.stellar.org/about/mandate/#Stellar_distribution


We have been heads down for the past several months working on the new network that is much more scale-able, has a provably correct consensus mechanism and a much more flexible modular design. It has cool features like multi-sig and attaching arbitrary info to transactions. We released it in beta a couple months ago: https://www.stellar.org/blog/stellar-consensus-protocol-proo...

We are turning the new network live very soon.


(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).


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.


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.



Thank you :)


It is a complication left over from ripple. It will most likely be turned off by default.


Well you can turn the feature off if you want. You can also set the "quality" of a given issuer. This means that you could apply a discount to the mtgox credit so it would swap out at a discount. But really it will probably just be turned off by default


Sorry that wasn't clear. What she means is the amount given to each person. We are still and always will be committed to giving away the total 95B stellars. I just edited her post to clarify what we were trying to say.


Thanks for the response. At the same time, I remained concerned by this idea that an increase in value of Stellars would slow down the rate of distribution.

After all, new users are a limited commodity (particularly after the honeymoon period). So almost by definition, if you chose to decrease the amount of Stellars distributed because the price is increasing, then you're slowing down the rate of distribution.

Which is exactly what Ripple has done.

I'd be happy to be proved wrong on this one, but I'm definitely taking a wait and see approach.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: