XRP Ledger (
rippled server) version 1.4.0 has been released. The XRP Ledger version 1.4.0 introduces several new features and overall improvements to the codebase, including the DeletableAccounts Amendment, which allows users to delete XRP Ledger accounts and recover some of their account base reserve in the process.
XRP Ledger (
A new XRP Ledger Devnet is now available for developers to access upcoming features of XRPL on beta build versions of
rippled, the C++ reference implementation of the XRP Ledger.
The fixMasterKeyAsRegularKey amendment to the XRP Ledger, introduced in
rippled v1.3.1, is expected to become enabled shortly past midnight UTC on 2019-10-02. Operators of
rippled servers must upgrade to v1.3.1 (or higher) by that time.
The fixMasterKeyAsRegularKey amendment to the XRP Ledger, introduced in
rippled v1.3.1, has gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-10-02. As long as the fixMasterKeyAsRegularKey amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date.
Update: The second reset occurred as planned and the Testnet became fully available by approximately 7:56 PM PDT. The amendments that are enabled on the Testnet now match the status of amendments on the production Mainnet.
On 2019-08-27 at approximately 1:00 UTC (6 PM PDT), Ripple reset their XRP Testnet. This means that all accounts, balances, and settings in the Testnet have been deleted and all contents of the Testnet's decentralized exchange have been erased. However, in the process of resetting the XRP Testnet, a procedural issue caused amendments that were previously enabled to be disabled in the fresh ledger chain. Ripple plans to reset the XRP Testnet again today (2019-08-30) at 4 PM PDT. Starting at this time, the Testnet may be unavailable for a maintenance window lasting up to 4 hours.
The production XRP Ledger, or Mainnet, is completely unaffected. This also has no effect on other test networks not run by Ripple.
Ripple has released version 1.3.1 of
rippled, the reference implementation of the core XRP Ledger protocol. To learn more about how to build and run a
rippled server, see Manage the Rippled Server.
This release supersedes version 1.3.0. Version 1.3.1 addresses deadlock conditions reported by some users late in the release cycle for 1.3.0.
By Rome Reginelli, Documentation Engineer at Ripple
Blockchain technology raises new questions about the roles of privacy and anonymity in the function of money. While all transactions are a matter of public record, the parties involved in the transactions are represented by pseudonyms, and information about who those parties are may be hard to come by. Even more obscure is information about those whose computing power and maintenance efforts underpin the blockchain. While there are lots of good reasons to maintain privacy around some entities and events, there are also situations that call for publicly establishing one's identity and reputation. The
xrp-ledger.toml specification provides a flexible standard for voluntarily publishing information about who you are and what you're doing with the XRP Ledger.
In this post, I explore the process of creating an
xrp-ledger.toml file, explain why to use it, and introduce a new dev tool for checking
Today, a new XRP Ledger explorer is available for both test net and production at explorer.xrpl.org.
As part of the recent site relaunch, the XRP Ledger Dev Portal has an updated version of the WebSocket API Tool. This tool lets you communicate directly with
rippled servers, which power the XRP Ledger network. Among several of the improvements in this new version of the tool is that you can choose which servers to connect to, including the public servers Ripple runs, servers in the XRP Test Net, or your own server running locally on your own computer.
xrpl.org is a new, community-driven website for developers to access technical documentation, developer tools, tutorials, and network metrics for the XRP Ledger. The XRP Ledger is one of the largest, most technically mature, open-source, public blockchain networks in the world. If you are learning about, building on, and contributing to the XRP Ledger, xrpl.org is your best resource.
Ripple has released version 1.2.4 of rippled, the reference implementation of the core XRP Ledger protocol.
Version 1.2.4 improves the verification and routing of shard crawl requests and imposes a 20 second timeout onto the component that checks for an updated validator list to prevent it from becoming blocked for an indefinite amount of time.
By Nik Bougalis, Engineering Manager
The primary mission of the C++ team at Ripple is to contribute to
rippled, the reference implementation of the protocol that underpins the XRP Ledger. The codebase—which is now over 6 years old—has contributions from over 100 developers from all over the world.
As a team, our primary focus is on ensuring that the codebase is solid, that the code is robust and that it is well-suited to be the core of the next-generation of financial infrastructure, one which allows value to not only move as fast and as efficiently as information does today, but to move securely as well.
In an earlier blog post, I noted that our existing software development and quality assurance process—honed over several years—places heavy emphasis on correctness and security. I highlighted our use of automated tests and specialized tooling (such as static analyzers) but I also alluded to the human element as well: our rigorous and public code reviews and regular security audits of the codebase by specialists. I’d like to take the opportunity to discuss those practices in greater detail.
The MultiSignReserve amendment to the XRP Ledger, introduced in
rippled v1.2.0, has gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-04-17. As long as the MultiSignReserve amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date.
The Data API, an open API that provides data to XRP Charts and third-party tools, suffered gaps in data ingestion on 2019-03-23. As a result, several metrics on XRP Charts, including the number of ledgers closed per day, were overcounted. During this time, the XRP Ledger did not experience any outages. However, the Data API's ingestion service was unable to process ledgers with transactions containing the
tecKILLED transaction response code.
tecKILLED is a new response code added to the XRP Ledger by amendment fix1578 on 2019-03-23. This necessitated changes to the ripple-binary-codec library used by the ingestion service, but those changes were only partially deployed to the ingestion service. We have since reprocessed and corrected the metrics that were affected by this problem.
Here at Ripple, we've been eagerly following and contributing to the progress of Interledger, a neutral standard for connecting all money systems into an Internet-like network of networks. Since finalizing the core protocol suite in late 2017, contributors from a variety of companies and backgrounds have been working hard on growing the ecosystem with implementations and infrastructure. Progress has been rapid and wild, so we thought we'd help make sense of it by checking in to see where Interledger stands today.
Ripple has released version 1.2.3 of rippled, the reference implementation of the core XRP Ledger protocol.
Version 1.2.3 corrects a technical flaw that could, in rare circumstances, cause the server to dereference a null pointer, which could result in the server process being terminated by the operating system.
The fix1578 amendment to the XRP Ledger, introduced in
rippled v1.2.0, has gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-03-23.
The fixTakerDryOfferRemoval amendment to the XRP Ledger has also gained support from a majority of trusted validators. Currently, it is expected to become enabled on 2019-04-02.
As long as the amendments continue to have the support of at least 80% of trusted validators continuously, they will become enabled on the expected dates.
Ripple has released version 1.2.2 of rippled, our reference implementation of the core XRP Ledger server.
Version 1.2.2 corrects a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly. In some circumstances this can potentially cause the server to crash.
Ripple has released version 1.2.1 of
rippled, our reference implementation of the core XRP Ledger server.
Version 1.2.1 introduces several fixes including:
A change in the information reported via the enhanced crawl functionality introduced in version 1.2.0.
A fix for a potential race condition when processing a status message for a peer.
A fix for a technical flaw that could cause a server to not properly detect that it had lost connectivity.
Version 1.2.1 also adds the delivered_amount field to more responses to simplify the handling of payment or check cashing transactions.
Ripple is pleased to announce the release of XRP Ledger (
rippled) version 1.2.0.
The XRP Ledger version 1.2.0 release introduces the MultisignReserve Amendment, which reduces the reserve requirement associated with signer lists for Multisign. This release also includes incremental improvements to the code that handles offers in the decentralized exchange (fixTakerDryOfferRemoval and fix1578 Amendments).
One of the major benefits of decentralized blockchain technologies, such as the XRP Ledger, is censorship resistance. Already highly resistant to censorship attempts, with the release of version 1.2.0 of the XRP Ledger, servers now have the ability to automatically detect transaction censorship attempts and issue warnings of increasing severity for transactions that a server believes should have been included in a closed ledger after several rounds of consensus.
In the cryptography industry, it is well known that using repeated or insufficiently random "nonces" (also called "k" values) in ECDSA digital signatures carries security risks. A new research paper authored by Joachim Breitner and Nadia Heninger discloses a more serious attack than was previously known on signatures with imperfect nonces.