> Generally, membership in Byzantine agreement systems is set by a central authority
or closed negotiation. Prior attempts to decentralize admission have given up some of
the benefits. One approach, taken by Ripple, is to publish a “starter” membership list
that participants can edit for themselves, hoping people’s edits are either inconsequential
or reproduced by an overwhelming fraction of participants. Unfortunately, because
divergent lists invalidate safety guarantees [Schwartz et al. 2014], users are reluctant
to edit the list in practice and a great deal of power ends up concentrated in the maintainer
of the starter list. Another approach, taken by Tendermint [Kwon 2014], is to
base membership on proof of stake. However, doing so once again ties trust to resource
ownership. SCP is the first Byzantine agreement protocol to give each participant maximum
freedom in choosing which combinations of other participants to trust.
A particular concern with Ripple is what would happen if Ripple validators failed not by crashing, but by getting compromised and acting maliciously (so-called Byzantine failure). The Ripple paper states in Section 3.2 that "it would take (4n + 1)/5 Byzantine failures for an incorrect transaction to be confirmed" (where all nodes are assumed to have identical UNLs and n is the size of that UNL). I believe this is an error, as with a quorum size of 80% of n, it is easy to construct a counter-example. Suppose nodes v_1 and v_10 are honest, while v_2, ..., v_9 maliciously deviate from the protocol. Now consider the two 80% sets (v_1, ..., v_8) and (v_3, ..., v_10). Those two sets overlap at only malicious nodes that could prevent v_1 and v_10 from hearing about each other's transactions.
The nice thing about SCP is that it is optimally safe (Theorem 13 in the paper). That doesn't mean it guarantees safety under all possible configurations (e.g., two disjoint sets of nodes that don't know about each other). But it means that in any configuration where there exists some protocol that could guarantee safety, SCP will guarantee safety as well. That includes Byzantine failure scenarios. So you could translate UNLs into quorum slices and substitute SCP for Ripple's consensus algorithm, and if RPCA was already guaranteed safe, then SCP will be, too. The converse is not guaranteed; you could choose a configuration that is safe under SCP and risks forking under RPCA.
This paragraph does not explain how they are different from Ripple's approach only that they are in fact different.
I think the last line sums it up: "SCP is the first Byzantine agreement protocol to give each participant maximum freedom in choosing which combinations of other participants to trust."
As opposed to Ripple, where the trust is heavily biased towards the starter membership list, making it more centralized than one would want.
It’s biased because of a technical issue (consensus must be reached). How does the Stellar protocol solve this technical issue?
To me, the statement says essentially "you can trust us more than Ripple" with no explanation as to why.
> David I always enjoyed working with you and I thought we had a degree of respect for each other so I'm pretty disappointed in your tone here. I don't really want to get into a big back and forth about this but this just isn't correct. When I left ripple the board was 2 people; myself and Chris.
> I left because I made the mistake of bringing Chris on as CEO and it ended up being untenable to work with him for a variety of reasons.
> I feel like I've been extremely restrained in my criticism of ripple despite the frivolous lawsuits from you guys the constant attacks on my character and my family. I know you are actually a good person but I think you are in too deep to see how horrible Chris has acted toward me.
> Stellar hasn't abandoned the idea of distributing the lumens widely and the original facebook distribution was actually a success but the software/ecosystem wasn't ready for it at the time so we stopped it. We will do something similar in the future. I don't think any attempt at an internet level protocol like stellar or ripple can be widely adopted with a for profit company owning the majority of the tokens.
> Stellar has always been focused on cross border payments so the IBM announcement isn't a pivot by any means.
> Stellar and ripple are going after two completely different use cases as far as I can tell so I don't understand the continued hostility.
Secure Scuttlebutt is a database protocol for unforgeable append-only message feeds.
"Unforgeable" means that only the owner of a feed can update that feed, as enforced by digital signing (see Security properties). This property makes Secure Scuttlebutt useful for peer-to-peer applications. Secure Scuttlebutt also makes it easy to encrypt messages.
SSB is deliberately “against consensus”, which makes it useless as a trustless decision-making tool. So I take your point that this property of Stellar seems to make Stellar useless for its stated purpose. (I haven't read the paper, so I may be very wrong.)
If you’re worried about it, read the linked paper. The mechanics (and assumptions) are covered in painstaking detail.
I bet there is already CS research theory ready to apply to this design. (Easier said than done and I am just guessing really).
PoW distributes the leadership (block creation) via crypto puzzles. PoS tries to use economic incentives to make bad behavior more expensive than good.
There's work being done (which I personally believe is the right way to go) in using a leader election-based system that works like a lottery (Algorand is an example). The basis of such a system is going to be the creation of non-biasable pseudo-random number generation.
Along these lines one of the more intriguing projects is called RandHound. It's a way of creating distributed randomness (according to the paper's title). I think chains secured via lottery leader selection protocol has more promise than PoS.
Edit: for clarity
A lottery-based system works because the "winning numbers" (imagine a winner being a node whose public key when XOR'd with the winning number is below a certain value) are known to all (a protocol like randhound ensures that all nodes know the winning number). A winner's bundle of transactions are validated as his/her's by cryptograpic signature (which can be verified using the same public key that is used to confirm this person is truly a winner). Those are the broad strokes. Obviously there's a lot more to getting it to work. I've been working on it for months and still haven't gotten around to putting it down on paper.
Probably what you meant but I still wanted to mention it: Bitcoin (or most PoW schemes) work like a lottery. Think of each attempt at generating a nonce below the required difficulty as a lottery ticket. The more nonces you generate (the more hashes per second you compute) the higher your chance of winning. The system works because people who spent lots of money on lottery tickets in the past (and maybe won one or two times) are incentivized to keep the lottery running in an honest manner (so their prize keeps its value - if they haven't spent it).
> Along these lines one of the more intriguing projects is called RandHound. It's a way of creating distributed randomness (according to the paper's title). I think chains secured via lottery leader selection protocol has more promise than PoS.
Another notable mention is dfinity (dfinity.org). They have a very interesting technology stack and I'm hoping for discussions about it in the future on HN.
One way to view how SCP avoids leader election is to consider that it is effectively emulating the leader. SCP has two phases, a nomination and a balloting phase. The nomination phase is effectively like one or more instances of an asynchronous broadcast protocol (which don't require a leader since multiple nodes can choose to broadcast). The balloting phase is like Paxos, except that the value to propose is embedded in the ballot number so nodes don't require a leader to tell them what is being proposed--they can each emulate the leader themselves.
One application that uses XLM as its native currency is SatoshiPay (that's how I got to know Stellar).
Does the algorithm fundamentally require that every transaction have to eventually pass through every node in the network?
The idea of quorum slices seems to imply 'no' but the whitepaper doesn't appear to make any attempt to connect the concept of quorum slices with actual transactions.
Can anyone answer that question?
Running a validator protects a token issuer against double redemptions, as might happen in a mining-based blockchain where anonymous miners fork the blockchain and thus create twice as many tokens. That's fine for pure crypto tokens, where you can create Ethereum [classic] or Bitcoin cash out of thin air. But if you were using colored coins or ERC20 tokens to represent claims on bank deposits, these forks would be a problem.
If you look at the market tab of this site, it gives you an idea of current and old exchanges for that instrument.
We're not done yet. IMO it's still not easy enough to build great software on top of our work.
I don't think building a turing-complete VM into stellar anytime soon is prudent. The work the ethereum folks have done is crazy impressive, and certainly it is beyond anything I myself could create, but IMO they are also too cavalier. I don't think we (programmers in general) have the collective smarts, wisdom, discipline, and ethical codes needed to build a safe "world computer" yet, and I don't think we've got a good grasp of the potential ramifications of an unsafe solution. I imagine there are many unknown unknowns to encounter as the world stumbles in the dark, greedily, from where we are today in the direction of skynet.
All that said, I'd really like to see a world with more decentralizing forces and where decentralized applications can more feasibly compete with centralized services. I think stellar can help make this happen one day. I'm sick of being forced to trust the googles and facebooks of the world with my personal data while not having viable alternatives, and I think one way to work towards breaking their outsized influence on humanity's digital culture is to enable and make accessible more decentralized interactions of increasing richness. Instead of building one turing-complete decentralized protocol to rule them all, I'd love to see us continue to develop a constellation of focused decentralized systems that we can consider/develop/verify/maintain in isolation first. Then, as our comfort with each system grows, we can work to carefully combine and layer them in increasingly useful ways. There's such a long way to go.
On a related note, IMO we too often think that what we're doing on a day to day basis is just computer science and don't often enough consider the social science-y aspects of our work. From how we structure our APIs to how we communicate with users about the responsibilities involved with participating in decentralized systems, we have tons of soft problems to overcome that can't easily be fed into a compiler or reasoned about formally to determine the quality of our solutions. For evidence, look at what occurred recently with the parity wallet/solidity or -- an example that hits closer to home for me -- the snafus around the account recovery system in stellar's original web client.
Please take the above with a grain of salt. I realize that the above isn't supported with citations and in the end I'm just some random fuckhead coder. I'm sure plenty of people here can point to why my thoughts on the subject are wrong and why ethereum is taking the correct approach to smart contracts; I don't pretend to be able to hang with the big brains of the cryptocurrency space.
All of the above is also not representative of stellar's official positions... these opinions are 100% my own.
I am looking to do something, not 100% what on Stellar Network, mostly due to the fact that I am familiar with it and I like api among other things.
I'm deeply skeptical of most altcoins, but Stellar is going places.