Jump to content


Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. Just don't pretend it's a "chi" and pronounce it like the hard "k" sound in LaTeX. Also, as you may have noticed, "Ripple Consensus Ledger" is now officially "XRP Ledger" (same tech, new name) so that hopefully there can be a little less confusion with xCurrent. And yes, xRapid uses XRP to source liquidity, and I'm excited to share more on that when we can.
  2. There are pros and cons of trading currencies using ILP or using the exchange built into the RCL. ILP's exchanges are more or less infinitely scalable; the RCL's exchange is not. ILP exchanges can be settled much faster than the 3-5 seconds it takes for an RCL ledger close. However, the RCL provides fully-atomic trades, bridging through XRP or not, with a well-known central set of validators. ILP trades using the open standard are not perfectly atomic since you don't have central validators/notaries for juding whether a transfer made it before expiration; it's possible for a connector in the middle to lose money, especially if the ledger they use goes down momentarily. (See also: Connector Risk Mitigations) ILP's "atomic mode" requires you to agree on a set of validators/notaries, which by definition means you're following some set of rules not part of the open standard. That's why it's not part of the open standard (anymore). So for people who want to conduct fully-atomic trades in a decentralized fashion, the RCL provides a handy set of validators and happens to have that functionality built-in already. It's possible that's not a big use case for a lot of people, who'd rather conduct faster trading with a centralized counterparty at a private exchange, or route cross-currency payments through the standard method of connectors. We'll see. I think it's likely that ecosystems for both will coexist for quite a while, at least.
  3. Order of trade execution

    In any closed or validated ledger, all transactions are executed in "canonical" order regardless of whether those transactions are trades or other types. It doesn't matter who was first if they are in the same ledger. The canonical order of transactions is essentially random, except that groups of transactions from the same sender are grouped and executed in sequence order. Open ledgers are different. Any given server's "in progress" open ledger has transactions executed in the order they arrived at that server. When the server "closes" the open ledger it actually throws out all this work and makes a new ledger by applying the set of transactions to the previous closed ledger in canonical order. That's why the provisional results from applying a transaction are just provisional; transactions are pretty much guaranteed to be reordered when a ledger goes from open to closed. As a reminder, there are three tiers of ledgers: The "open" or "current" ledger is an unreliable work in progress whose results are tentative, especially for hotly-traded exchanges. Every server's open ledger is likely to be slightly different based on which transactions they've seen in what order. The main reason rippled exposes the open ledger at all is that it's still pretty useful to know what other trades people are making in real-time if you have a trading bot or something. Open ledgers don't have a hash of their contents because the contents are expected to change anyway. A "closed" ledger is a set result of applying one set of transactions to the previous ledger. Two closed ledgers are guaranteed to be the same if they have the same set of transactions, the same parent ledger, and the same transaction processing logic—regardless of what order the transactions were received. Still, different servers may have different closed ledgers based on stuff like, if a transaction arrived just before or just after the time cutoff, or if a transaction wasn't offering a high enough transaction cost when the server was especially busy. (Or if those servers are running different versions of the protocol.) Closed ledgers have a hash of their contents, including the results of transaction processing, so if two ledgers have the same hash then they're actually the exact same; if they have different hashes then they're different somehow. So there may be multiple competing variants of a ledger floating around with the same ledger index (sequence number) but different hashes, which indicates either a different transaction set or the transactions were processed under different protocol rules. A "validated" ledger is a specific hash and ledger index that's been approved by consensus, so the validators all agree that this is the one and only canonical ledger for that sequence number. These ledgers are truly final.
  4. Useful rule: if an address has ever sent a transaction, it was not a black hole at the time. And the only way a non-black-hole becomes a black hole is if it changes its auth methods (e.g. the way Jon did) to disable all known ways of controlling it.
  5. A question about validators

    Yes, it's quite easy to create a fork. (It's only "slightly" tricky becasue rippled servers tend to want to connect to each other and then they get confused about why all their peers are talking about something completely different.) The hard part is getting people to use your fork instead of the main network that everyone uses, because the point of the whole system is that there's one main network that everyone uses.
  6. Things might make sense if you realize that, from the perspective of the RCL, the one who "created" the address is just whoever was first to send it enough XRP. Really, that's the person who "funded" the address. Someone else could've generated the address, and they may or may not know the private key of the address. (The more specific the address, the less likely it is to have been generated from a known private key. So the Stellar address is all-but-certainly a black hole.)
  7. A question about validators

    There's only one way to create more XRP, which is to redefine the protocol and get it approved by a vast majority of trusted validators (~80%). There are a few different ways this could look, but ultimately that's it. You could implement and propose an amendment to the protocol using the amendment system. Introduce a new transaction or pseudo-transaction that generates XRP from nothing. (Stellar-style inflation, for example.) In addition to the usual challenges, this involves a 2-week waiting period. Create transactions that generate XRP in violation of the existing protocol. You'd have to change the rippled source to execute these in a different way than usual, or manually generate a ledger that has these transactions executed in an abnormal way. Then you have to get those transactions / validators approved by the consensus network. (To fraudulently confirm transactions requires control of ~80% of trusted validators, per the consensus whitepaper.) In effect, you're making de factor changes to the protocol to add exceptions for specific cases. Implement a custom version of rippled that has a different protocol, then get 80% of trusted validators to switch to this version of rippled. This is like the amendment system but without the courtesy of a 2-week waiting period. (You could put your changes on any other sort of switch you wanted. In the past, Ripple has basically does this with timed switches for benign reasons, like fixing bugs/exploits in transaction processing.) Actually, there's one other way to create XRP: Hack at least 80% of validators in existence and edit the databases containing ledger data to change the record of what transactions and balances exist. No protocol changes necessary—just rewrite (the recorded) history! To be honest, one of my greatest fears and reservations about XRP right now is that, while Ripple still controls all the validators, stuff like this is merely "very difficult", not completely and utterly infeasible. I should mention, by the way, that if any of the above happened, the people who are running untrusted validators or non-validating servers would follow along what their trusted validators do by default, but they could get together and roll back to a prior version of the ledger, then change their configs to change which validators they trust, to fork away from the version of the ledger with changes they didn't like. (Sort of like what happened to ETH vs. ETC, but with a config change instead of a code change.)
  8. Yeah. Starting with this address encoding code, here's what I ended up with to reproduce the ACCOUNT_ZERO value in Node.js:
  9. No, it cannot be mathematically proven that any given address is a black hole, for the same reason that one cannot guess the private key for a given public key. "Known black hole" addresses are addresses that seem spectacularly unlikely to be generated from key generation. For example, ACCOUNT_ZERO is an address for "000000000000000000000000000000000000000000" (the r's are 0's in Ripple's Base58 dictionary, and the "hoLvTp" part at the end is the checksum, the first four bytes of the sha256 of the sha256 of 000000000000000000000000000000000000000000. There are two ways to choose an address out there: decide on the private key first, or decide on the address first. In the case of the private key, you can do some calculations and end up at an address. In the latter case, you can't go backwards, so you've probably just picked a black hole. The problem is, if someone points to an address and says, "This is an address I picked, and definitely don't know the private key for," people have no way of knowing whether that person is telling the truth or lying. There are lots and lots of ways the person could have generated a random address and not know what the private key is, but how can you know for sure what they did? The less random the address looks, the less likely it is that the person picked a private key first. Zeroes all the way through is about as non-random as it gets. There are "vanity addresses" out there—ever notice GateHub's address starts with "rhub" and their hot wallet starts with "rhot"?—but those are limited to a few letters at the beginning; the remainder of the addresses are just a random jumble, like rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq. Coming up with an address like that is the matter of doing "a few" attempts. Every additional letter you tack on increases the difficulty exponentially. For the entire address to be non-random, you're looking at the same difficulty as guessing someone else's secret key. Except, when you start with an address, you're not even sure such a private key that results in that address even exists. Background on why guessing someone else's secret key is impossible, which you may have read before: Public key cryptography only works because, given a particular public key, it's currently impossible to figure out what the private key is. Strong hash functions have a similar property—given only a hash value, it's impossible to know what preimage value results in that hash value. Ripple addresses are the RIPEMD160 hash of the SHA-256 hash of a public key, so to figure out the private key from an address, your options are: Solve three of the hardest problems in computer science (how to efficiently reverse ECDSA keys, SHA-256 hashes, and RIPEMD160 hashes). Invent a quantum computer with enough qubits to do the above. Try to find the private key by brute force ("guess and check"). This probably requires more energy than exists in the universe. So theoretically, there might be a key out there that maps to the public key 000000000000000000000000000000000000000000, but your chances of guessing it are about as good as your chances of guessing any other private key for any account in the ledger.
  10. https://ripple.com/build/ledger-format/#accountroot The "RegularKey" field tells you what regular key address is set for the account. The "Flags" field tells you what flags are enabled. You have to do bitwise-AND to figure out if a specific flag is set (unless that's the only flag set, then the Flags field is equal exactly to the flag's value). Here, here's some pseudocode to see if an address has been turned into a black hole:
  11. Transaction Volatility and FI's

    If the payment uses ILP and goes Fiat→XRP→Fiat, then the institutions on the sending and receiving side aren't exposed to any volatility risk in XRP exchange rates, but the trader/liquidity provider is the one exposed to the currency risk. For example, liquidity provider Mark agrees to an ILP quote and lock up 400 XRP in exchange for 100 USD. During the time before this ILP quote expires, the price of XRP suddenly skyrockets and that 400 XRP is now worth over 150 USD. Mark is still committed to the previously-agreed 400:100 exchange rate, so Mark ends up losing out on $50 USD worth of value he could've gained by not trading his XRP. Mark has to choose his exchange rates and expiration times to offset and minimize the chance of losing out like that all day long. If banks use XRP as a reserve and vehicle currency, they can minimize their exchange costs (consolidating many accounts in different places to just one XRP reserve) but that does mean they take on the volatility risk instead.
  12. Well, yeah. A totally unique building that lasts 8 years without falling over is pretty impressive, especially if it's built in a way nobody had done before. And a bunch of other buildings (altcoins) built using a similar process also haven't fallen over in the years since, so clearly proof-of-work is fairly safe under the conditions we've seen thus far.
  13. Yeah, ledgers 1 through 32569 were accidentally deleted early in Ripple's history when servers ran out of disk space. 32570 is the earliest ledger that anyone has a record of. The contents of ledger 1 are known (they were the default values for everything) but the events of ledgers 2 through 32569 can only be surmised by the state of the ledger as of 32570. Back on the original topic, there's a new amendment in voting now, EnforceInvariants, that adds an extra check to make sure that a transaction can't create XRP (or delete more than a transaction's exact transaction cost), among other rules. To be clear, all transaction processing already follows those rules, but after this amendment gets approved there will be an independent check to make sure that even in the case of a bug or something a transaction still can't break certain rules. (This was one of the ideas we started talking about after watching Etherium's DAO get wrecked: with sufficiently complex systems, we figure, more sanity checks are well worth the effort, and way better than having to fork or rewrite history to undo an exploit.)
  14. I'm pretty sure the reason nobody else (but Stellar of course) uses a "trusted validators" consensus protocol like Ripple's is that it doesn't scale to more validators automatically. The one really big deal with proof-of-work algorithms is they make it so any new server can participate in the validation process with no human intervention or configuration. That's possible because proof-of-work assumes that no malicious party can accumulate more computing power than all the non-malicious parties combined. When you look at it that way, it's really impressive because the fact that that Bitcoin and major altcoins haven't had a 51% attack yet is evidence that proof-of-work actually works. Starting from just a handful of servers, Bitcoin now has a huge number of mining servers worldwide participating in its "consensus" process. On the other hand, as we reach later and larger stages with greater understanding, we're now starting to see where it could go wrong. A few mining pools with subsidized electricity have gained inordinate influence over the blockchain. Does this lead to a 51% attack? We'll see. But it certainly does lead to huge backlogs of transactions and wasteful electricity usage. Ripple's consensus algorithm, by contrast, requires manual intervention to increase the number of validators. The people who run rippled servers have to manually choose which servers to add to their UNLs; and if they choose poorly, they could end up forking from the rest of the network. (For example, if you edit your UNL to include 20 additional validators that are all ultimately controlled by the same party, that party could dictate which ledgers and transactions your server thinks are validated.) To guarantee a lack of forking, the RCL needs two things: validators' trusted node lists must have sufficient overlap with one another; and the number of maliciously-colluding nodes in those trusted lists must be small enough. The exact math is in the consensus whitepaper, but basically it comes down to: consensus works smoothly as long as everyone in the network has more than 20% overlap in their UNL, and each server works well as long as no more than 20% of the validators in its UNL are malicious. There's also a huge gap between "there are enough malicious nodes to stop consensus" (>20%) and "there are enough malicious nodes colluding to confirm a transaction fraudulently" (>80%). There are some major upsides to Ripple's system, aside from the oft-mentioned efficiency & speed things, too. The RCL's consensus algorithm is not vulnerable to the same type of 51% attack, since malicious actors can't participate in the consensus process without convincing validator operators to add the malicious actors' validators to the trusted operators' UNLs. And, if you identify a malicious actor, you can remove that actor from your UNL and ask others to do the same, locking them out of the process. With Bitcoin, the only recourse you have is to amass more computing power to compete, or try to get people to manually recompile the software to blacklist mining servers you don't like. On a more esoteric note, if there's a case where two "cliques" of RCL servers really don't want to trust one another, they can "agree to disagree", remove each others' members from their UNLs, and amicably diverge, intentionally forking the network. (Server operators who are caught in between would have their server correctly report "no consensus" until they chose which clique to follow.) Ripple's plan is to move beyond this to a stage where UNLs are completely dynamic, too, which starts with the "Dynamic UNL Lite" code that debuted in rippled 0.60.0. This algorithm introduces the idea of a "validator registry" or "publisher" that lists validators. In the past, we also called this same concept an "attestor". The idea is that someone (probably Ripple first) publishes a list of validators they think are reliable, and you configure your rippled with a publisher instead of configuring your UNL directly. You can also add multiple publishers to choose from all their lists. (Eventually we may add a score attribute to the list format, too.) Your rippled periodically fetches the latest list and updates its UNL automatically to a subset of the results. It's possible to have multiple publishers supporting the same network, as long as their lists of validators have enough overlap. It might also be possible to have a parallel network by using a publisher with a completely separate list. For example, the Ripple Test Net would have its own registry with a completely separate set of validators that are all on the test net.
  15. Transaction Volatility and FI's

    The more usage it gets, the lower the volatility should be. Also, compared to Bitcoin, XRP settles so fast that you're not exposed to the volatility risk nearly as much. That said, it's certainly a concern. If you look at our math on using XRP for currency conversion, we outline a "high-volatility" scenario where XRP is about 2.5× as volatile as the fiat currencies. The nice thing is that you save so much on other costs that it's still cheaper in total to go through XRP.
  16. Hacking XRP

    If you were thinking of brute-forcing XRP secrets, I highly recommend you put that effort into studying public key cryptography. Not only do you have a higher chance of cracking someone's secret key before you die of old age, you're also far more likely to develop useful skills that can earn you a lof of XRP in actual legal income. Yes, it's entirely possible that someone may invent a new algorithm that makes it far easier to decipher private keys from public signatures. (If they do, no money is safe.) Brute-force ain't gonna get you there, though.
  17. Decentralization implementation

    Well, their validator is a subdomain of this page... http://worldlink-us.com/
  18. All accounts are only subject to the current reserve. Maybe you forgot to factor in the additional owner reserve in your testing? Also, XRP allocated to the reserve can be destroyed to pay for transaction costs, so it's not completely out of circulation in the same way that destroyed XRP is. I think a more interesting number is how much XRP is owned by black hole accounts. The total owned by the known black holes is pretty small though (less than 200,000 XRP).
  19. Development support

    It's hard to stay cool sometimes, but then I remember just how much work we still have to do. But seriously, I'm most excited about the stuff that's open-source anyway so I have less to worry about.
  20. Yes, "Ripple Charts" is now "XRP Charts". I don't actually know why we made the name change, but I can tell you it's official.
  21. Article Posted Yesterday

    That's a consciously-reinforced company culture thing. We're trying to be constructive and build bridges, not disruptive and destructive. We pay attention to other tech, but we mostly spend our effort improving our own and talking about how good ours is. In particular, we make it a point not to trash-talk other crypto-currencies. We'd rather trash talk the completely outdated legacy payment systems banks are using today.
  22. Development support

    I think Interledger is building up a pretty sweet set of features and tooling to enable micropayments. With the now-robust features to support Interledger stuff in RCL, these are a natural fit. Meanwhile, the W3C and browser developers are working on building the interfaces to request payments right into browsers themselves. Meanwhile, better support from new and existing exchanges has made it far easier to buy XRP. So yeah, I'm not going to be writing a tutorial for how to buy XRP with a credit card (hint: debit/credit payments are reversible but XRP payments aren't so that's a bad idea for the seller) nor how to set up sites for micropayments just yet... but I think those things will be coming from somewhere in the next few years. It's all part of the bigger picture of "enabling the internet of value" as we say!
  23. Pretty much what T8493 said. If you want the current (latest) orderbook status, you should call a rippled server directly. The Data API mostly serves historical / not-live data. It's especially important with orderbooks that you probably want to work from the in-progress current open ledger, not the most recent validated ledger. Although the data you see that way isn't final, it includes transactions that are likely to become final within the next 3-5 seconds. The Data API mostly does not serve that kind of up-to-the-second in-progress data (it mostly gets its data by importing ledgers that are already closed and completed). I can't directly link you to the API results because the JSON-RPC API needs you to do a POST instead of a GET request, but it's still simple enough to pull such data with a tool like cURL or other HTTP clients. (It's a little harder to do from a browser because of the browser's same-origin policy. Oddly, WebSocket requests are generally exempt from browsers' same-origin policy so you could do that.)
  24. Most Data API methods can return CSV data directly, but I think this one can't. (The docs say that it can, but I think that's a doc bug, which I should fix.) I think RCL transactions are irregular enough that CSV data would be kind of tough to format sanely.
  25. Making your rippled ghostly

    To run a node with a "private" location, you need to run (at least) two rippled servers: A public-facing rippled server whose IP address will be known. Better yet, run a cluster of such servers. A private rippled server whose IP address will not be known. Its node public key will be known, but that's meaningless (rippled servers just generate a random one when they start if they don't have one defined). Its validator public key will also be known, if you configure one. (That's how other servers know that a validation message is from your validator if they trust you.) You configure your private rippled server to peer/connect only to your public-facing server(s). You configure your public servers to connect to the network at large and also your private servers, but not to relay the IP addresses of your private servers to the rest of the network. (That's what peer_private is for.) As an analogy, it's kind of like having a very important person do all their business through signed messages carried by carefully-vetted couriers. Everyone can see that the VIP's messages are genuine because they're signed and everyone can send messages through the couriers to the VIP, but nobody besides the couriers gets to talk to the VIP directly so nobody knows where the VIP lives or works or what the VIP looks like. This is Ripple's recommended way of running high-security validators, by the way.