Jump to content

mDuo13

Ripple Employee
  • Content count

    307
  • Joined

  • Last visited

  • Days Won

    18

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
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX
  1. Sadly, there's nothing published just yet on that. Arthur likes to keep his cards close at hand, so I don't think we'll be publishing anything substantial on the technical aspects of WorldDB until we're ready to move on it.
  2. Mojaloop is open-source code from several different companies including Ripple. And, to be honest, xCurrent and xRapid are more than just customer-specific glue code. There's quite a big repository of original code there including separate implementations of ILP-style connectors, ILP-compatible ledgers, etc. In fact, there are at least 3 or 4 implementations of ILP-compatible ledgers out there: Interledgerjs implementation (five-bells-ledger) Proprietary xCurrent Ledger implementation (supports more crypto-conditions and proprietary atomic mode stuff) Mojaloop implementations (compatible with Five Bells Ledger, written by other engineers at other companies that are part of the Mojaloop effort) DFSP Ledger and Central Ledger I think Hyperledger has also implemented at least some Interledger-compatible code but I'm not up to date on exactly what they have.
  3. Lowering XRP Min Balance

    The discussion within Ripple has been inconclusive so far. We are being very cautious about lowering the reserve for a couple reasons: One of those is that, clearly, the current amount is still not deferring misuse (as Polo unfortunately exemplifies). The other is that raising the reserve is a painful process, which is almost like taking money away from people. So we really don't want to lower it if we'd have to raise it again sometime soon. So we definitely cannot react to short-term price movements. We have also been discussing some ways to possibly create accounts or account-like things that can be deleted, with whatever caveats. It's not guaranteed that we'll do any of these specifically or even any of them at all. But in the interest of transparency and collaboration, here are a couple thoughts that were tossed around: XRP-only multi-signing "sub-accounts" that are tied to destination tags. The sub-account would have its own balance of XRP but would send transactions using the sequence number of the parent account. New "deletable" flag on accounts (on by default for new accounts). Transactions from these accounts must specify a LastLedgerSequence within a certain range of the current ledger. You still would only be able to delete an account if it owned no ledger objects. "Light" accounts that can send and receive XRP but can't own objects in the ledger and can only send and receive "Payment" type transactions. Light accounts have special Sequence numbers that start out equal to the current ledger index when the account gets created and can't go over a certain amount (always less than the current ledger index). So the account would take a while (say, 100 ledgers) to "mature" enough to send transactions and then it can't average more than 1 transaction per ledger version. If it ever runs out of XRP, it'd get deleted. The sequence number thing gets around the transaction replay problem because if an account ever gets re-created, its new starting Sequence number will definitely be higher than any previous transaction it could've sent successfully. Since they can't own anything in the ledger, the total space a "Light" account would occupy is less than what an offer occupies, so they're definitely less bad than offers (which already exist) in terms of letting people temporarily clog the ledger and then get their XRP back.
  4. Short version: It's imprecise by design because negotiating exact times is more effort than it's worth. Long version: Ledger close times are recorded in "seconds since the Ripple Epoch of 2000-01-01:00:00:00 UTC" so the milliseconds portion is always going to be 0. On top of that, ledger close times are negotiated by the network as part of the consensus process. The consensus process potentially involves servers each with their own clocks in disparate locations and communication latency in between, so it's pretty hard to agree on an exact time down to the millisecond upon which a ledger is closed. Instead, there's a window (I think it's 10 seconds) called the "close_time_resolution" and the official ledger close time is rounded off to the nearest window. Ledgers that would be rounded to the same number as a parent ledger have the close time incremented by one second. Consensus usually takes 4-5 seconds, so that's why you see a 0, 1, 2 pattern of seconds—the "1" and "2" are ledgers that are rounded to the same 10-second window as their predecessors. You're likely to see some sequences of ledgers that don't have a +2-second offset because they'll get rounded up to the next window after the +0s and +1-second ledgers and you'll almost never see a +3s because you won't fit three ledger closes in a 10-second window.
  5. I don't have great answers to all your questions (I'll get back to you when I hear from those who know more about the db config stuff) but I can handle this one: You configure your rippled server with a list site (vl.ripple.com) and a public key that your server will use to confirm the integrity of the lists it receives. (Servers can also share the data to their peers, if for example, the site is down.) To maintain sync with the validators that Ripple recommends, you should follow this setup for now. Otherwise, there's no guarantee you'll maintain the 80% overlap in validators that is necessary to keep you in sync with everyone else, especially as Ripple grows the recommended list of validators from 5 to much more. (Starting today or tomorrow, Ripple is adding a 6th Ripple-operated validator, with more to come until the official recommendation is up to the planned 16 new Ripple-run validators. This is, of course, in preparation for adding non-Ripple validators to our recommended lists.)
  6. Seeking dev community

    Best of luck! If you have specific questions or notice any oversights in the documentation, let me know (or file them as issues in https://github.com/ripple/ripple-dev-portal ) and I'll try to answer them as best I can.
  7. Ripple's resource limits as a company are quite simple and fundamental: Time, people, and those people's expertise. This tweet summarizes it pretty succinctly: There are only so many people working at the company, and it's hard just to teach those people enough about XRP and everything else the company for them to contribute. This industry is not easy to understand! And all the time that Ripple employees spend hiring and training other employees is time not spent doing stuff like writing code, communicating with the public, arranging business deals, thinking up the next innovation, and so on. Not to mention that we have to be very careful to manage our own security—the company is a big target for highly-motivated malicious actors—and follow the law, because it's surprisingly easy to come up with a cool idea for a financial service only to figure out that you need a license (or 50) to offer said service. Fortunately, the company realizes that if you skimp out on hiring and training people, that's a surefire way for your company to become a total trainwreck with people operating at odds with one another, blocking progress, and duplicating work. (I know this all too well, having previously worked at Playdom, a company which went from 70ish employees to over 200 in a year and became just completely, embarrassingly disorganized.) Ripple is not focused on one thing at a time. The company is not doing everything because that would be crazy, but it is doing several things (XRP Ledger, Interledger, xCurrent, xRapid, etc.) while also growing carefully. Also, the company's assets are now worth much, much more than they were 90 days ago, but the company can't just immediately cash out and realize that value. It would be very unwise to commit to spending as much as possible all the time. Especially because cryptocurrencies are so volatile, the company doesn't know how much it'll be worth quarter to quarter, and it could be much higher, or much lower, than it is now. Ripple has made steady progress on building out a quality company with people who know what they're doing and how to do it properly, and I'm both impressed and proud at the balance the team has struck between speed and quality so far. I hope it continues that way. For the record, if you want to help, Ripple is always hiring: https://ripple.com/company/careers/all-jobs/#
  8. Technical documentation on this is here: https://ripple.com/build/ledger-format/#contributing-to-the-owner-reserve
  9. Re-keying ripple account

    Technically setting a regular key doesn't change the public key associated with an address so much as add a second one. (You can then turn off the first one.)
  10. This is a really fascinating discussion and unfortunately tough to visualize without diagrams. I was thinking recently about a similar setup, where the idea would be to issue a limited number of tokens, but if some get destroyed by people sending them to the issuer, be able to re-issue up to the same amount. (So the total amount that can be created is unlimited, but the circulating supply at any given time has a known maximum.) The setup I was picturing sounded kind of similar to what heartbit has been describing, but I could never quite fit it all in my head at one time to convince myself it would/wouldn't work.
  11. You're spot-on when you say that the XRP Ledger is not a "blockchain" in the strict sense. That's because it's all about the mechanism for achieving consensus. To me, "blockchain" means proof of work and other mining-based technologies where the consensus is, by convention, declared as whatever the longest chain contains. In comparison, the XRP Ledger technology makes the element of human trust explicit in the consensus rules. For Bitcoin you say, "I trust whichever chain is longest because making a chain long is a matter of collaborating and having more computing power dedicated to this problem than everyone who wants the consensus to be different." For the XRP Ledger you say, "I trust whatever this set of servers can agree on." The differences from strictly-defined "blockchain" tech don't end there (there's also the "one complete slice" versus "just the diff" blocks) but that's the most important one. That's why the XRP Ledger goes so fast—you're not competing to see who can waste the most energy on the problem—but it's also why decentralizing the XRP Ledger is so much harder, because it actually matters who's running the servers you trust. However, "blockchain" has become too much of a buzzword for Ripple to claim not to be one. I'm pretty sure Ripple's marketing department threw in the towel on trying to explain these technical vagaries and just decided, "You know what, the XRP Ledger is a decentralized database with digital signatures and a scarce native asset and transactions that are confirmed in sequential blocks... that's close enough."
  12. @tulo, you seem to have misunderstood my point. Here, maybe a diagram will help.
  13. Sorry, this is a misunderstanding. XRP is not necessary for xCurrent and xVia transactions, which settle using Interledger atomic mode. But, as @JoelKatz explained in the Reddit thread and elsewhere, that's part of our strategy to make XRP successful. First, remove all the non-technical issues that prevent big institutions from settling via whatever asset they want. Then they'll use XRP because XRP is the best asset and it saves them the most money. Why is XRP the best asset? It's a natively digital asset, so it's far faster and easier to send than precious metals and other physical assets by being simple to send anywhere very quickly. All fiat currencies and cryptocurrencies have this advantage, although some are faster than others. (For example, the UK and Mexico have very fast intra-national settlement rails for GBP and MXN, respectively.) It's decentralized and international, without needing a single trustworthy authority to issue, settle, and balance. So you don't have to worry that the government will suddenly print more of it out of control. All cryptocurrencies and precious metals have this advantage, although XRP's comes with the caveat that it depends on the validators becoming decentralized. The literal mining of precious metals and other physical assets is frequently associated with other social and ecological problems, though. It doesn't waste time and electricity with mining. XRP and XLM are the only cryptocurrencies I know that are remotely in the same class in this respect. XRP has (in my opinion) a stronger dev team, leadership, and partner ecosystem than XLM.
  14. rippled 0.81.0 released

    Yeah, it's not documented in detail yet, in part because I haven't had time to dig into it and get all the details. But I can tell you a little bit. The "blob" is a base64-encoded JSON string containing (for example) the following (you can verify this yourself by echoing and piping the blob content to base64 -d if you're on *nix): { "sequence": 2, "expiration": 569980800, "validators": [ { "validation_public_key": "ED6C9E8456FDA70144A73E709D5096463F1585F7158881F3BDC53E8B4FF1A1AB9B", "manifest": "JAAAAAFxIe1snoRW/acBRKc+cJ1QlkY/FYX3FYiB873FPotP8aGrm3MhA9mu8kAXgZh9Es8Jmi43UOspDNKvuaBRmgVnoAcF7dPTdkYwRAIgGjUNlb0/CMVKRZ/xsqyRU44Xp6eW49YE7STmISMMo38CIFzRps3YAVOEJjORUHm+5jPVkPUM5haZSlh+H5A6H1CqcBJA+rO3/EBajQxi+X03bv88XLaJZ29JGHmp9KnDsw2yLjM1raGOVSCmW6aCshze4E0vjt0n3i9D3+0+6jEvJNdPAg==" }, { "validation_public_key": "ED44FFE2F6249C37321A349C0A983C5D5D3EE334013AE4A5D8986E1674920354C9", "manifest": "JAAAAAFxIe1E/+L2JJw3Mho0nAqYPF1dPuM0ATrkpdiYbhZ0kgNUyXMhA2BsdqQcpySDEjiNfpWLH/SEReD0mKca2pBapPn8v21edkYwRAIgGfEX3KqbavKh+ULq7/uzY/pyXJsWKA9kMrWyd/S34wkCIDFQ7MHttljWbOMs18yfBIVNtyc714HHnj6L1aXOinCqcBJAkFsUkgaOACMfOgnLWl/kpTvAnY0mVH2r3cfSwZjsZyfrASiy1JCesixHOyAmypD9lCxEFESfWbNYXVSN/o3vDA==" }, { "validation_public_key": "ED57EA43D51EA4D1C78929BB24090ED3C89F03E1ED72BC564E957D87273006544F", "manifest": "JAAAAAFxIe1X6kPVHqTRx4kpuyQJDtPInwPh7XK8Vk6VfYcnMAZUT3MhAygLFlHdFPSlbYNKy+ZjdkUDLYcdC9/z7AuDNaAh7sbCdkcwRQIhAMZ+PNIkFZXVQSzrv4rfQB4uSplW3/sim+P56c6+Vt8KAiAqX4+X+Meakzlgp00wN2mZ9cAS5jB4AFOfnIGvwWsl3HASQBhpRx9RGBhgRKNYybcXN95LF80g44DM6nHSAmJGfjVJBWaZoYfiJmK6akQaBnN4Q1NIMMJevPjXx7tPmv8GRwE=" }, { "validation_public_key": "EDAFA8C68121A5A7DCF8BE55BD68D56DD342B834289961CA39BE6F2D06B9F1E605", "manifest": "JAAAAAFxIe2vqMaBIaWn3Pi+Vb1o1W3TQrg0KJlhyjm+by0GufHmBXMhAqyqCmq4xrrWSV31jBpa25vDBUMEdD3upfaLa1VgzNFedkcwRQIhALZagRDPKZD7tYsglEc/oJkMsyjOcTPKuPTqWtStiQ6qAiBxJ4zpSq8LYxM7v+aVssw9LfGUDCACM+MNrAVT5YtG3XASQInSqzLnlR8E0anedpwFBiroXApOZZgtv94nh9WHxUlWhj5PZnJUW86RavArYCphz/TmK53EsNjEOz+KfuHGFgg=" }, { "validation_public_key": "ED998FE668B05429A4790412BED375B219F3BBF5ADCF21765879511A1657223454", "manifest": "JAAAAAFxIe2Zj+ZosFQppHkEEr7TdbIZ87v1rc8hdlh5URoWVyI0VHMhAxMm4MZwm5jTP+w9WmJqZDDHYoE2Qiewf3Mq/nBmg2CsdkYwRAIgaaQHafZHdae/s/Kmc8w7c2fJWA+uc9EpPG9dWABhUcwCIFeX9ASCzOOv5bQV42fcldG9X+22OIo02XXE1QD54PnWcBJAiylOFqrifImqqPknGYj7EQirpOPXU8NigspfpCFPZYoEB5/xmg3E9uiYlZe25Q3RE1hiVLGdCIGmVZz9TcdAAw==" } ] } I think a "manifest" is basically a synonym for a validator token (or the public part of it, anyway?), which is a somewhat ephemeral key signed by the master key pair, plus a sequence number (so it can invalidate previous tokens). Something like that. @wilsonianb knows this stuff better than I do.
  15. I have a strong suspicion that DigitalOcean has a cron job that's killing the rippled process as soon as it starts to use too much memory or CPU. For the record, it's a pretty standard shared hosting practice to kill runaway processes that are eating up all system resources. (Gotta make sure all your customers get their fair share, after all.) It looks like your process is running fine, starting to sync up to the ledger, until it gets an external signal to kill it. Which would basically mean that the problem isn't coming from rippled itself.
×