Search the Community
Showing results for tags 'documentation'.
Found 5 results
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.
We've recently published two new articles to the XRP Ledger Dev Portal, both discussing the subject of Consensus: Introduction to Consensus is just that—a beginner level summary of Consensus in the XRP Ledger. Hopefully this can help new people pick up enough to get up and running with the XRP Ledger without getting as deep into the weeds as the older, more detailed consensus article. Consensus Protections Against Attacks and Failure Modes is a new FAQ-like article that discusses some of the various threats to the XRP Ledger and how it's set up to handle them. There's also a new blog post @JoelKatz shared on the Ripple Insights Blog: The Inherently Decentralized Nature of XRP Ledger. This one talks about the future of XRP decentralization and why the lack of mining is good for the network. (Forewarning: I think this article can be a little confusing when it switches between talking about the total number of validators and the trusted validators that most of the network pays attention to.) If you find these articles helpful or interesting, we'd be happy to hear it! And if you're befuddled or want to know more, please ask away. More importantly, I hope that building a better understanding of the XRP Ledger and its greater ecosystem can help you make more informed choices in the future, especially if you choose to contribute to the Internet of Value!
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.
mDuo13 posted a topic in Technical DiscussionJust today I published the documentation for a bunch of new feature stuff that's coming in rippled 0.31.0. (Right now we're still tracking down the last few bugs in the release candidates, but the feature set is finished and the release will be out probably any day now.) It's been a long road for multi-signing in particular, with the first preview promising that it was "coming soon" as of March 24, 2014. Yeesh! But this time, we really mean it: multi-signing is getting real. We're not... quite... there yet, though, and part of the reason is that 0.31.0 is the first time we're going to truly use the Amendments system for rolling out new network features in a decentralized fashion. This is a big step in our roadmap towards encouraging a decentralized web of trust in the validation network, because it means that the network will be able to smoothly roll out new features without interruptions or a central authority managing them. You can read more about Amendments on the Ripple Dev Center. But! There's one other thing before Multi-Sign happens, and that's an amendment called "Fee Escalation." We haven't talked it up as much, but this change has also been in a long time coming. A while back, you may recall that the cost to send a transaction increased from a typical price of of 10 drops to 10,000 drops of XRP. That's because we realized that, with the network as it was, it had become possible to intermittently DDoS the network without spending a fortune in XRP -- the transaction cost reacted slowly enough to changes in conditions that the network was already in trouble by the time the costs became unbearable. For many months, we've been running our validators with a band-aid fix, with the "load" multiplier artificially cranked up to 1000× in order to maintain network stability. That's why the first Amendment we support will be Fee Escalation -- a change that makes it actually possible to pay a higher transaction cost to make sure your transaction gets processed sooner. Now, when there are a lot of transactions in the current ledger, the server will start queuing up additional transactions for the next ledger instead of trying to squeeze them all in at once -- and the order will be determined by how much XRP those transactions destroy. Not only that, but you can still squeeze into the current open ledger if you pay even more XRP -- but the requirement scales exponentially, so it won't be worth it for long! The long and short of it is that the network should be more resilient against DDoS attacks, while affording more flexibility in the amount of XRP you spend sending transactions (based, presumably, on how urgent your transactions are). With any luck -- and this is not a guarantee, but I'm pretty sure it'll happen -- we'll be able to turn off the artificial "1000×" load knobs and return the minimum transaction cost back down to a truly miniscule amount. See the "Open Ledger Cost" section in the documentation for the details. That finally brings us back to Multi-Signing. It's going to be a few weeks out even after the release gets finalized, so you'll have plenty of time to figure out how it works in order to start multi-signing the instant the feature goes live. In fact, if you're really excited to try it out, you can practice how to multi-sign a transaction using rippled in stand-alone mode. You can also test out other stuff in stand-alone mode, without having to interact with the real network, whether you want to replay old ledgers or test out new features. (Stand-alone mode is not a new feature, but the new documentation should make it much easier to use.) This has been a big project (over 40 commits just to documentation!) and there are a few more changes not even mentioned here. (There might even be some minor improvements to rippled 0.31.0 that haven't made their way into the docs yet.) So, let's not quite declare victory before the release is live -- but get your funny hats and party poppers ready, because version 0.31.0 is going to be a big deal. As always, feedback is deeply appreciated, and I'm glad to offer clarifications for anything that doesn't make sense to you. And, just like rippled itself, our documentation is open-source, so you don't have to be a Ripple employee to contribute!
It's probably no surprise to the people here, since RippleAPI has been available for a little while, but here's the official announcement about the release of RippleAPI: https://ripple.com/dev-blog/introducing-rippleapi/ tl;dr RippleAPI is the merger of Ripple-REST and ripple-lib, it's way better than those two were, we're not supporting the old stuff anymore, and you should check out the brand-new Beginners Guide in case you're not sure how to get started with RippleAPI.
Just published last night: https://ripple.com/build/freeze/ This new documentation is more accurate (no more typos of who's freezing whom, which is something that persisted in the wiki article for like a year), more thorough, reviewed by technical experts, and even includes functional code samples for the new RippleAPI. Of course, the Freeze feature itself is over a year old, with no significant changes since then, so this is hardly news. But I still think it's worthwhile to share our ongoing efforts to clarify and improve understanding of the Ripple Consensus Ledger rules and rippled software as it exists. If there are any points in the documentation that are confusing or seem inaccurate, let me know and I'd be glad to clarify!