Ripple Employee
  • Content count

  • Joined

  • Last visited

  • Days Won


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. Well, their validator is a subdomain of this page...
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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!
  7. 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.)
  8. 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.
  9. 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.
  10. To be totally certain, you should combine the tx_hash, the provider, and the offer_sequence. An "exchange" in the Data API is any instance where all or part of an offer was executed, so there are a lot of ways that individual "exchanges" could look alike: A single Payment transaction can flow through several offers for the same or different currency pairs, and an OfferCreate can flow through several offers in the same currency pair (as it digs into the order book) so tx_hash by itself, or tx_hash and buyer/seller/provider/taker, isn't sufficient. Existing offers in the ledger are unique identified by the pair of account that placed them (provider) and the sequence number of the transaction that created them (offer_sequence). So provider/offer_sequence uniquely identifies a single offer, but that offer could be executed in multiple "exchanges" if each only took part of it. The "offer_sequence" is just a number for each account that increments as you send transactions, so it's likely that offers from different accounts have the same offer_sequence occasionally. ("Oh, that was placed by your 100th transaction? What a coincidence, mine too!") So you need to use the provider to distinguish offers taken by the same transaction, placed by different accounts at the same sequence number. Any single transaction can only go through an individual offer a single time, so I think the three-part key is certain to be unique.
  11. That's pretty awful. I have an HP EliteBook! Luckily, the first thing I did with it was format the hard drive and install Arch Linux, so I think I'm OK.
  12. It also occurred to me, if it's on the original Ripple client, it might have used the Blobvault. Hopefully your ripple-wallet.txt file isn't some sort of blob that needs a signature from the old Ripple Trade auth server to decrypt...
  13. I looked up your address rD7SfizZYJrbNBFDtku972tnzwRThu7C35 using the RPC Tool. Good news! Your XRP balance (30781.000003 XRP) is indeed there, and there are no signs that your account has been "re-keyed"; there's no regular key set and the flag to disable the master key is also not set. Fun fact: the last transaction to modify your account was from 2014. So you haven't ruined everything with a mis-click. As long as you can figure out what your secret key is, you should be able to get full control of your XRP. The typical format that secrets are written in looks like this: snoPBrXtMeMyMHUVTgbuqAfg1SUTb However, there are other formats the secret could be in, including as a passphrase. (Ripple condenses those down to the above format, basically; in fact, the above example is the secret key derived from "masterpassphrase".) It sounds like your secret key was probably just generated at random and then whatever client you were using at the time (the official one?) just stored it in a blob that was encrypted with a passphrase, so this is a super long shot unlikely to work but you could try it. If you can run your own rippled server, even in offline mode, you can try generating wallet keys using wallet_propose and passing anything you think might be the passphrase as the "passphrase" parameter. (You can leave out the key_type since yours is definitely secp256k1 because it's from before we had ed25519 support.) If you got the right one, the response will show "rD7SfizZYJrbNBFDtku972tnzwRThu7C35" as the account_id field. Don't do this on someone else's rippled server since that could be giving away your secret. Since doing key generation like this doesn't actually require network connectivity, you can run rippled in stand-alone mode to save yourself some bandwidth and CPU. Installing rippled is not exactly easy, depending on your OS, so this is a bit of an extreme step (but maybe worth it for 30k XRP!). If you're on Windows, you have to compile from source with Visual Studio 2015. It's a lot easier if you're on Red Hat Linux or Ubuntu. I don't know if the Mac installation instructions are even updated. Anyway, if you get it installed, you start rippled in offline (stand-alone) mode like so: rippled -a --start Then you could use the commandline to try generating wallets from whatever might be your secret(s), but I prefer to use the Firefox Poster extension myself. I've attached a screenshot of what it would look like to try generating a wallet from a passphrase there.
  14. Why the bird analogy and not a water analogy? What size of Ripple Wallet would you like? Thermos, Tub, Pond, Lake, Sea?
  15. Here's an excerpt from the docs that might help you: So just look for a Link header with rel=next and get that URL to get the next page of results in CSV format. Then you just have to find a way to combine the results together, which could be as simple as copy-paste or just adding each new result to the end of the previous one in the CSV file.