Jump to content

mDuo13

Ripple Employee
  • Content count

    368
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Ripple Address
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX
  1. @Tinyaccount , I think you might have conflated two ideas: The required percentage of "good actors" in a given server's UNL. If your server's UNL has >X% faulty nodes, they can stop your server from declaring consensus. If it has >Y% faulty nodes, they can make your server think fraudulent transactions have been confirmed. I don't remember offhand what numbers X and Y are, but I think they were something like 20% faulty stops network progress and 80% faulty is needed to confirm fraudulent transactions. The required amount of overlap between different servers' UNLs. If your chosen UNL has <Z% overlap with another server's UNL, then it's possible your servers may come to different conclusions as to what has been "validated". Originally, it was believed that Z was 40%, but that proof did not follow the academic standard of assuming that all network messages may be arbitrarily delayed or dropped as if by a malicious network operator. The recent research paper proved that Z is ~90% given this assumption. It is difficult to know how many servers will be faulty (which includes both malicious and buggy behavior) but obviously everyone hopes there are no faulty validators in their UNL at any given time. Of course, having a larger list means that there's more chance that one or two are faulty but also decreases the impact of that happening since any given validator represents a smaller percent. Cobalt's advantages are primarily related to the required overlap percentage (which it reduces from ~90% to ~60%), not the good/faulty node requirements. Plus it has some other advantages like simplifying the calculations on how much one's UNL overlaps with another because you would no longer have to worry about who's on your UNLs' UNLs, and so on. But as long as people have configured their servers to follow the validator list which is published at vl.ripple.com, their overlap percentage will be 100%—everyone has the exact same UNL.
  2. It is a big challenge to deliver exact amounts to a particular recipient by making two trades on different exchanges where the exact rates are constantly fluctuating. We spent a lot of time looking at this problem and exploring possible solutions. I'm not going into the details of how xRapid solves the problem, because that could be considered trade secrets, but if you want to think on it yourself, you should be sure that whatever you come up with doesn't fall into the "free option problem" (a variant on the "fair exchange problem").
  3. mDuo13

    When are New Offers "Applied"?

    Correct. rippled / the XRP Ledger does not ensure transactions (of any type) are processed in the order they are received. Doing that is not necessary to solve the double spend problem. To solve the double-spend problem, you must only ensure that every participant agrees on the order in which transactions execute and consequently what their outcomes are. In fact, a big part of the double spend problem is that different parties have different perspectives on the order in which transactions were received. For the most part, transactions are processed in the next ledger after they're received, with transactions that get into the same ledger being more or less randomly ordered. (It's deterministic, but hard to predict; and also, transactions from the same sender are relatively ordered by increasing sequence number.) The exact canonical ordering code is kind of complicated. You can see some discussion in this GitHub issue. Maybe an example would make this clearer: Suppose Alanis, Beethoven, Ciu, and Deepak each have XRP Ledger accounts and are sending transactions that arrive around the same time. Consensus approves a set of transactions that includes (in no particular order): A1, A2, and A3 sent by Alanis, where A1 is Alanis's lowest sequence transaction and the others are one sequence number higher each B1 and B2 sent by Beethoven, where B1 is Beethoven's lowest sequence number C1, C2, C3, C4, and C5 sent by Ciu, again ordered by increasing sequence number D1 sent by Deepak. One possible canonical ordering for this set could be: D1 B1 B2 A1, A2 C1, C2, C3, C4, C5 A3 First, the ordering of accounts is set based on some unpredictable hash (to be honest I don't know exactly how this works). Then all transactions by those accounts are attempted in sequence order. Some transactions may fail but are retriable. (For example, A3 attempted to spend money that isn't received until C4 is processed.) Then retriable transactions are processed.
  4. It sounds to me like you're describing a Sybil attack, which would probably not do anything for the same reasons I described in my previous post: the new validators are going to be completely ignored unless people are duped into adding them to their UNLs en masse. Remember: Spinning up new servers should have little to no effect on the existing network unless people choose to listen to them. XRP Ledger servers are "untrusted by default." At most, they are only used to relay signed messages to & from entities you do trust.
  5. Oh, and another thing: we're going to be closing down the old Ripple wiki soon, so rather than linking the "Ledger Cycle" wiki page, I recommend linking https://developers.ripple.com/consensus.html
  6. Since I was summoned: Yes, the protection against a Sybil attack is the rule that validators must be explicitly trusted, aka the UNL. (This isn't a foolproof protection, since the attacker could convince you to trust several different entities which are in fact the same one, but it adds a degree of difficulty there, which is all you can really do.) I do have a few nitpicks where the article is overly rosy about the XRP Ledger's advantages, but for the most part @Hodor is spot-on. I wish I knew Bitcoin's proof-of-work system better, but my understanding is that you decide which transactions to include in the block while you're calculating the hashes. The hash is a hash of the block's data (plus a variable nonce). I think, in practice, this is not that different from how you described it, because an individual miner still has some control over what to put in the block before they calculate the hashes; I'm just nitpicking the description. Another unimportant nitpick: the post implies that individual validators in the XRP Ledger consensus algorithm have no censorship power, but it's more accurate to say they have a very small amount of censorship power. They could choose to exclude particular transactions from their proposals, in defiance of the network rule that any valid transaction must be included in the next ledger provided it pays sufficient transaction cost. This would probably have a small but measurable effect on the time it takes the "censored" transactions to get into validated ledgers, since those transactions would lose slightly more "coin flips" in the cases where they were being broadcast right around the borderline between one ledger and the next. The size of this effect is inversely proportional to the number of validators, and you could detect when it was happening by analyzing the validators' proposals. Interestingly, even non-validating "hub" servers could have a similar effect in the XRP Ledger by simply refusing to relay certain valid transactions to their peers. The size of this effect depends on how well-connected the network is and how centrally-located (in terms of peer topology) the censoring servers are. It's not likely to be big, but it is a possibility to consider. I think something similar was demonstrated for Bitcoin, where a malicious network operator could even drop Bitcoin transactions in transit to manipulate which ones get confirmed sooner. Ultimately, these are risks that are inherent to operating on a wild, lossy, potentially adversarial network. Here's the big advantage of proof-of-work compared to the XRP Ledger's consensus algorithm: proof-of-work seamlessly¹ scales the number of participants who contribute to declaring a consensus on the next block; XRP Ledger's consensus mechanism requires hard work off-ledger to carefully choose trustworthy participants (UNL selection). That's why (as of this writing) Ripple hasn't yet recommended trusting any validators not run by Ripple. It's also the tiny nugget of truth behind the "centralized scamcoin" FUD. Here's another advantage of consensus the article didn't really cover: Consensus has a simple and native mechanism to discount malicious actors: simply remove them from your UNLs. With proof-of-work, if there was an entity known to be attacking the network with a huge hashrate, you would have to add some sort of mechanism to blacklist proposals from those malicious entities, and everyone who's not on the blacklist would have to agree not to use the valid hashes (with probably skewed contents) that those entities were producing. It's awkward and full of pitfalls. By comparison, XRP Ledger's consensus mechanism is simple: just stop trusting anyone who proves themselves untrustworthy. Anyway, both systems have their strengths and weaknesses, but my biggest personal preference for consensus is the electricity usage. Because it's a cooperative system, there's no need to spend excess electricity. It's not a wasteful competition to see who can flex their computational muscle the most. In a world where externalities from wasteful energy usage are one of the biggest threats to human society, I find a system that incentivizes waste to be reprehensible and scary. For those who've heard of the paperclip maximizer thought experiment, substitute "bitcoin" for "paperclip" and suddenly the idea sounds a whole lot more plausible. In fact, you don't even need to invent a single superintelligent A.I. to reach a similar end-state if human society is content to act out the same steps (in slow motion compared to super-AI timescales, probably). In short, don't discount the effectiveness of proof-of-work, but I sure hope consensus wins out for everyone's sake. ¹"seamlessly" may be a bit of an overstatement when you consider the awkwardness of transaction fee variability, but it remains that many more unique, unrelated parties have contributed to the network-achieved consensus blocks of Bitcoin while only 1 entity, Ripple (Labs), has ever contributed to the XRP Ledger consensus validations. This remains my biggest complaint with the XRP Ledger and why I'm pushing so hard for us to really follow through on the decentralization plan this year.
  7. mDuo13

    When are New Offers "Applied"?

    Offers are "processed" (executed) when a ledger closes¹; however, the outcome is not final unless the ledger is validated. You may have a candidate ledger N in which Offer A executes before Offer B, but a competing candidate ledger N´ may have a slightly different transaction set with a completely different canonical ordering where Offer B executes first. If Offers A and B are mutually exclusive, you don't know which one will succeed until you know if N or N´ is validated. I should add, the XRP Ledger is not ideal for HFT because there's an overall latency of 3-7 seconds for a new ledger to become finalized. The order in which new transactions (offers) execute when they're in the same ledger is intended to be arbitrary and unpredictable, so you don't get a benefit for being faster (as high-frequency traders typically do in most other markets). Which is not to say HFT is pointless, since you can still have a chance of taking a juicy offer the moment it appears. (Either by getting into the same ledger a target offer is created and being lucky enough to be after it but before your competing offers, or if nobody does that, then by getting into the following ledger as early as possible.) Also, I'm not familiar with any push to add a plugin architecture to rippled. ¹Transactions, including offers, are also tentatively processed immediately when they're included in an open "current" ledger, in the order they're received. The results of such processing are tentative, but not final—they're usually right if no mutually-exclusive transactions are received in the same ledger as long as the transaction doesn't fail to be included in the next validated ledger (for example because it was so close to the end of the window between this ledger and the next one that some servers let it in this ledger and others put it off for the next).
  8. Financial institutions that join RippleNet sign up to a standard set of rules and policies so that they can transact bilaterally with any other network member. However, financial institutions must individually choose which partners they want to transact with, and configure their xCurrent instances to speak to those instituions' instances. There have been cases where institutions have specific requirements or policies that are not covered by the standard RippleNet rulebook, either because of those institutions' internal rules or because of the jurisdictions in which they operate. Ripple is working hard on both the software and the legal agreements to make it easier to transact with more institutions with less setup. Still, when matchmaking¹ large, risk-averse, heavily-regulated institutions, not every member wants to or should connect to every other. ¹I kid you not, Brad and company have made jokes about how bootstrapping the network was kind of like being "Tinder for banks"
  9. mDuo13

    Securing Validators - Nikb

    Good question and to be honest I don't have the answer for you at the moment. I believe Ripple's ops team does some stuff with DNS(?) since s1.ripple.com for example doesn't consistently direct to the same server, but I do not have the technical details yet. I'll be sure that information is in the eventual published article on this.
  10. Ripple's decentralization plan is to find reliable businesses and organizations with a long-term interest in supporting the XRP ecosystem by running validators—or just hub servers that others can use to pass messages around. When those sorts of entities run validators well, Ripple will add them to its recommended validator list. (rippled servers with default settings automatically follow Ripple's recommended validator list.) For every two non-Ripple validators that get added to Ripple's recommended list, Ripple plans to remove 1 Ripple-run validator from the recommended validator list. Running a validator as a third party or individual helps the XRP Ledger indirectly in several ways: It helps set a standard for performance, so we can measure these businesses up to appropriate expectations. By providing feedback on the process, challenges, and guidelines for running validators, we can build more institutional knowledge on how to run a validator properly. The community can, collectively, test many more possibilities than any company can alone. Whether it's hardware specs, hosting providers, configuration settings, or network architectures, the more things the community tries out the more specific we can recommend things to businesses to reduce uncertainty and smooth out the process. As a corollary to this, if you run a validator, you should talk about your experience! What did you do? What hardware and operating system did you use? What went wrong or was confusing? How'd it go? If you stopped, why? If you're still running one, what kind of metrics have you collected from it? Honest, properly operating validators provide a backdrop for detecting dishonest or buggy behavior in validators.
  11. mDuo13

    Securing Validators - Nikb

    Thanks for highlighting it! Also, I've been meaning to do this for ages, so here, I tossed together a (rough) network diagram of what it looks like to configure public facing servers as a proxy in front of a private peer validator: In addition to speaking peer protocol to the outside network, your servers may or may not have a port for rippled API access. Obviously, don't expose an admin interface to the world at large. Your validator probably shouldn't expose any API access to the outside world. (You probably want admin access on localhost so you can debug/admin the server from an SSH session or whatever.) The load balancer and multiple clustered public facing servers are optional. You can also do a simplified architecture with just a single rippled server speaking through the firewall to the outside world. Peer protocol is a binary protocol so HTTP(S)-only load balancers won't be able to handle that. Anyway, this isn't thoroughly reviewed or official, so take the appropriate precautions. There will be an official version eventually.
  12. How does Heleum know which currencies are appreciating and how long those currencies are going to continue to do so?
  13. mDuo13

    New Ripple developers' site

    Yep, we worked very hard on putting developers.ripple.com together. (Pretty soon, ripple.com/build will be replaced with a redirect to the new site.) That introduction to the XRP Ledger article has been around for a while (published https://ripple.com/build/xrp-ledger-introduction/ back at the beginning of March) but the new site gives us a much better opportunity to highlight it By the way—if you see anything buggy-looking, or if there are technical areas you'd like to understand better, let us know. We're here to help! We've got some ideas already on what needs documenting, but feedback from the community certainly helps us calibrate our priorities. Here's to another great year for XRP!
  14. It's probable that any confusion on whether xRapid can use non-XRP currencies is a result of the product evolving over time. There was a beta of xRapid that could use BTC instead of XRP as an intermediary currency. It worked OK, but BTC didn't offer much price advantage, and having multiple intermediary currencies added some complication and limitations so we've since removed the ability of xRapid to use BTC as an intermediary. As it exists today, xRapid always uses XRP. It's not fundamentally required to be that way, but XRP works best so that's how it is at the moment. In contrast, xCurrent uses whatever (generally fiat) currencies the institutions hold in their systems already. It's about orchestrating atomic swaps between two or more institutions. The "or more" is important there as that's where you may find future-xRapid appear as an intermediary in an xCurrent-powered transaction.
  15. I'm happy that Zagone didn't fall for Mr. Walker's provocations, and kept his cool. That's part of the Ripple brand, strategy, and ideals: calm, humble confidence and fundamental strength built from cooperation and measured, rational thought. Ryan Zagone is a consummate professional and I'm proud to be working on the same side. Also, this first post would be easier to follow if you made it clear precisely what video you were referring to. Maybe you should include a link to the actual talk?
×