Jump to content

mDuo13

Ripple Employee
  • Content count

    240
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27

mDuo13 had the most liked content!

About mDuo13

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. Thanks! That's good feedback on the "drops" bit. I'll add a reminder. As for the tx hashes, I'm not sure which hashes you're asking for... the ones in the tutorial are all on the TestNet, which means they're ephemeral because the TestNet gets reset regularly and as far as I know there aren't any servers that keep a long history. If you're asking for the Escrows of Ripple's huge XRP stockpile, I don't think they've happened yet.
  2. Personally, this is also my biggest worry regarding XRP. Fortunately, I have the privilege of being able to complain to the devs about this on a regular basis, so they've been putting together various work to make it happen. ("Dynamic UNL Lite" from v0.60.0 was one of the biggest steps so far.) But before I talk more about that, I can answer your question on Bitcoin et al. Basically, mining solves this problem with a "might is right" approach. You trust whoever is lucky enough to get the correct hash first and follow whichever is the longest chain. Each round, only one vote matters (whichever one is first to share the "correct answer"), but the total number of attempts to vote is based on your hashrate. This is really the biggest difference between the XRP Ledger and every other "blockchain" technology and it's the source of many of the major advantages and drawbacks that the XRP Ledger has over Bitcoin: With Bitcoin, you need to know which chain is longest, so you have to sync for hours downloading the chain history. With the XRP Ledger, you just ask your validators which ledger is the latest and then trust them, so you can grab a snapshot without the full history. The XRP Ledger is fast and doesn't waste electricity because there's no mining. But with the current system, you have to manually adjust your settings if you want to scale the size of the validation pool up or down. If everyone does this, you have to be careful not to create a topology that makes it hard to reach consensus, or (unlikely) forks the network. Bitcoin's "validation pool" scales automatically based on the global hash rate. Ripple's long-term plan has pretty much always been to define an "Attestor" or "publisher" service, which anyone could run, to list and rate validators. Then, when you run a rippled server, you would just pick an attestor rather than picking a UNL directly; you'd choose your validators based on what the attestor said, or possibly based on what a group of attestors say. At the moment, I think the next step in the process is setting up our own proper attestor and switching over the code to use that rather than just relying on the default validators from the config file. I don't sit close enough to David Schwartz to know for sure, though. Anyway, definitely keep an eye on "trust agility"—it's a major challenge in these kinds of systems, and the XRP Ledger won't be the first to have to tackle it. Speaking of which, does anyone know a good way to rotate PGP keys?
  3. There's a new tutorial for exactly this, just published within the past hour! https://ripple.com/build/escrow-tutorials/ Feedback appreciated. Extensions already planned include a mini-tutorial for how to cancel an expired escrow and a concept article explaining the basics at a higher level.
  4. XRP lockup

    Because the XRP lockup is scheduled to happen this quarter, I'm working on better docs around how the Escrow feature of the XRP Ledger works. If you want to know more about XRP Escrow, there's a new set of short tutorials for it here: https://ripple.com/build/escrow-tutorials/ More docs to come on Escrow, including some more high-level conceptual background information, tutorial on how to cancel expired escrows, etc.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.)
  11. 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.)
  12. Yeah. Starting with this address encoding code, here's what I ended up with to reproduce the ACCOUNT_ZERO value in Node.js:
  13. 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.
  14. 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:
  15. 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.
×