Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stellar Consensus Protocol: Proof and Code

stellar.org

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Stellar Consensus Protocol: Proof and Code

#91

Post by themusicgod1 »

oskarer wrote: post #49

It looks very promising, but I was unable to find the answer to this simple question: How do I get my money from my bank account into the Stellar network?

> How do I get my money from my bank account into the Stellar network?

In addition to using gateways, as diyang suggests, there is another way, but you first need two things

1) Someone on the network who you trust. This may be your bank, but it could also be something else. I'm not going to tell you who or what you should trust, and to what extent, that is a decision that should be always in your hands

2) A path between the entity you trust and an entity that either you or your bank has access to.

Until #2 exists, you can do what the poster below just said: use a gateway. This is not recommended, as they are probably going to track you and it may not be always possible to deal with them in a humane way.

So really it depends on what your bank is, whether it makes sense to draw money from your bank into another form/service that is compatible with a service that stellar can talk to. What bank? What country? These things are going to matter on the global scale.

Re: Stellar Consensus Protocol: Proof and Code

#92

Post by swamp12 »

nullc wrote: post #87
vbuterin wrote: post #82

Earlier quoted context omitted.

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)…

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

Re: Stellar Consensus Protocol: Proof and Code

#93

Post by rfugger »

nullc wrote: post #18

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

Ripple formalized its topology requirement in its consensus whitepaper (page 5, section 3.3):

https://ripple.com/files/ripple_consensus_whitepaper.pdf

Basically, any two UNLs must have 20% overlap to avoid any risk of a fork.

Re: Stellar Consensus Protocol: Proof and Code

#94

Post by rfugger »

swamp12 wrote: post #92
nullc wrote: post #87

Earlier quoted context omitted.

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

(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 t…

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.

Re: Stellar Consensus Protocol: Proof and Code

#95

Post by rfugger »

jsprogrammer wrote: post #89
mazieres wrote: post #53

Earlier quoted context omitted.

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?

You obviously wouldn't. But lots of people depend on them already because lots of other people do and they don't want to spend any more time thinking about it than they absolutely have to. If you can convince them to change, more power to you.

Re: Stellar Consensus Protocol: Proof and Code

#96

Post by SkyMarshal »

rational-future wrote: post #62
VienneseCPA wrote: post #24

Earlier quoted context omitted.

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.

You are partially right. It is completely possible to write in JS/Mongo systems as robust as Ada/Oracle|DB2|SQL Server. You just have to know what you are doing. There is no magic in Ada, Oracle, etc. Node and Mongo are moving hundreds of billions daily in HFS shops.

>There is no magic in Ada, Oracle, etc.

There is no magic but there are strong constraints that shift reliance for correctness from fallible human programmers and peripheral tools to the type system and compiler, providing better integrated, systematic assurance.

Re: Stellar Consensus Protocol: Proof and Code

#97

Post by JoelKatz »

rfugger wrote: post #94
swamp12 wrote: post #92

Earlier quoted context omitted.

(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 t…

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 ne…

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.

Re: Stellar Consensus Protocol: Proof and Code

#98

Post by JoelKatz »

TheOsiris wrote: post #13
burke wrote: post #10

Earlier quoted context omitted.

This is kind of explained away implicitly by pages 6-7. Each node has its own quorum slice, and they tend to point upward to a set of trustworthy financial institutions, not entirely unlike DNS. i.e. FBA relies on a web of trust, not just on showing up and churning out hashes or whatever.

isn't this still sort of pseudo-centralized? my guess is that most people will trust the same handful of nodes.

This kind of "pseudo-centralized" is decentralized. When the "central authority" gets all of its power from individual participants who choose to follow it, and those participants are free to change the authorities at any time, that's a decentralized model. Bitcoin isn't centralized just because everyone has to agree on which transactions are valid.

Re: Stellar Consensus Protocol: Proof and Code

#99

Post by ryanobjc »

dward wrote: post #84
ryanobjc wrote: post #80

Earlier quoted context omitted.

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

Shovel data around at speeds that push the boundaries of hardware performance. That isn't systems programming?
Post reply on HN