Jump to content


Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


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
  1. Transaction fees in xCurrent are denominated in the currencies of the transaction. For example, sending Japanese yen to Thai baht, fees would be denominated in JPY and THB.
  2. I don't believe Ripple is "handing off" any specific validators. It might be that the validator in question is a Ripple validator that was removed from the list but is still showing up on the site due to a prior validator list? (Again, with the "add two non-Ripple, remove 1 Ripple validator" plan, Ripple validators are getting removed from the trusted list one by one.)
  3. mDuo13

    Validator Trust Score?

    The trust score thing from the old Ripple Wiki was aspirational / conceptual stuff from when the founders were designing the protocol. There's no trust score information in rippled or in the validator list site at the moment, as far as I know. From any individual server's perspective, validators are either trusted or not. (Also, some peers may be considered "insane" if they seem to be following a completely different ledger chain, like if testnet servers accidentally connect to mainnet servers. Not sure if being "insane" disqualifies your validation votes; it generally doesn't matter since the trusted validators are all following the same ledger chain.)
  4. You can issue arbitrary currency within the XRP Ledger. Those issued currencies/IOUs can be atomically swapped with each other and with XRP, within the XRP Ledger. Swapping from a currency's native form (whether it's a fiat, crypto, or whatever) to the issued currency in the XRP Ledger (or the other direction) is not atomic. The Interledger Protocol's purpose is to make it safer to swap currencies across a ledger boundary like this, but Interledger's atomic mode was removed from the public spec because it still required participants to agree on quite a few things.
  5. Continuing from what tulo said, to check whether flags are set, use the AND operator (&). For example: tfSetfAuth = 0x00010000 tfSetNoRipple = 0x00020000 tfSetFreeze = 0x00100000 Flags = 2147680256 // tfFullyCanonicalSig, tfSetfAuth, and tfSetNoRipple are enabled if (Flags & tfSetNoRipple) { // True console.log("Flags include tfSetNoRipple") } else { console.log("Flags don't include tfSetNoRipple") } if (Flags & tfSetFreeze) { // False console.log("Flags include tfSetFreeze") } else { console.log("Flags don't include tfSetFreeze") }
  6. @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.
  7. 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").
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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).
  13. 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"
  14. 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.
  15. 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.