Jump to content


Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by mDuo13

  1. The answer to the first question is "almost" and the answer to the second question is "no". You must sign transactions to trade on the XRP Ledger. You may sign those transactions using a signing library without running your own rippled server, then submit the signed transactions to a public rippled server, and that's safe & secure. Basically, if you sign the transactions using JavaScript, you don't need to run rippled. Of course, you may still get benefits out of running your own rippled server since you don't have to share with everyone else like you will if you only use the public servers, but the maintenance burden is definitely lower using the public servers. In JavaScript, the library that has signing is RippleAPI , also known as ripple-lib. If you're using C++, you can use ripple-libpp to sign the transactions. There aren't any other supported signing libraries right now. (If you want to implement signing in another language, that would be quite an undertaking.) And as I warned before, if you're calling rippled's sign method via anything other than localhost, be sure you use an encrypted connection (HTTPS/WSS not HTTP/WS) or intermediaries might "overhear" your secret. On localhost, unsecured HTTP/WS is fine because the message never leaves your own machine. The "submit" method —if you're submitting already-signed transactions—is OK even over unencrypted HTTP/WS because those signed transactions don't contain anything secret.
  2. It's very likely that making it easy to move money will cause money to move a lot more often. It's very hard to know by how much. If you consider snail mail vs. email as a point of comparison, the numbers are inspiring.
  3. What tulo said is all true. Also, you don't have to write JavaScript code to trade on the decentralized exchange. You can use rippled's JSON-RPC interface from any language that has an HTTP client, including Python. For example, here's some code I wrote to query a rippled instance directly from Python: https://github.com/mDuo13/txsplain/blob/master/txsplain.py#L191-L215 The biggest advantage of JavaScript is that there's an official library that (among other things) can create signed transactions natively in JS so you don't have to be running your own rippled instance to get trusted signing. If you're using any other languages, you basically have to run your own rippled server if you want to get secure signing. IMPORTANT WARNING ON SIGNING: Don't use the "sign" command of rippled instances you don't control, because whoever runs the server can save your secret and use it to take control of your account. Same goes for the "submit" command in sign-and-submit mode. And even if you own the server, don't use HTTP (do use HTTPS) if the rippled is not running on the same computer or your own sub-network. HTTP traffic isn't encrypted, so random intermediaries could read the unencrypted traffic (with say, a packet sniffer) and also learn your secret. HTTPS traffic is safe as long as it's configured correctly. (An example of incorrect configuration would be if you use a self-signed cert and you don't verify that the rippled is using that exact same cert or CA; in that case a man-in-the-middle attack could present itself to you as if it's your own rippled server using a different cert.) One other important thing to keep in mind when trading on the XRP Ledger's decentralized exchange is that transactions are only processed when a new ledger closes (approximately once every 4-5 seconds), so you can't do "high frequency" trading. If a particularly juicy trade appears in one ledger, you are fighting with everyone else who notices it within about a 4-second window. Oh, and https://ripple.com/build/reliable-transaction-submission/ is worth a read, so you can be sure when you submit a transaction that it'll reach a final outcome (succeed or fail) within a sensible timeframe. That said, good luck, and welcome to the realm of XRP Ledger traders.
  4. Host application on XRP

    Those instructions are slightly outdated because they don't cover the validator list site settings. For a personal test network, you can remove the validator list site stanza and hardcode the validator keys to trust. I won't go into detail, because generally speaking, Ripple does not want to make it easy to start parallel XRP Ledger networks. (Most of the time, the test net is plenty. The exception, which matches this case, is if you really want to test differences in the consensus algorithm itself.) You may want to read https://ripple.com/build/stand-alone-mode/ to get a better sense of how to run rippled in testing mode with a new genesis ledger, since there are some gotchas. For starters, all amendments will get enabled starting with ledger index 2. For another thing, the default reserve settings are different than the production ledger's settings. There are a also couple edge cases that work differently when you're not missing ledgers before 32750 as the production ledger history is (I don't remember all those offhand).
  5. There's a reason we're not incentivizing people to run validators. An incentive is a way to encourage people to take certain behaviors. Which behaviors? Well, the ones you're incentivizing, of course! Right? Except, you probably aren't incentivizing the behaviors you think you are. Incentivization prompts behavior that maximizes the reward and minimizes punishment. This isn't always the thing that you wanted to reward. If you shout at your puppy for pooping in the house, he still has to go but now you're scary, so he'll only do it when you aren't looking. If you give a dolphin fish for picking up trash, it'll stockpile trash and rip it into small pieces so it can get more fish. If you teach an A.I. to play tic-tac-toe, it might discover the most reliable way to win is to crash its opponent. Not to mention that incentivizing charitable behavior sometimes causes people to view it less charitably. If you make alcohol illegal, you might just prompt crime to get organized. A long time ago (before I started at Ripple, actually), the company tried to incentivize a developer community by giving users XRP if they authenticated their GitHub account. Within hours, they received a phone call from GitHub's offices, asking Ripple to stop DDoSing their new user sign-up. If you give Bitcoin out to people for confirming new blocks of transactions, you might end up with a tiny number of mega-mining pools, who'd rather charge higher fees than process more transactions. A certain other Ripple employee put it more succinctly: We don't want bad things to happen to the XRP Ledger because we rewarded people for the wrong thing. In fact, we don't even want to throw away XRP on incentivizing something that's merely neutral. The point of the XRP Ledger is to provide a public good that benefits everyone it can. Ripple could pay people to run validators. But where's that pay coming from? XRP's supply is finite, so they couldn't get paid forever. They might threaten to stop running validators, endangering the network if they weren't being paid anymore. Or they might simply stop if the pay wasn't sufficient anymore. Either way, that's bad for the network if it happens. As long as running a validator isn't too expensive or difficult (things we're still working on improving), then we're confident the people and institutions who should run validators will end up doing so for their own and the public benefit.
  6. The "request" method that uses is an in-progress new method for making raw requests to rippled in rippled's native websocket format. That method, and the subscription event handling, are not final right now and not really documented yet (to my knowledge) outside of the stuff you see on GitHub. I did (just now) update the RippleAPI docs on https://ripple.com/build/rippleapi/ for v0.19.0, which includes Checks functionality.
  7. Ripple Data API v2 rate limit

    I don't think the Data API v2 has formal rate limits right now. I've overheard that the Ripple data team has had problems with some people/businesses taking advantage of that, so we're likely to impose proper rate limits in the future. And yes, the rate of "OfferCreate" and "OfferCancel" type transactions definitely outstrips the rate of "Payment" transactions in the XRP Ledger. I think that's mostly a nature of the beast; trading is kind of speculative and freeform while payments generally only happen when you need to move your money from one place to another. Especially since there aren't many merchants who accept XRP (Ripple has not exactly pursued that use case so far), there's not as many opportunities to pay people.
  8. Personal Validator / Server

    You may want to do some more reading. Adding a validating server wouldn't impact TPS positively. (I believe the main limits on TPS are disagreements between servers, and the slowest trusted validator's time doing things like verifying signatures... assuming the trusted validators all have sufficient I/O to meet their needs.) Most likely, adding a new validator will have no effect, although it could in theory decrease TPS by increasing the communication overhead with the other servers on the network. Right now the XRP Ledger isn't that close to capacity on throughput, though, so the easiest way to increase TPS is by... sending transactions. Right now, most people who're running their own rippled server are either businesses like exchanges that offer XRP, or individuals running arbitrage bots to trade in the decentralized exchange that's built into the XRP Ledger—or trade in off-ledger exchanges and bridge the gaps between them. (I know there are least a couple people who make a tidy income doing that kind of stuff.) I'd love to see more creative, interesting uses of the XRP Ledger. If you're a data scientist, you may want to look at the Data API and see if the stuff they're collecting interests you. That code's mostly open source, so you can even run your own historical database if you want to pull the data locally and analyze it yourself (although I think some of the import scripts for certain types of data are closed-source).
  9. Could you imagine the fudstorm if...

    Hey, curing (one person's) hunger and ending (one person's) homelessness are real problems. They're just, you know, small scale. That said, I don't know of any big real-world problems that can be fixed with quantum computers. There probably are some, but it may be that nobody has figured out yet what problems really need quantum computing algorithms, outside of some cryptography things. Right now, the really fascinating thing about computer science is that most problems are about figuring out what approach can achieve the outcome you want with the fewest unexpected consequences, not so much about how to make things go faster. For better or for worse, it's become as much about figuring out humans as figuring out math.
  10. The quorum and the UNL overlap are different (albeit related) things. The overlap is something like, "If my UNL has validators A through J and your UNL has validators C through L, then we have 80% overlap (8 validators in common out of 10 each)". The quorum is, "If I see 8 of my 10 validators declare a consensus for ledger 100, then I'm declaring ledger 100 validated". These papers don't change the rules for the preferred quorum, which remains at ~80%. They do change the expectations for overlap (topology) requirements though. The disappointing result of this consensus research is that a fork between two rippled servers is technically possible if the UNLs of those servers, or the UNLs of the validators they trust, don't all have >90% of the same trusted validators in them. When the original Ripple consensus whitepaper was published, its authors thought that servers only had to have >40% UNL entries in common with one another. What they failed to account for was the possibility that a malicious validator could send contradictory messages to different servers. The peer-to-peer network broadcasts messages between a bunch of servers (even non-validators pass on messages) so the original authors thought you would easily notice that a validator was acting maliciously if it sent contradictory messages to different parties. The standard rule in the research is that you may not notice this because the unreliable network might drop the contradictory messages in such a way that the contradictory messages don't both reach you, or the network could delay some of the contradictory messages long enough that you don't realize there's foul play going on until it's too late and you've already taken action. In short, when network conditions are bad, the UNL topology has to be a lot more interconnected than we thought, or malicious actors could cause a fork. The good news is: first, the current plan, using a validator registry (the list site), is safe, because anyone using the validator registry has 100% overlap with everyone else who's doing the same. (It makes it harder to open things up to multiple validator registries, though—if those registries don't have >90% of the same entries on them, then forks would be possible.) The other good news is that we (well, mostly Ethan) have come up with a new algorithm called Cobalt that only needs >60% overlap and also has some other neat properties, like that you don't have to worry so much about the UNLs of the servers in your UNLs.
  11. Rippled 0.90.0 Released

    A few new articles that we released recently, some related to 0.90.0, some catching up on older features: Summary of how master and regular keys work: https://ripple.com/build/cryptographic-keys/ Also, a corresponding tutorial on setting and removing regular keys: https://ripple.com/build/working-regular-key-pair/ Explanation of the History Sharding feature: https://ripple.com/build/history-sharding/ Expanded content on Authorized Trust Lines (formerly called Authorized Accounts, much of this content is ported from the Gateway Guide): https://ripple.com/build/authorized-trust-lines/ Also, in case you missed it: Checks docs ( https://ripple.com/build/transactions/#checkcreate and others) and Deposit Authorization ( https://ripple.com/build/deposit-authorization/ ) Reminder: if you're connected to the Test Net, you can try out these new amendments before they go live on the production XRP Ledger.
  12. RippleNet and it's parts

    Sorry, @Lumpy, you've done a lot of research but it seems you've misunderstood xRapid. The transfer from one exchange to another happens on the XRP Ledger. As you noted, it wouldn't have to do so. But for ownership of XRP to change without a transaction in the XRP Ledger, the two entities doing business would have to have a relationship with one another where they tracked who owns what. (In other words, at least one would need to have an account with the other.) That's basically how correspondent banking works today and it's why we have all these "float" relationships tying up trillions of dollars' worth of value worldwide. The beauty of xRapid is that the exchanges don't have to do that. XRP doesn't know national boundaries and it's so cheap and fast to transfer that the exchanges in question don't have to know each other; you can just send XRP from one to the other. The xRapid customer just needs to open accounts at both exchanges (and the balance sitting around on the receiving end can be minimal or zero). I agree. The nice thing is, the functionality in the XRP Ledger isn't going away, there are still advantages to it, and I think we may eventually reach a point where people use it more. But for now, trading in off-ledger exchanges or connecting payments of different assets via ILP Connectors is the way to go. Sadly, one of the major reasons that Ripple isn't pushing for companies to issue non-XRP currencies on the XRP Ledger right now is a regulatory one. My understanding is—and mind you, I am decidedly not a lawyer, so this is likely to be a poor representation of the proper rules—that there's a key difference between businesses that enable "two party" transactions and "three party" transactions. Issuing gateways end up looking a lot like they're enabling three-party transactions (person sends money to gateway, gateway sends money to third party) which in the USA means you need money transmitter licenses, which are different per state. Meanwhile, exchanges only facilitate two-party transactions (person gives asset to exchange, same person comes back with different asset from same exchange), which means they don't need the same type of license and they don't need 50+ different ones just to operate in the US. So in other words, it's kind of a quirk of the USA's regulatory environment that gateways need to spend way more time and money getting proper licenses than exchanges do, even though theoretically what gateways are doing is simpler.
  13. Yes, that warning is specifically for the case of you forking away from the network. Suppose your server is configured to trust the original 5 Ripple Labs validators only and not the new validators that are being added to the rest of the network. Those validators—and indeed, most of the network—are following the official validator list site as Ripple adds new recommended validators in the coming months. A consensus round could occur such that the 5 validators you trust all support a particular proposed ledger. Meanwhile, several of the other validators you don't trust yet support a different ledger, so less than 80% of the network believes a consensus has occurred but by chance the subset of servers you see all agree. Now suppose further that you received a transaction in that ledger. Maybe you're waiting on a deposit of XRP before you send the person a different cryptocurrency, say, LTC. So you see this proposed ledger, which has support from all the validators your server trusts. This leads you to think that ledger (with the transaction you received) is final, so you send off the related payment of LTC in the Litecoin network. Then the rest of the consensus process happens, and the validators you trust change their votes for a final validated ledger—because, as mentioned, as far as they were concerned it wasn't final yet. And due to the different transaction set in the actual final, validated ledger, the transaction that sent you XRP doesn't succeed. Now you've acted assuming a particular transaction was final, but because your server forked away from the network, the transaction didn't happen as you thought. Meanwhile, the LTC transaction you've sent separately is still happening and you can't do anything about it. So potentially, you've lost money. As long as your validator set has 80% overlap with the rest of the network, this won't happen. But if you only trust the old 5 Ripple Labs validators as they become outnumbered by the dozens of new validators on the recommended validator list, it becomes increasingly likely. And if you choose validators willy-nilly you might end up choosing validators that go down or lag, or just happen not to be trusted by many others, so their votes on what ledgers are valid have little influence over the rest of the network.
  14. I think people are interpreting my comments about xCurrent's atomic mode ILP and ILPv4 to be more concrete or specific than I intended them to be.
  15. Last night we added several new pieces of documentation to the XRP Ledger in preparation for the upcoming release of rippled 0.90.0: Deposit Authorization is a new feature for compliance with regulations such as the New York Bitlicense. In addition to the concept page, the flag has been added in appropriate places such as the AccountSet transaction reference. Checks documentation has been added to the transaction reference and ledger reference. Checks are a feature originally conceived back in, like, 2012 or something, which got new life recently when we realized they'd solve one of the challenges with Deposit Authorization. We also added specific instructions for how to build and run rippled 0.90.0 and higher on Ubuntu Linux. That's important, because rippled 0.90.0 must be compiled against the latest version of Boost, which now includes Vinnie Falco's Beast library (originally developed to use in rippled). There'll be more coming out in the coming days, including an article on another key 0.90.0 feature, history sharding. I can't give a specific release date for 0.90.0, but the feature set is final, as we're just now polishing up the details and ironing out the bugs. As per usual, it'll be out soon—when it's ready—and no sooner. P.S. if you want to try out Checks and Deposit Auth leading up to the release, they're already available for use on the Test Net.
  16. There's no mathematical reasoning behind it. It's just a convention because professional traders are used to seeing quotes with the ratio in a specific order.
  17. Policy of deleted offers

    Yes. Here's a statement to remember: Changes to the XRP Ledger's state are always¹ the result of transactions (or pseudo-transactions), and transaction metadata always describes all such changes. ¹ There's an exception, because of course there is. It's the "LedgerHashes" object type in the ledger, which tracks ledger history for easy lookup. Objects of this type get added or modified when closing a ledger. There's no pseudo-transaction to track this, it's just part of the "close" process. (It adds the parent ledger's hash to the list, and starts a new page if necessary.) But this is really the only exception. Things expiring or being removed always happens as a result of a transaction.
  18. Policy of deleted offers

    Processing other people's payments and offers that matched yours, largely. Only the offers it touches are deleted. So as long as the transaction executing your offer doesn't dig that deep into the order book, the others are safe. I think you can just watch account_tx for the account placing the offer. If an offer is deleted, it'll restore the owner reserve for that offer (5 XRP at current rates) so it should show up in your account_tx as a transaction that affected your account. You have to look at the metadata to see exactly what happened. (Offers that were removed as unfunded will show up as "DeletedNode" entries in the metadata.)
  19. xCurrent transactions do not use the XRP Ledger. They are, by default, not public information. XRP Ledger transactions are all public knowledge. It takes some work and some speculation to figure out who's who and what those transfers represent, but you can see the full transaction history. You don't necessarily know the context around the transactions, though—for example, is a given XRP transfer an aggregation of several smaller transfers, or a rebalancing to other private transactions you haven't seen? xRapid payments are a mix of the two. The trades that occur in a given exchange are known to the exchange and maybe those closely watching the exchange, but the deposits and withdrawals aren't. The XRP transfer that links two exchanges is public. And the payments that happen at the endpoints are private. So you can surmise some of the picture by watching XRP movements, but again, you have to make inferences about the context.
  20. Policy of deleted offers

    @raktaktak pretty much has it. There's no periodic purge or anything. Whenever an offer is matched—whether at the time it's placed or later when it's crossed by another offer—the engine executes as much of the match as possible. If the placing account doesn't have the funds to execute the whole offer, it executes as much as it can and then deletes the offer from the books (or just doesn't place it onto the order books, if this happens at the time the order is initially placed). If the offer isn't matched, or is matched for an amount that doesn't use up all the available funds being offered, then the offer can stay in the order books. The rest of it can be executed later if another offer matches it. It's fine if the availability of the funds offered increases or decreases in the meantime. When the offer is matched again, it's re-evaluated to see how much funding is available at the time, and it'll stay or be deleted based on whether there's anything left after executing the match for as much as possible. When you initially place an offer that doesn't match any existing offers, it'll only go into the orderbooks if you have a positive amount of whatever you're offering, but you don't have to have the full amount. Even $0.00001 is probably enough to place an offer to sell $9999999. (Technically I think the exchange rate for what you're trading for mustn't round to zero or infinity.) Or, if you're offering a currency that you issue from the same account, you have to have room on trust lines to issue a nonzero amount of that currency, but again you don't need room to issue the full amount at the time you place it.
  21. How is xVia supported?

    Not quite. Both xVia and xCurrent do pathfinding. xVia is (at present) more like a slimmed down xCurrent interface for entities that don't want or need to run the whole suite of xCurrent functionality. Banks who're storing lots of value and facilitating exchanges across different currencies or countries (even same-currency)? They'll want xCurrent, complete with Messenger, Ledger, FX Ticker and Validator components. Payment originators who keep their money at a bank and just want to send (or receive) payments? They'll want xVia, which has a preconfigured Messenger and maybe a Ledger depending on the customer's needs, but relies on partners' and intermediaries' xCurrent instances for the other stuff. The two products are pretty similar, but targeted at different categories of customers with different needs.
  22. How is xVia supported?

    xVia sources liquidity from other members of RippleNet, who provide liquidity today by running their own xCurrent instances. When xRapid becomes fully integrated into RippleNet, xVia will be able to source liquidity that way too—via whichever path is currently the most rapid, cost-effective, etc. (puns intended)
  23. ILPv4 is fantastically simple, and I can't wait to see more services using and implementing it. It's really versatile and I love how the model has evolved over time to become even more compatible and generic. I can't divulge our future plans for xCurrent, but I can clarify any confusion on the current tech. As of right now, the latest xCurrent release does not use ILPv4; it still uses a proprietary Atomic Mode ILP variant and has its own validators (formerly called notaries). Part of signing on to RippleNet is signing contracts defining how you choose xCurrent Validators (any xCurrent installation where you provide liquidity between multiple currencies or institutions, you also run an xCurrent Validator). I believe the long-term plan is to continue developing both the tech and the ecosystems for ILP universal mode and atomic mode until they meet in the middle. Once they do, plugging atomic mode and universal mode together should be easy compared to what it takes to plug existing ledgers together.
  24. The story is slightly different for escrows that are held based on crypto-conditions instead of time-locked. If the hash function is broken so people can easily create hash collisions, then someone could make their own valid fulfillment and release the funds without going through the person who was supposed to release it. That said, as far as I've seen SHA-256 (currently used by all crypto-conditions in the XRP Ledger) isn't any more likely to be broken by quantum computers than just regular computers. And even in the case that something's released, it still only goes to the intended destination address, which is set when the escrow is created. As long as the destination address is locked with a secure key (as Nik describes) then it's not like some third party can steal the funds. But really, conditional escrows are meant for short-term locks (Interledger payments, which should take seconds to hours depending on the slowest link in the chain) not multi-year lockups. I'm more concerned about Ripple's "Year 2068 problem" where the XRP Ledger's 32-bit time format overflows. You can't even schedule time-based escrows to expire past then! And upgrading the timestamps will involve modifying the ledger header, which is one of the oldest, crustiest, hardest-to-update pieces of the XRP Ledger. The good news is, that particular deadline is approaching at a very predictable rate.
  25. I'm not sure what all the circumstances are that might make this possible. It's not impossible you found a bug in the Data API's balance changes method. (It's processing and storing a lot of transactions, so it wouldn't be that surprising if it had bugs for rare cases, especially on old data.) It's also possible something else happened. Like, maybe Bitstamp's USD balance going negative really early could be the result of them having a trust line configured backwards (so the cold wallet was trusting the hot wallet instead of the other way around?) or something along those lines. Especially in the early days before all these conventions were defined for how trust lines and whatnot should be used... I pinged the data team to see if they could take a look at this, but this is just a tiny drop in the firehose of XRP Ledger data...