mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-27 15:15:50 +00:00
Migrate dev-blog to Redocly (#2346)
* Step 1 to migrate the blog - Add blog pages from the dev-blog repo * Add blog-specific sidebar (& update contents) * Add new dev reflections blog post from 01-23-2024 * Blog migration: fix markdoc errors and broken links * Remove community pages from the sidebar --------- Co-authored-by: mDuo13 <mduo13@gmail.com>
This commit is contained in:
Amarantha Kulkarni
committed by
mDuo13
mDuo13
parent
33cd1f54a5
commit
b4489f8649
62
content/blog/2014/biweekly-release-notes-14-august-2014.md
Normal file
62
content/blog/2014/biweekly-release-notes-14-august-2014.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Biweekly Release Notes (14 August 2014)
|
||||
|
||||
_Release notes are part of a larger overhaul of our developer resources, which we are continually adding to. Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features. We hope you find these useful! Please let us know if you have feedback in the comments._
|
||||
|
||||
### Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]
|
||||
|
||||
*Released version 0.26.2*
|
||||
|
||||
- Freeze enforcement: activates on September 15, 2014 ([RIPD-399](https://ripplelabs.atlassian.net/browse/RIPD-399))
|
||||
- Add pubkey\_node and hostid to server stream messages ([RIPD-407](https://ripplelabs.atlassian.net/browse/RIPD-407))
|
||||
- Fix intermittent exception when closing HTTPS connections ([RIPD-475](https://ripplelabs.atlassian.net/browse/RIPD-475))
|
||||
- Correct Pathfinder::getPaths out to handle order books ([RIPD-427](https://ripplelabs.atlassian.net/browse/RIPD-427))
|
||||
- Detect inconsistency in PeerFinder self-connects ([RIPD-411](https://ripplelabs.atlassian.net/browse/RIPD-411))
|
||||
- Add owner\_funds to client subscription data ([RIPD-377](https://ripplelabs.atlassian.net/browse/RIPD-377)) (Experimental Feature)
|
||||
|
||||
### Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]
|
||||
|
||||
*No new releases, major commits included below*
|
||||
|
||||
- Add empty http tests
|
||||
- Add rest to lib transaction converter
|
||||
- Fixed bugs from API cleanup
|
||||
- Began breakout of globals to separate modules
|
||||
|
||||
### Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]
|
||||
|
||||
*www.ripplecharts.com*
|
||||
|
||||
- restore user persistence for light theme
|
||||
- add Ripple Fox to gateways list
|
||||
- add IOU/IOU markets to top markets
|
||||
- metrics: added SS EUR, RS XAU, PR ILS to total network value
|
||||
- offersExcercised: demmurage/interest currency support
|
||||
- offersExercised: apply interest to unreduced results
|
||||
- gateways: rename ripple israel, add GBI
|
||||
- gateways: added lakeBTC
|
||||
|
||||
[*Open bounties*](https://www.bountysource.com/trackers/3954022-ripple-charts)
|
||||
|
||||
- [Value Summary Donut: change details display to better represent IOU/IOU markets](https://www.bountysource.com/issues/3597514-value-summary-donut-change-details-display-to-better-represent-iou-iou-markets) (8,750 XRP)
|
||||
|
||||
### Ripple Client [[Release Notes](https://ripple.com/wiki/Ripple_Trade_Release_Notes) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]
|
||||
|
||||
*www.rippletrade.com - new release next week!*
|
||||
|
||||
- Redesigned Settings page
|
||||
- Destination Tag included in Transaction Summary (thanks [OrzFly](https://github.com/orzfly)!)
|
||||
- Fix invalid/non-canonical currency pairs in dropdown menu
|
||||
- Trade filter on history page (thanks [Madsn](https://github.com/Madsn)!)
|
||||
|
||||
[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (62,500 XRP)
|
||||
- [Alerts in the top right should include trades](https://www.bountysource.com/issues/2842706-ripple-trade-alerts-in-the-top-right-should-include-executed-trades) (12,500 XRP)
|
||||
- [Ripple URI for trade tab](https://www.bountysource.com/issues/2842655-ripple-uri-for-trade-tab) (12,500 XRP)
|
||||
|
||||
### Codius [[Github](https://github.com/codius)]
|
||||
|
||||
- Code released on August 4th
|
||||
- Examples available ([bitcoin](https://github.com/codius/example-bitcoin), [webserver](https://github.com/codius/example-webserver), [helloworld](https://github.com/codius/example-helloworld))
|
||||
|
||||
|
||||
@@ -0,0 +1,61 @@
|
||||
# Biweekly release notes (17 September 2014)
|
||||
|
||||
*Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.*
|
||||
|
||||
*We hope you find these useful! Please let us know if you have feedback in the comments.*
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*Released version 0.26.3-sp1*
|
||||
|
||||
- New command to display HTTP/S-RPC sessions metrics ([RIPD-533](https://ripplelabs.atlassian.net/browse/RIPD-533))
|
||||
- Improved handling of HTTP/S-RPC sessions ([RIPD-489](https://ripplelabs.atlassian.net/browse/RIPD-489))
|
||||
- Fix unit tests for Windows.
|
||||
- Fix integer overflows in JSON parser.
|
||||
- Improve processing of trust lines during pathfinding.
|
||||
- Added a command line utility called LedgerTool for retrieving and processing ledger blocks from the Ripple network.
|
||||
|
||||
### **Ripple-lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]**
|
||||
|
||||
*Released version 0.8.1*
|
||||
|
||||
- Wallet: Add Wallet class that generates wallets
|
||||
- Make npm test runnable in Windows.
|
||||
- Fix several stability issues, see merged PR's for details
|
||||
- Fix bug in Amount.to\_human\_full()
|
||||
- Fix undefined fee states when connecting to a rippled that is syncing
|
||||
|
||||
### **Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*No major updates* [***Open bounties***](https://www.bountysource.com/trackers/3954022-ripple-charts)
|
||||
|
||||
- [Value Summary Donut: change details display to better represent IOU/IOU markets](https://www.bountysource.com/issues/3597514-value-summary-donut-change-details-display-to-better-represent-iou-iou-markets) (5,833 XRP)
|
||||
|
||||
### **Ripple Client [[Release Notes](https://ripple.com/wiki/Ripple_Trade_Release_Notes) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*www.rippletrade.com - released version 1.0.6, 1.0.7* 1.0.6
|
||||
|
||||
- Balance pie UI changes
|
||||
- Enable 2 factor authentication
|
||||
|
||||
1.0.7
|
||||
|
||||
- Add "Download to CSV" option for account history
|
||||
- Ability to select which issuer you want in the send and convert flows
|
||||
- Use bower ripple-lib
|
||||
- Update bower dependency versions
|
||||
- Fix issues around balance pies and exchange rates
|
||||
- Gateway UI changes
|
||||
- Show ripple names on notifications
|
||||
- Show executed trades in notifications bell
|
||||
- Temporarily remove currency and amount filters from history
|
||||
|
||||
**[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)**
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (41,667 XRP)
|
||||
- [Incorrect amount displayed for partial payments](https://www.bountysource.com/issues/2842476-incorrect-amount-displayed-for-partial-payments) (8,333 XRP)
|
||||
|
||||
### **Codius** **[[Github](https://github.com/codius)]**
|
||||
|
||||
- Connect and write to TCP socket
|
||||
- Add jsmn to libuv for JSON parsing
|
||||
64
content/blog/2014/biweekly-release-notes-3-september-2014.md
Normal file
64
content/blog/2014/biweekly-release-notes-3-september-2014.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Biweekly Release Notes (3 September 2014)
|
||||
|
||||
*A few days tardy, but better late than never...* *Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.* *We hope you find these useful! Please let us know if you have feedback in the comments.*
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*No new releases, *major commits included below**
|
||||
|
||||
- Fix missing return value error check
|
||||
- Optimize pathfinding operations
|
||||
- Improve parallelization of getRippleLines
|
||||
|
||||
### **Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
**No new releases*, major commits included below*
|
||||
|
||||
- Fix missing metadata on get payment
|
||||
- Fix undefined ledger\_current\_index
|
||||
- Fix double-date-conversion in request payment
|
||||
- Always query rippled for transactions
|
||||
|
||||
### **Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*No major updates* [***Open bounties***](https://www.bountysource.com/trackers/3954022-ripple-charts)
|
||||
|
||||
- [Value Summary Donut: change details display to better represent IOU/IOU markets](https://www.bountysource.com/issues/3597514-value-summary-donut-change-details-display-to-better-represent-iou-iou-markets) (5,833 XRP)
|
||||
|
||||
### **Ripple Client [[Release Notes](https://ripple.com/wiki/Ripple_Trade_Release_Notes) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*www.rippletrade.com - released version 1.0.4, 1.0.5, 1.0.5-1, and 1.0.5-2* 1.0.4
|
||||
|
||||
- Pie widget that displays the total estimated balance of the account in 1 currency
|
||||
- "Flip' button for currency pairs in the Trade tab
|
||||
- Click on an active order, load orderbook for that pair
|
||||
- "Trade" filter in the History page
|
||||
- Place recently used trade pairs at the top of the dropdown
|
||||
- Migrate and Login flows now check separate blobs
|
||||
- Add destination tags to transaction summary page
|
||||
- Update trust lines UI to "Connect gateway" UI, put it under the "Fund" tab
|
||||
- Put Rippling and incoming trust lines into the "advanced trust line" options
|
||||
- Settings UI updated
|
||||
|
||||
1.0.5
|
||||
|
||||
- Only show funded portion of orders in the orderbook
|
||||
|
||||
1.0.5-1
|
||||
|
||||
- Fix currency choice restriction bug (RT-2146)
|
||||
|
||||
1.0.5-2
|
||||
|
||||
- Various send tab fixes
|
||||
|
||||
**[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)**
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (41,667 XRP)
|
||||
- [Incorrect amount displayed for partial payments](https://www.bountysource.com/issues/2842476-incorrect-amount-displayed-for-partial-payments) (8,333 XRP)
|
||||
|
||||
### **Codius** **[[Github](https://github.com/codius)]**
|
||||
|
||||
- Create passthrough API
|
||||
- Implement fs.statSync to call out of the sandbox
|
||||
- Added EventLoop
|
||||
81
content/blog/2014/biweekly-release-notes-31-july-2014.md
Normal file
81
content/blog/2014/biweekly-release-notes-31-july-2014.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# Biweekly release notes (31 July 2014)
|
||||
|
||||
Starting today, Ripple Labs will release curated release notes on a bi-weekly basis to ensure better communication with the developer community about ongoing projects.
|
||||
|
||||
This effort is part of a larger overhaul of our developer resources, which we are continually adding to.
|
||||
|
||||
The curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.
|
||||
|
||||
We hope you find these useful! Please let us know if you have feedback in the comments.
|
||||
|
||||
### Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]
|
||||
|
||||
*Released version 0.26.1*
|
||||
|
||||
- Enabled asynchronous handling of HTTP-RPC interactions. This fixes client handlers using RPC that periodically return blank responses to requests. ([RIPD-390](https://ripplelabs.atlassian.net/browse/RIPD-390))
|
||||
- Fixed auth handling during OfferCreate. This fixes a regression of [RIPD-256](https://ripplelabs.atlassian.net/browse/RIPD-256). ([RIPD-414](https://ripplelabs.atlassian.net/browse/RIPD-414))
|
||||
|
||||
### Ripple-Lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]
|
||||
|
||||
*Released version 0.7.39*
|
||||
|
||||
- Improvements to multi-server support. Fixed an issue where a server's score was not reset and connections would keep dropping after being connected for a significant amount of time.
|
||||
- Improvements in order book support. Added support for currency pairs with interest bearing currencies. You can request an order book with hex, ISO code or full name for the currency.
|
||||
- Fix value parsing for amount/currency order pairs, e.g. Amount.from\_human("XAU 12345.6789")
|
||||
- Improved Amount parsing from human readable string given a hex currency, e.g.Amount.from\_human("10 015841551A748AD2C1F76FF6ECB0CCCD00000000")
|
||||
- Improvements to username normalization in the vault client
|
||||
- Add 2-factor authentication support for vault client
|
||||
- Removed vestiges of Grunt, switched to Gulp
|
||||
|
||||
### Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]
|
||||
|
||||
*Released version 1.2.1*
|
||||
|
||||
- Enabled invoice ID
|
||||
- Do not limit the amount of account transactions per ledger to 10, fixing the issue where no incoming transactions were ever notified.
|
||||
|
||||
### Rippled Historical Database [[Github](https://github.com/ripple/rippled-historical-database)]
|
||||
|
||||
*Kicked off development on project*
|
||||
|
||||
- SQL database as a canonical source of historical data in Ripple
|
||||
|
||||
### Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]
|
||||
|
||||
*www.ripplecharts.com*
|
||||
|
||||
- Top 6 markets are visible on the front dashboard now
|
||||
- New markets have been added to our volume pie chart
|
||||
- Hot/Warm wallet accounts have been deducted from Cold Wallets balances in the capitalization charts (under value trends) to more accurately represent capitalization of each issuer/currency
|
||||
|
||||
### Ripple Client [[Release Notes](https://ripple.com/wiki/Ripple_Trade_Release_Notes) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]
|
||||
|
||||
*Released versions 1.0.1 and 1.0.2* 1.0.1
|
||||
|
||||
- Account password change functionality
|
||||
- Navbar render optimization
|
||||
- Currency caching fixes
|
||||
- e2e testing setup / basic login, xrp send flow tests
|
||||
- Mobile UI fixes
|
||||
- "LESS" variables for used colors / fonts
|
||||
- Translation fixes
|
||||
- Online/Offline issue fix
|
||||
|
||||
1.0.2
|
||||
|
||||
- AngularJS optimizations / Performance boost
|
||||
- Code cleanup
|
||||
- Demurrage exchange fixes
|
||||
- Mobile UI fixes
|
||||
- "Load more" button for orderbook
|
||||
- Detect browser language preferences
|
||||
|
||||
[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (62,500 XRP)
|
||||
- [Click on XRP amount in top right, dropdown showing all balances](https://www.bountysource.com/issues/2842592-ripple-trade-click-on-xrp-amount-in-top-right-dropdown-showing-all-balances) (25,000 XRP)
|
||||
- [Create "Trade" filter in History tab](https://www.bountysource.com/issues/2842682-create-trade-filter-in-history-tab) (25,000 XRP)
|
||||
|
||||
### Codius
|
||||
|
||||
*Code drop on 4 August 2014 at 9:00 am PST*
|
||||
75
content/blog/2014/curves-with-a-twist.md
Normal file
75
content/blog/2014/curves-with-a-twist.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Curves with a Twist
|
||||
|
||||
Ripple Labs is considering the addition of a new elliptic curve implementation to the Ripple protocol to complement the existing cryptographic system. The addition of a Schnorr-based cryptosystem will produce more optimal and secure design schemes and provides a platform for robust and sophisticated functionality while preserving existing network structure and efficiency.
|
||||
|
||||
Currently, the Ripple protocol uses Koblitz curves with secp256k1 parameters and [ECDSA](http://en.wikipedia.org/wiki/Elliptic_Curve_DSA) signatures as defined in the [Standards for Efficient Cryptography](http://www.secg.org/collateral/sec2_final.pdf) (SEC) by Certicom, which is the same cryptosystem that powers Bitcoin.
|
||||
|
||||
After months of analysis and testing, we’ve concluded that a Schnorr-based cryptosystem will greatly enhance the security, flexibility, and performance of the Ripple protocol. The system we’re currently testing is [Ed25519](http://ed25519.cr.yp.to/).
|
||||
|
||||
The Ed25519 cryptosystem was designed by prominent cryptographer [Daniel J. Bernstein](http://cr.yp.to/djb.html). It consists of [Curve25519](http://cr.yp.to/ecdh.html), a [Twisted Edwards curve](http://en.wikipedia.org/wiki/Twisted_Edwards_curve), in conjunction with the [Schnorr signature scheme](http://en.wikipedia.org/wiki/Schnorr_signature). Ed25519 addresses many of the ongoing security concerns surrounding commonly used cryptosystems, which Bernstein [outlines in a March blog post](http://blog.cr.yp.to/20140323-ecdsa.html), and avoids several design constraints inherent to secp256k1 ECDSA. [OpenSSH](http://www.openssh.com/) recently added support for Ed25519 [based on this reasoning](http://chneukirchen.org/blog/archive/2014/02/the-road-to-openssh-bliss-ed25519-and-the-identitypersist-patch.html).
|
||||
|
||||
## The elliptic curve: Curve25519
|
||||
|
||||
[](https://cdn.ripple.com/wp-content/uploads/2014/06/curved2.png)
|
||||
|
||||
_Image: secp256k1 (left) versus Curve25519 (right)_
|
||||
|
||||
|
||||
The [open and transparent nature](http://safecurves.cr.yp.to/) of how the curve parameters for Curve25519 were set mitigates the risk of a potential backdoor.
|
||||
|
||||
Summary of advantages versus secp256k1:
|
||||
|
||||
- [Large absolute value](http://safecurves.cr.yp.to/disc.html) for the CM field discriminant (large `|D|`)—although there is no evidence of security problems with small `|D|`.
|
||||
|
||||
- Supports simple, fast, [complete](http://safecurves.cr.yp.to/complete.html) constant-time single-scalar multiplication using [a Montgomery ladder](http://safecurves.cr.yp.to/ladder.html).
|
||||
|
||||
- A random curve point can be represented in a way that’s [indistinguishable from random data](http://safecurves.cr.yp.to/ind.html).
|
||||
|
||||
- Faster performance (see below)
|
||||
|
||||
Our initial tests and analysis suggest significant performance gains with the new curve. Curve25519 halves verification time versus secp256k1 based on efficient implementations of both curves. These results were achieved with lower variance, which point to the constant time properties of Curve25519.
|
||||
|
||||
Also, the default signature format for Ed25519 allows batch signature verification, which promises twice the performance of DSA.
|
||||
|
||||
### Benchmarking
|
||||
|
||||
- [Raw test results](http://justmoon.github.io/curvebench/benchmark.html)
|
||||
- [Benchmark source code](https://github.com/justmoon/curvebench)
|
||||
|
||||
In combination, the new curve implementation is expected to quadruple performance versus secp256k1 based on our preliminary benchmarking.
|
||||
|
||||
## The signature scheme: Schnorr
|
||||
|
||||
The Schnorr signature scheme also adds key benefits in comparison to ECDSA. [Adam Back](http://en.wikipedia.org/wiki/Adam_Back), the inventor of [Hashcash](http://en.wikipedia.org/wiki/Hashcash) (the proof-of-work system used in Bitcoin), [sums up the benefits of Schnorr](https://www.mail-archive.com/cypherpunks@cpunks.org/msg02419.html) as follows: "simple blinding, compact multi-sig, clearer security proofs, better security margin, less dependence on hash properties."
|
||||
|
||||
Summary of advantages versus ECDSA:
|
||||
|
||||
- Simpler to securely implement
|
||||
- Composable threshold signatures without multi-party computation
|
||||
- Verification happens off-network allowing for sophisticated functionality without increasing network load or complexity
|
||||
- Conducive to highly distributed systems
|
||||
- Less constraints allows for more optimal and secure design schemes
|
||||
|
||||
DSA schemes are difficult to manage because the schemes are easy to get wrong. An improper implementations is trivial to break, and what might seem like a minor misstep can precipitate a system-wide vulnerability—as demonstrated by [the highly publicized Playstation hack](http://nakedsecurity.sophos.com/2012/10/25/sony-ps3-hacked-for-good-master-keys-revealed/) in 2012.
|
||||
|
||||
Hackers were able to access full control of the PS3 employing “simple algebra” after Sony set a constant in its custom DSA implementation instead of a randomly generated number. The sensitivity of DSA signatures to human error allowed this single oversight to fully compromise the console’s encryption protections, exposing the platform and Sony’s partners to the perpetual threat of piracy.
|
||||
|
||||
Alternatively, Schnorr signatures are more forgiving and simpler to implement because its security is inherently [more robust based on the scheme’s dynamic hash function](http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=4908440). The ephemeral public value _r_ is tightly bound to the message, which means that the security of the scheme is no longer [dependent on the collision resistance of the hash function](http://www.cs.bris.ac.uk/Publications/pub_master.jsp?id=2001023).
|
||||
|
||||
[](https://cdn.ripple.com/wp-content/uploads/2014/06/dsa-schnorr.png)
|
||||
|
||||
### Independent verification and combining
|
||||
|
||||
Another advantage of Schnorr is related to [threshold signatures](http://en.wikipedia.org/wiki/Threshold_cryptosystem), a useful alternative to [multi-signature schemes](https://ripple.com/wiki/Multisign) when multiple parties need to sign a message.
|
||||
|
||||
Multi-signature schemes require the network to verify each signature, increasing load with the number of participants. Conversely, threshold signatures are generated offline and result in a single signature regardless of total number of parties participating.
|
||||
|
||||
ECDSA can create threshold signatures, but requires [multi-party computation](http://en.wikipedia.org/wiki/Secure_multi-party_computation). This means that the number of participants required to generate a signature without revealing their secrets is twice the number of shares required to recover the key. In contrast, Schnorr has no such restriction. Shares of a signature can be independently verified and then composed.
|
||||
|
||||
Incidentally, composable threshold signatures allow the integration of sophisticated new features with fewer design constraints—especially when considering highly distributed systems—while preserving existing network structure and efficiency.
|
||||
|
||||
### Powering the future
|
||||
|
||||
Ed25519 allows more optimal designs regarding security, distribution, and, performance. The added flexibility will become increasingly relevant going forward as we supplement sophisticated functionality to the Ripple network—particularly in the area of [smart contracts](http://en.wikipedia.org/wiki/Smart_contract) and oracle systems (such as [Reality Keys](https://www.realitykeys.com/), winner of the Startup Challenge sponsored by [Ripple Labs at Bitcoin 2014 in Amsterdam](https://ripple.com/blog/ripple-labs-at-bitcoin-2014-in-amsterdam/))—where we have dedicated significant efforts behind the scenes.
|
||||
|
||||
We’ll provide an update of our progress in a future post.
|
||||
29
content/blog/2014/dev-portal-adds-rippled-apis.md
Normal file
29
content/blog/2014/dev-portal-adds-rippled-apis.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Dev Portal Adds rippled APIs
|
||||
|
||||
_By Rome Reginelli, technical writer_
|
||||
|
||||
Today, the [Ripple Dev Portal](https://developers.ripple.com/) gets a big boost of content and usability. The new additions to our development portal include thorough and tested documentation of all the public API methods for our core server software, ‘rippled’, alongside a host of improvements in styling and formatting, as well as new introductory material to give you direction in navigating the sea of Ripple technology.
|
||||
|
||||
This update brings very crucial content into the fold of documentation that's thorough, complete, and software-tested. Today, you can access [full specs and usage information for all 20+ public methods in the rippled WebSocket API](https://developers.ripple.com/rippled-api.html).
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
Just how much did we change this time? Let's have a look at what an arbitrary API calls looks like in the old and new formats:
|
||||
|
||||
**Before:**
|
||||
|
||||
[](https://cdn.ripple.com/wp-content/uploads/2014/08/Screen-Shot-2014-08-01-at-2.45.28-PM.png)
|
||||
|
||||
|
||||
**After:**
|
||||
|
||||
[](https://cdn.ripple.com/wp-content/uploads/2014/08/Screen-Shot-2014-08-01-at-2.47.50-PM1.png)
|
||||
|
||||
|
||||
You can see just from the size of the screenshots how much more information our new documentation brings to the table. We’ve standardized the structure of every method reference, and simplified the descriptions of what each one does. All the parameters in the request are listed and explained; so are all the fields in the response. Tested, complete examples are provided for both request and response in every method. Details have been checked against running instances and the source code, and the entire document has been proof-read multiple times by different experts. All the new examples scroll separately so they don’t overflow the layout. (Tip: You can expand any example to its full vertical size by double-clicking it. Careful: some of them are <i>long.</i>) To top it off, there's brand-new introductory material, ranging from why to run a server to how to select the right tool for the job.
|
||||
|
||||
While this is a big step forward for the Developer Portal, you should be aware of a few existing gaps in our content coverage which will be resolved shortly. For starters, most of the Websocket API's admin methods aren't covered. For those, you'll still have to refer back to the old wiki documentation. Possible error messages aren't included in the method reference, either. Although every method has an example in WebSocket format, most methods don't have a corresponding example in JSON-RPC syntax yet. Most importantly, this still covers only one piece of the software that Ripple Labs is creating: great pieces of software like [ripple-lib](https://github.com/ripple/ripple-lib) and the [Blobvault](https://github.com/ripple/ripple-blobvault) aren't on the Dev Portal yet. Rest assured, we're working on it.
|
||||
|
||||
The good news is, we don't have to go it alone. Following Ripple's company ethos of being inclusive and open, we've got the source for the Dev Portal [available on GitHub](https://github.com/ripple/ripple-dev-portal) for anyone to download and view. If you catch a mistake—let us know with an [issue](https://github.com/ripple/ripple-dev-portal/issues), and we'll take a look. Better yet, fork the repo, fix it yourself, and send us a pull request. We love community contributions, and we'd love to work your changes into the official site.
|
||||
|
||||
For all those of you who are following the Ripple protocol and building apps already, thank you. We're hard at work to make your jobs easier. For all those of you who haven't started yet: why not? Now's a better time than ever.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Gateway Advisory On Partial Payment Flag
|
||||
|
||||
Ripple Labs has issued a Gateway Bulletin on the Partial Payment flag which describes the flag and best practices around balancing activity on and off the ledger. The tfPartialPayment flag is set by the sender to specify a payment where the beneficiary can receive less than the specified amount.
|
||||
|
||||
Gateways are encouraged to implement best practices and understand the Partial Payment flag to mitigate errors that can result in fraud if undetected.
|
||||
|
||||
To view this bulletin, please see [GB-2014-06 Gateway Advisory: Partial Payment Flag (PDF)](https://ripple.com/files/GB-2014-06.pdf).
|
||||
42
content/blog/2014/how-ripple-labs-supports-gateways.md
Normal file
42
content/blog/2014/how-ripple-labs-supports-gateways.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# How Ripple Labs supports gateways
|
||||
|
||||
<div class="alert alert-danger">This program is no longer active.</div>
|
||||
|
||||
_To help accelerate the creation of strong, reliable, and compliant gateways, Ripple Labs will be providing XRP incentives and extended technical support for gateways that meet criteria considered to be critical for the success of a gateway._
|
||||
|
||||
Ripple Labs wants every gateway to achieve a gold standard in business planning, technical reliability and stability, regulatory compliance, and liquidity. The Ripple protocol enables the federation and interoperability of many independent payment systems.
|
||||
|
||||
As such, we’re actively developing the specifications for [Gateway Services APIs](https://ripple.com/wiki/Gateway_Services) and are eager to help gateways with implementation. In the meantime, here are some of the steps and assistance provided by Ripple Labs to help get your gateway to that point.
|
||||
|
||||
|
||||
## Gateway business plan development
|
||||
|
||||
Successful businesses start with a concept that can be concisely summarized and executed upon. To get things started on the right foot, here is a business plan template for gateways _(link deleted)_ that is freely available. This plan was developed in consultation with new gateways that were exploring the business opportunities on Ripple, so it's tailored to the needs of an early stage operator.
|
||||
|
||||
The template encourages you to carefully consider who your customer is and what value they’ll derive from your service. Simplifying their experience and making the deposit and withdrawal of assets frictionless is critical to driving volume and subsequent revenue.
|
||||
|
||||
Serious endeavors should contact Ripple Labs at [developers@ripple.com](mailto:developers@ripple.com) to coordinate for possible assistance and business planning.
|
||||
|
||||
### Services implementation
|
||||
|
||||
[Gateway Services APIs](https://web.archive.org/web/20150322165420/https://wiki.ripple.com/Gateway_Services) make gateways interoperable and provide straightforward calls that clients can use to route payments appropriately. Gateway Services rely on existing web standards like host-meta and webfinger, while making certain functions of the REST API more robust. Please contact us for assistance if you decide to implement these services at your gateway.
|
||||
|
||||
## XRP for customers of KYC/AML compliant gateways
|
||||
|
||||
Ripple Labs may assist with customer acquisition by providing gateways with XRP that can be used to activate Ripple wallets of new accounts. Customers who provide a baseline level of KYC information may be eligible to receive XRP upon registration and making a deposit at your gateway.
|
||||
|
||||
## Compliance resources
|
||||
|
||||
Ripple Labs regularly issues [Gateway Bulletins](https://xrpl.org/become-an-xrp-ledger-gateway.html#gateway-bulletins) as new features are released or on topics related to compliance and risk. Those bulletins are shared with the developer community including gateway operators and [IRBA members](https://groups.google.com/forum/#!forum/irba). In addition to Gateway Bulletins, Ripple Labs publishes [Compliance Resources](https://groups.google.com/forum/#!forum/irba) that may be helpful for gateway operators in understanding local and global standards on KYC/AML policies, as well as opinions or guidance on virtual currency.
|
||||
|
||||
Since rules on KYC/AML policies and guidance on virtual currency vary by jurisdiction, gateways should obtain legal advice on how these rules apply to their business and country of operation. Be aware that regulatory standards are evolving rapidly. While Ripple Labs makes every effort to update the Gateway Bulletins and Compliance Resources regularly, gateways should seek legal advice and understand changes to regulation as it may vary based on geography and the products that you offer.
|
||||
|
||||
## Generating liquidity
|
||||
|
||||
Ripple Labs understands that it may be difficult for new gateways to generate the liquidity needed to provide a compelling service to their customers. To do so, it is important to meet the aforementioned technical and compliance standards to have a popular, well-capitalized gateway. Transaction volume drives liquidity so Ripple Labs may facilitate introductions for operational gateways to market makers who can enable assets issued by your gateway to trade freely at competitive exchange rates.
|
||||
|
||||
## Feedback is welcome
|
||||
|
||||
The Ripple protocol's success will be largely determined by the ecosystem of gateways that are providing the onramps and off-ramps for value. As such, Ripple Labs continues to support gateway developers and entrepreneurs in their projects to build gateways.
|
||||
|
||||
We’d love to hear your feedback on what’s most useful and other tools that you’d like to see. We look forward to working alongside you to build the value web!
|
||||
83
content/blog/2014/introducing-offer-autobridging.md
Normal file
83
content/blog/2014/introducing-offer-autobridging.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Introducing: Offer Autobridging
|
||||
|
||||
_By Nikolaos D. Bougalis_
|
||||
|
||||
Ripple’s powerful system allows payments between any source and destination currency to be made easily. Pathfinding considers multiple conversions between currencies to find the best rate for a payment.
|
||||
|
||||
The new **autobridging** feature improves offer placement in a similar fashion to pathfinding: when consuming existing offers, a newly placed offer will have the liquidity available in not only the direct order book (source to destination currency) but also in the corresponding books in which XRP is the destination and source respectively.
|
||||
|
||||
This expands the Ripple protocol’s capabilities and brings improved market depth for heavily-used asset pairs and improved liquidity for less-heavily-used asset pairs. A primer for Ripple’s autobridging implementation is [available on the Ripple Forums](https://ripple.com/forum/viewtopic.php?f=1&t=7127).
|
||||
|
||||
## AUTOBRIDGING: Creating more efficient markets on the Ripple network
|
||||
|
||||
Autobridging, at its core, is about constructing a new order book, which contains in sorted order by offer quality both direct and bridged offers. Traversing such a combined book and performing order crossing would, then, be no different than traversing a direct book.
|
||||
|
||||
[](https://cdn.ripple.com/wp-content/uploads/2014/07/autobridging-graphic.png)
|
||||
|
||||
Although conceptually simple ("figure out the offers, sort them best to worst and do offer crossing"), the reality is that there are a number of subtle points to keep in mind.
|
||||
|
||||
## SORTING: Ranking direct and autobridged offers
|
||||
|
||||
To sort composed bridged offers—such as (USD:XRP) and (XRP:EUR)—against direct offers—(USD:EUR)—we must calculate their respective exchange rates—what we call _quality_.
|
||||
|
||||
In the case of offer autobridging, quality is defined as the ratio of _out:in_ at the time that the offer was placed. This is particularly important—once an order is placed, its quality **never changes**.
|
||||
|
||||
In bridged offers, the input of the second leg is the output of the first leg, and quality is the ratio _out:in_. Thus the resulting quality of a bridged offer would be _leg2-out:leg1-in_—ignoring the XRP part of the offers—that is, we calculate the quality of the (USD:EUR) bridged offer by taking the product of the two legs together.
|
||||
|
||||
Given respective qualities direct and bridged offers are sorted into a combined order book from best to worst.
|
||||
|
||||
After rank, the next key variable to consider is amount—which brings us to the concept of _flow_.
|
||||
|
||||
With the ability to compare direct and bridged offers by quality, we are now able to sort them into an order book from best to worst. But we still need to figure out what offers we actually have to put in that book.
|
||||
|
||||
In the case of a direct offer, the answer is simple: put the direct order itself into the book. But what to do in the case of a bridged offer? To answer that question, we need to calculate how much a bridged offer could accept as input and how much it could produce as output—which brings us to another new concept: _flow_.
|
||||
|
||||
## FLOW: Determining bridged offer combinations
|
||||
|
||||
_Flow_ is the pair of input and output amounts that can be produced when taking an offer. Depending on context, flow can mean either _maximal flow_ or _actual flow_.
|
||||
|
||||
_Maximal_ flow is the largest output that the offer can produce—it represents the amount that one could get out of the offer, given an infinite amount of the input asset.
|
||||
|
||||
_Actual_ flow, on the other hand, is the amount that will actually be produced when the offer is taken—it is the amount that one could get out of the offer for a given, finite input.
|
||||
|
||||
During the autobridging process, we need to be able to take two _maximal_ flows (the individual USD:XRP and XRP:EUR offer flows) and combine them to create a new _maximal_ flow (USD:EUR).
|
||||
|
||||
## COMBINING OFFERS
|
||||
|
||||
In order to combine two offers, we must first determine which of the two offers is the limiting factor by looking at the output of the first leg and the input of the second leg and finding the smallest of the two.
|
||||
|
||||
With that established, we can adjust the non-limiting order so as to make the first order's output equal to the second order's input. Any such adjustment, of course, must be done respecting the offer's quality to maintain the invariant established earlier—that an offer's rate never changes.
|
||||
|
||||
The primitive we use is _capping_—capping clamps an offer's input or output to by a given maximum, scaling the output or input respectively, if necessary.
|
||||
|
||||
When capping an offer's input, if the offer's input is greater than the cap amount, then we clamp the input so that is equal to the limit, and we scale the output down by the offer's quality.
|
||||
|
||||
Similarly, when capping an offer's output, if the output is greater than to the cap amount, we clamp the output so that is equal to the limit, and we scale the input down by the offer's quality.
|
||||
|
||||
Either way, the result of capping is a new flow. When capping is complete, the output of the first offer (in XRP) should be equal to the input of the second offer (again, in XRP). The end result is that, given two offers (USD:XRP) and (XRP:EUR), we now have a maximal (USD:EUR) flow representing the combination of those two offers bridged over XRP.
|
||||
|
||||
It is this maximal flow which we will then place on the book.
|
||||
|
||||
At this point, you are probably wondering "_what about Buy/Sell semantics?_" It turns out that to implement Buy vs. Sell all that is required is one more _cap_ operation, either on the first or the second leg depending on whether we are implementing Sell or Buy semantics respectively, performed before we calculate the _maximal_ flow. We believe that this highlights the elegance of the _flow_ and _cap_ primitives.
|
||||
|
||||
## CROSSING
|
||||
|
||||
Given both a quality and a maximal flow, we can now create an autobridged book that contains, in sorted order, both direct and bridged offers that take USD and pay EUR—which is what we wanted—and offer crossing can proceed normally.
|
||||
|
||||
## REARCHITECTING
|
||||
|
||||
As an aside, during the development of offer autobridging, we also undertook a significant rearchitecting of the offer crossing code. Although the existing code was robust and well-written, we felt that we could still improve it by leveraging what we’ve learned in the process of developing and maintaining Ripple.
|
||||
|
||||
The results of these ongoing efforts speak for themselves—the offer crossing code has been abstracted and can be separately unit-tested. And—when using lines of code as a metric—less code is now needed to implement offer crossing.
|
||||
|
||||
Smaller size and increased functionality? Winning!
|
||||
|
||||
Going forward, you will see process reflect more of this rearchitecting of code alongside with the development of new features. This will help us improve the code and make it easier to understand, analyze, and further develop Ripple.
|
||||
|
||||
If you would like to examine the code, you can view the autobridging implementation on [our GitHub repository](https://github.com/ripple/rippled/commits/develop). The relevant commits are tagged with "Autobridging" in their commit message.
|
||||
|
||||
We look forward to any questions that you may have.
|
||||
|
||||
_Contact Nik: <nikb@ripple.com>_
|
||||
|
||||
_Follow him on Twitter: [@nbougalis](https://twitter.com/nbougalis)_
|
||||
54
content/blog/2014/introducing-ripple-names.md
Normal file
54
content/blog/2014/introducing-ripple-names.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# Introducing Ripple Names
|
||||
|
||||
Ripple names work in conjunction with Ripple addresses as a destination to receive funds, as an identifier for the sender, and as a handle to set trustlines.
|
||||
|
||||
|
||||
## Ripple name specifications
|
||||
|
||||
- Have 1-20 characters
|
||||
|
||||
- Valid characters include “a” through “z”, “0” through “9”, and dash “-”
|
||||
|
||||
- Leading, trailing, and two or more adjacent dashes are not allowed
|
||||
|
||||
Names will be canonicalized, meaning:
|
||||
|
||||
- Case insensitive, e.g. TheABCs is the same as theabcs
|
||||
|
||||
- Hyphens are ignored, e.g. the-abcs is the same as theabcs
|
||||
|
||||
## Implementation
|
||||
|
||||
We are designing a system for the Ripple network. Because protocol level changes are irreversible, we have decided to develop an off-network implementation.
|
||||
|
||||
In this implementation, we reserve the right to set aside names that can be claimed by authorized entities.
|
||||
|
||||
Reserved list:
|
||||
|
||||
- All 1-character and 2-character names
|
||||
|
||||
- The most visited 100,000 domains
|
||||
|
||||
- Current [name]@ripple.com addresses
|
||||
|
||||
- Application requests in sunrise period (open through 04/30/2014)
|
||||
|
||||
- Subset of Google’s n-gram database
|
||||
|
||||
## Application Requirements
|
||||
|
||||
Applying for a name and completing the payment does not guarantee that that Ripple name will be claimable. Applications must show some previous or intended use of the name, which can include, but is not limited to:
|
||||
|
||||
- Having a registered business, or doing-business-as, with that name
|
||||
|
||||
- Owning and controling a related domain name
|
||||
|
||||
- Not infringing on known trademarks or servicemarks
|
||||
|
||||
- Not intended to confuse or mislead
|
||||
|
||||
Applications will be reviewed in early May.
|
||||
|
||||
To apply for a Ripple name, please fill out the name application form _(formerly `names.ripple.com`)_ and complete a payment of 10,000 XRP to rrrrrrrrrrrrrrrrrNAMEtxvNvQ. XRP sent to this address will be unspendable. This is known as a [black hole address](https://xrpl.org/accounts.html#special-addresses).
|
||||
|
||||
If you have additional questions, please email support@ripple.com.
|
||||
96
content/blog/2014/release-notes-14-october-2014.md
Normal file
96
content/blog/2014/release-notes-14-october-2014.md
Normal file
@@ -0,0 +1,96 @@
|
||||
# Release Notes (14 October 2014)
|
||||
|
||||
*Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.*
|
||||
|
||||
*We hope you find these useful! Please let us know if you have feedback in the comments.*
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*Released version 0.26.3-sp4*
|
||||
- Update for validating rippled servers that includes new transaction fee logic
|
||||
|
||||
### **Ripple-lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]**
|
||||
|
||||
*Released versions 0.8.2, 0.8.3-rc1, 0.9.0-rc1, 0.9.0-rc2* 0.9.0-rc2
|
||||
- Currency: add `show_interest` flag to show or hide interest in `Currency.to_human()` and`Currency.to_json()` [Example use in tests](https://github.com/ripple/ripple-lib/blob/947ec3edc2e7c8f1ef097e496bf552c74366e749/test/currency-test.js#L123)
|
||||
- **Breaking change:** make maxLoops in seed.get\_key optional. [Example use in tests](https://github.com/ripple/ripple-lib/blob/23e473b6886c457781949c825b3ff48b3984e51f/test/seed-test.js)([23e473b](https://github.com/ripple/ripple-lib/commit/23e473b6886c457781949c825b3ff48b3984e51f))
|
||||
|
||||
0.8.3-rc1
|
||||
- Add routes to the vault client for KYC attestations ([ed2da574](https://github.com/ripple/ripple-lib/commit/ed2da57475acf5e9d2cf3373858f4274832bd83f))
|
||||
- Configurable maxAttempts for transaction submission ([d107092](https://github.com/ripple/ripple-lib/commit/d10709254061e9e4416d2cb78b5cac1ec0d7ffa5))
|
||||
- Fix: change handling of requestLedger options ([57b7030](https://github.com/ripple/ripple-lib/commit/57b70300f5f0c7534ede118ddbb5d8762668a4f8))
|
||||
|
||||
0.8.2
|
||||
- Currency: Allow mixed letters and numbers in currencies
|
||||
- Deprecate account\_tx map/reduce/filter
|
||||
- Fix: correct requestLedger arguments
|
||||
- Fix: missing subscription on error events for some server methods
|
||||
- Fix: orderbook reset on reconnect
|
||||
|
||||
### **Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*No major updates* [***Open bounties***](https://www.bountysource.com/trackers/3954022-ripple-charts)
|
||||
- [Value Summary Donut: change details display to better represent IOU/IOU markets](https://www.bountysource.com/issues/3597514-value-summary-donut-change-details-display-to-better-represent-iou-iou-markets) (5,833 XRP)
|
||||
|
||||
### **Ripple Client [[Release Notes](https://github.com/ripple/ripple-client/releases) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*www.rippletrade.com - released version 1.0.8, 1.0.9, 1.0.10* 1.0.10
|
||||
- Added a complete KYC flow (hidden for now)
|
||||
- Fixed payment URI’s with small amounts
|
||||
- Fixed JSON rewriter issues
|
||||
- Fixes on account page UI
|
||||
- Fixes on convert page
|
||||
- Routing changes
|
||||
- Notification and button UI improvements
|
||||
|
||||
1.0.9
|
||||
- Nodejs server for dev use
|
||||
- Advanced settings page UI improvements
|
||||
- Add default ripple.txt file
|
||||
- Show ripple names on overview page
|
||||
- Align balances on the decimal place on overview page
|
||||
|
||||
1.0.8
|
||||
- UI improvements / cleanup
|
||||
- Currency parameter for Ripple URIs
|
||||
|
||||
**[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)**
|
||||
- [In the “Send” confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (41,667 XRP)
|
||||
- [Incorrect amount displayed for partial payments](https://www.bountysource.com/issues/2842476-incorrect-amount-displayed-for-partial-payments) (8,333 XRP)
|
||||
|
||||
### **Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*Released version 1.2.5, 1.3.0-rc2, 1.3.0-rc3, 1.3.0-rc4* 1.3.0-rc4
|
||||
- Memo field support
|
||||
- Freeze support
|
||||
- New endpoint to generate an address/secret pair, `/account/new`
|
||||
- New configuration, you will have to change your config file
|
||||
- New database interface, support for sqlite in memory or persistent through config path
|
||||
- Deprecated Postgres support
|
||||
- Transitioned to Express4
|
||||
- Refactored response and error handling, improves consistency of response messages
|
||||
- Expose `router` and `remote` as `RippleRestPlugin` to use as a plugin for other modules
|
||||
- Centralize connection checking, improves consistency of connected responses
|
||||
- Centralize logging using winston, timestamps on all logs
|
||||
- New test-suite
|
||||
- Log all connected servers, add reconnect to servers on SIGHUP
|
||||
- Tied api version to major package version and added package version to index page `/` or`/v1`
|
||||
- Update ripple-lib which fixes several stability problems and crashes
|
||||
- Fix: issue where forcible server connectivity check would cause permanent server disconnect
|
||||
- Fix: show index page while hitting root `/`
|
||||
- Fix: issue with notification parsing
|
||||
- Fix: check and validate issuer upon payment
|
||||
- Fix: database reset on startup
|
||||
- Fix: Check tx.meta exists before accessing
|
||||
- Fix: Allow browser-based client to make POST to ripple-rest server
|
||||
- Fix: Occasional crash on getting payments for account
|
||||
- Code refactor and cleanup
|
||||
|
||||
1.2.5
|
||||
- Fix: Check that tx.meta exists before accessing
|
||||
- Fix: Case where ripple-rest would crash when rippled could not be connected to
|
||||
|
||||
|
||||
###### About Ryan Terribilini
|
||||
|
||||
Ryan Terribilini is head of developer relations at Ripple Labs.
|
||||
105
content/blog/2014/release-notes-19-november-2014.md
Normal file
105
content/blog/2014/release-notes-19-november-2014.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# Release Notes (19 November 2014)
|
||||
|
||||
*Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.*
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*Released version 0.26.4*
|
||||
|
||||
- Rocksdb v. 3.5.1
|
||||
- SQLite v. 3.8.7
|
||||
- Disable SSLv3
|
||||
- Add counters to track ledger read and write activities
|
||||
- Use trusted validators median fee when determining transaction fee
|
||||
- Add --quorum argument for server start ([RIPD-563](https://ripplelabs.atlassian.net/browse/RIPD-563))
|
||||
- Add account\_offers paging ([RIPD-344](https://ripplelabs.atlassian.net/browse/RIPD-344))
|
||||
- Add account\_lines paging ([RIPD-343](https://ripplelabs.atlassian.net/browse/RIPD-343))
|
||||
- Ability to configure network fee in rippled.cfg file ([RIPD-564](https://ripplelabs.atlassian.net/browse/RIPD-564))
|
||||
- Performance
|
||||
- Ledger performance improvements for storage and traversal ([RIPD-434](https://ripplelabs.atlassian.net/browse/RIPD-434))
|
||||
- Improve client performance for JSON responses ([RIPD-439](https://ripplelabs.atlassian.net/browse/RIPD-439))
|
||||
|
||||
<!-- -->
|
||||
|
||||
- Other
|
||||
- Remove PROXY handshake feature
|
||||
- Change to rippled.cfg to support sections containing both key/value pairs and a list of values
|
||||
- Return descriptive error message for memo validation ([RIPD-591](https://ripplelabs.atlassian.net/browse/RIPD-591))
|
||||
- Changes to enforce JSON-RPC 2.0 error format
|
||||
- Optimize account\_lines and account\_offers ([RIPD-587](https://ripplelabs.atlassian.net/browse/RIPD-587))
|
||||
- Improve fee setting logic ([RIPD-614](https://ripplelabs.atlassian.net/browse/RIPD-614))
|
||||
- Improve transaction security
|
||||
- Config improvements
|
||||
- Improve path filtering ([RIPD-561](https://ripplelabs.atlassian.net/browse/RIPD-561))
|
||||
- Logging to distinguish Byzantine failure from tx bug ([RIPD-523](https://ripplelabs.atlassian.net/browse/RIPD-523))
|
||||
|
||||
### **Ripple-lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]**
|
||||
|
||||
*Released version 0.9.3*
|
||||
|
||||
- Change `presubmit` to emit immediately before transaction submit
|
||||
- Add "core" browser build of ripple-lib which has a subset of features and smaller file size
|
||||
- Update binformat with missing fields from rippled
|
||||
- Wait for transaction validation before returning `tec` error
|
||||
- Change default `max_fee` on `Remote` to `1 XRP`
|
||||
- Fix: Request ledger\_accept should return the Remote
|
||||
|
||||
### **Ripple Client [[Release Notes](https://github.com/ripple/ripple-client/releases) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*www.rippletrade.com - released versions 1.1.0, 1.1.1, 1.1.2, and 1.1.3* 1.1.3
|
||||
|
||||
- Add error messages on gateways page
|
||||
- Disable remove button on incoming trust
|
||||
- Orderbook currency precision changes
|
||||
- Update the loading spinners
|
||||
- Remove external jQuery dependency
|
||||
- Fix problems with GBI Send/Convert
|
||||
- Fix release notes link
|
||||
|
||||
1.1.2
|
||||
|
||||
- Add BRL, MXN funding pages
|
||||
- Add client side validation for trusting amount
|
||||
- Code cleanup
|
||||
- Show higher precision for orderbook
|
||||
|
||||
1.1.1
|
||||
|
||||
- Add account deletion feature
|
||||
- Add ripple name support on debug page
|
||||
- Change amount precisions on send, convert, orderbook
|
||||
|
||||
1.1.0
|
||||
|
||||
- Keep user session in sync thru all the browser tabs
|
||||
- Fund UI redesign
|
||||
- Add max network fee change field in advanced tab
|
||||
- Add Balances sidebar for several pages
|
||||
- Add JPY funding page
|
||||
- Add pretend page
|
||||
- Add 404 page
|
||||
- Add tooltip with full Ripple address when hovering over contact
|
||||
- E2E tests for settings dropdown and login
|
||||
- New amount precision rules based on currencies,
|
||||
- Clean up the code according to our js style guide
|
||||
- Update Loading UIs
|
||||
- Remove downloadable client code
|
||||
- Expand history filters by default
|
||||
- Fix contact destination tag deletion
|
||||
- Fix currency on trustline deletion
|
||||
- Generalize currency colors
|
||||
|
||||
**[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)**
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (41,667 XRP)
|
||||
|
||||
### **Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*Released version 1.3.1*
|
||||
|
||||
- Add `validated` query parameter to POST payment, account settings and trustlines. When set to true this will force the request to wait until the transaction has been validated. [f2710f4b](https://github.com/ripple/ripple-rest/commit/f2710f4b78a8c1b9860f2876f6f051022241c641), [1ee9c9ff](https://github.com/ripple/ripple-rest/commit/1ee9c9ff06ada4a14955bf64ed42d7c3c75f5a3e), [f243fef9](https://github.com/ripple/ripple-rest/commit/f243fef9d28be86f593dae11a3fac7421115e5bf)
|
||||
- Add `/v1/transaction-fee` endpoint to retrieve the current fee that connected servers are charging. [212c0bfb](https://github.com/ripple/ripple-rest/commit/212c0bfbcde887db9e9842ef43af062b5ab77598) and [afaa381b](https://github.com/ripple/ripple-rest/commit/afaa381bb5f9a4fdd50f1e35cb1d7990b4926833)
|
||||
- Support `last_ledger_sequence` in POST payments, sets the last ledger this payment can be included in.
|
||||
- Support `max_fee` in POST payments. This will set the maximum fee the user will pay when posting a payment.
|
||||
- Add config entry to configure `max_transaction_fee`. This allows you to set the maximum fee you're willing to pay for any transaction. [Documented changes](https://github.com/ripple/ripple-rest/blob/develop/docs/server-configuration.md)
|
||||
- Save unsubmitted transactions to database
|
||||
60
content/blog/2014/release-notes-29-october-2014.md
Normal file
60
content/blog/2014/release-notes-29-october-2014.md
Normal file
@@ -0,0 +1,60 @@
|
||||
# Release Notes (29 October 2014)
|
||||
|
||||
*Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.*
|
||||
|
||||
*We hope you find these useful! Please let us know if you have feedback in the comments.*
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*No releases*
|
||||
|
||||
### **Ripple-lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]**
|
||||
|
||||
*Released version 0.9.0* 0.9.0
|
||||
|
||||
- Add routes to the vault client for KYC attestations ([ed2da574](https://github.com/ripple/ripple-lib/commit/ed2da57475acf5e9d2cf3373858f4274832bd83f))
|
||||
- Currency: add `show_interest` flag to show or hide interest in `Currency.to_human()` and`Currency.to_json()` [Example use in tests](https://github.com/ripple/ripple-lib/blob/947ec3edc2e7c8f1ef097e496bf552c74366e749/test/currency-test.js#L123)
|
||||
- Configurable maxAttempts for transaction submission ([d107092](https://github.com/ripple/ripple-lib/commit/d10709254061e9e4416d2cb78b5cac1ec0d7ffa5))
|
||||
- Binformat: added missing TransactionResult options ([6abed8d](https://github.com/ripple/ripple-lib/commit/6abed8dd5311765b2eb70505dadbdf5121439ca8))
|
||||
- **Breaking change:** make maxLoops in seed.get\_key optional. [Example use in tests](https://github.com/ripple/ripple-lib/blob/23e473b6886c457781949c825b3ff48b3984e51f/test/seed-test.js)([23e473b](https://github.com/ripple/ripple-lib/commit/23e473b6886c457781949c825b3ff48b3984e51f))
|
||||
- Shrinkwrap packages for dependency locking ([2dcd5f9](https://github.com/ripple/ripple-lib/commit/2dcd5f94fbc71200eb08a5044c76ef94f7971913))
|
||||
- Fix: Amount.to\_human() precision bugs ([4be209e](https://github.com/ripple/ripple-lib/commit/4be209e286b5b209bec7bcd1212098985e15ff2f) and [7708c64](https://github.com/ripple/ripple-lib/commit/7708c64576e70ce3ac190442daceb30e4446aab7))
|
||||
- Fix: change handling of requestLedger options ([57b7030](https://github.com/ripple/ripple-lib/commit/57b70300f5f0c7534ede118ddbb5d8762668a4f8))
|
||||
|
||||
### **Ripple Charts [[Github (frontend)](https://github.com/ripple/ripplecharts-frontend) | [Github (backend)](https://github.com/ripple/ripple-data-api) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
- Added date picker to staging, launching to production soon
|
||||
- Massive [pull request](https://github.com/ripple/ripplecharts-frontend/commit/c656f71d6655ee79755f212393d3107861a9c227) outlining upcoming features
|
||||
|
||||
[***Open bounties***](https://www.bountysource.com/trackers/3954022-ripple-charts)
|
||||
|
||||
- [Value Summary Donut: change details display to better represent IOU/IOU markets](https://www.bountysource.com/issues/3597514-value-summary-donut-change-details-display-to-better-represent-iou-iou-markets) (5,833 XRP)
|
||||
|
||||
### **Ripple Client [[Release Notes](https://github.com/ripple/ripple-client/releases) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*www.rippletrade.com - released version 1.0.11* 1.0.11
|
||||
|
||||
- Numbers after decimals are getting rounded now, not truncated
|
||||
- Snapswap USD funding flow (hidden)
|
||||
- GBI gateway discovery
|
||||
- l10n fixes
|
||||
- Roll back pathfinding changes
|
||||
- new txQueue mechanism
|
||||
- UI cleanup
|
||||
- When logged in on multiple tabs, if you sign out/in on one tab, sign out/in on the other tab
|
||||
|
||||
**[*Open bounties*](https://www.bountysource.com/trackers/3604734-ripple-trade)**
|
||||
|
||||
- [In the "Send" confirmation page, show network and gateway Fees](https://www.bountysource.com/issues/2842674-in-the-send-confirmation-page-show-network-and-gateway-fees) (41,667 XRP)
|
||||
- BOUNTY GRANTED: [Incorrect amount displayed for partial payments](https://www.bountysource.com/issues/2842476-incorrect-amount-displayed-for-partial-payments) (8,333 XRP)
|
||||
|
||||
### **Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*Released version 1.3.0-rc5* 1.3.0-rc5
|
||||
|
||||
- Freeze support ([pull 167](https://github.com/ripple/ripple-rest/pull/167) and [pull 178](https://github.com/ripple/ripple-rest/pull/178))
|
||||
- Memo field support ([pull 154](https://github.com/ripple/ripple-rest/pull/154))
|
||||
- Add `destination_amount_submitted` and `source_amount_submitted` to Payment ([0d3599b](https://github.com/ripple/ripple-rest/commit/0d3599b4057c5cb884eade6bc11c978f8770c943) and[67134e3](https://github.com/ripple/ripple-rest/commit/67134e3ef57b808fc193f2f62579c5681aeb49cc))
|
||||
- New endpoint to generate an address/secret pair, `/wallet/new`
|
||||
- Expose `router` and `remote` as `RippleRestPlugin` to use as a plugin for other modules
|
||||
- Log all connected servers, add reconnect to servers on SIGHUP
|
||||
28
content/blog/2014/release-notes-3-december-2014.md
Normal file
28
content/blog/2014/release-notes-3-december-2014.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Release Notes (3 December 2014)
|
||||
|
||||
*Curated release notes will be posted on this blog and will include updates from every active project. Specifically we will post and link to any new release notes, open bounties, and upcoming features.*
|
||||
|
||||
### **Codius** **[[Github](https://github.com/codius)]**
|
||||
|
||||
- New [website](http://codius.org/) and documentation - check it out!
|
||||
|
||||
### **Ripple-Rest [[Release Notes](https://github.com/ripple/ripple-rest/releases) | [Github](https://github.com/ripple/ripple-rest) | [Issue Tracking](https://ripplelabs.atlassian.net/browse/RA/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel)]**
|
||||
|
||||
*Released version 1.3.2-rc1*
|
||||
|
||||
- Add place and cancel order functionality [d80d198](https://github.com/ripple/ripple-rest/commit/d80d198e18f9c1f96adad8fba4be67b8ae26c4d5)
|
||||
- Support paging behavior for balances and trustlines [6980ab7](https://github.com/ripple/ripple-rest/commit/6980ab7c844508caae5c62ee7202aa429d12ef0b)
|
||||
- Fix parameter discrepancy, `*_froze_line` -\> `*_trustline_frozen` [2701c0b](https://github.com/ripple/ripple-rest/commit/2701c0b9ac481b4e9172b6faaf0d0a4821d6acb5) and [a8aeeec](https://github.com/ripple/ripple-rest/commit/a8aeeeced9b9f896608160a3d34aaedf00e3dc96)
|
||||
- Add tests to show use of complex currencies [9c5412f](https://github.com/ripple/ripple-rest/commit/9c5412f3a0e1498e3108930d38da6157dc764e53)
|
||||
|
||||
### **Rippled [[Release Notes](https://ripple.com/wiki/Category:Rippled_release_notes) | [Github](https://github.com/ripple/rippled) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=25)]**
|
||||
|
||||
*No new releases*
|
||||
|
||||
### **Ripple-lib [[Release Notes](https://github.com/ripple/ripple-lib/releases) | [Github](https://github.com/ripple/ripple-lib) | [Issue Tracking](https://github.com/ripple/ripple-lib/issues)]**
|
||||
|
||||
*No new releases*
|
||||
|
||||
### **Ripple Client [[Release Notes](https://github.com/ripple/ripple-client/releases) | [Github](https://github.com/ripple/ripple-client) | [Issue Tracking](https://ripplelabs.atlassian.net/secure/RapidBoard.jspa?rapidView=2&view=planning&selectedIssue=RT-1990&quickFilter=38&epics=visible)]**
|
||||
|
||||
*No new releases*
|
||||
@@ -0,0 +1,17 @@
|
||||
# Ripple Labs Bounty Program Moves To Bountysource
|
||||
|
||||
_Posted by Daniel Radding_
|
||||
|
||||
The Ripple Labs Bounty Program is moving to its [new home at Bountysource](https://www.bountysource.com/teams/ripple/bounties), a vibrant and robust bounty marketplace that will make paid contributions to the Ripple source code more effective and efficient.
|
||||
|
||||
One of the major benefits of Bountysource is its seamless GitHub integration. You can view Ripple GitHub projects on our team page. Bountysource automatically pulls open issues from these projects. Issues from JIRA can be manually added with a deeplink.
|
||||
|
||||
Anyone can place a bounty on an issue, which is then awarded when a proposed solution is accepted by Ripple Labs. Bounties are paid out in USD, XRP, Bitcoin, or Mastercoin.
|
||||
|
||||
Users can also request proposals to open issues and invite developer bids, get a better sense of the market value of a potential bounty, and prevent redundant efforts.
|
||||
|
||||
And while the Ripple Labs team will be actively placing bounties, anyone can contribute ideas and raise money for development by opening a fundraiser.
|
||||
|
||||
For instance, community member longhaul is pushing for [a fully-featured Ripple wallet for Android](https://www.bountysource.com/teams/instant-ripple/fundraiser). We’ll continue to support community collaboration in the [community-sponsored bounties](https://ripple.com/forum/viewforum.php?f=22) section of the official forums. Third-party projects are hosted on a new Github page called [RippleLabsBounties](https://github.com/ripplelabsbounties) (e.g. client libraries and outbound bridges).
|
||||
|
||||
By making Ripple projects easier to manage and participate in, the Bountysource platform will help us expand and engage with our open source community. We look forward to your contributions!
|
||||
19
content/blog/2014/ripplerest-1.3-release.md
Normal file
19
content/blog/2014/ripplerest-1.3-release.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# ripple-rest 1.3 release
|
||||
|
||||
Last Friday we did a master release of ripple-rest version 1.3.0. We’ve done a few changes externally but the substantial additions in 1.3.0 have been stability and verbose error handling. If you’ve been following the commits on [github](https://github.com/ripple/ripple-rest), we’ve also vastly improved test coverage and introduced simplicity by removing the need for Postgres.
|
||||
|
||||
Below is a list of some of the major changes and an explanation of the decisions we made for this last release.
|
||||
|
||||
- **Improved error handling:** Error handling logic has been rewritten to provide clearer feedback for all requests. Prior to 1.3.0, an error could respond with a 200-299 range HTTP status code stating that the ripple-rest server was able to respond but the request may not have been successful. This put the burden on the developers to parse through the response body to determine whether something was successful or not. In version 1.3.0, ripple-rest will only return a “success” (200-299 range) when the actual request is successful and developers can expect that the response body will match what a successful request looks like. With actual errors and errors responses, ripple-rest will now include an error\_type (a short code identifying the error), an error (a human-readable summary), and an optional message (for longer explanation of errors if needed). Details [here](https://github.com/ripple/ripple-rest/blob/develop/README.old.md#errors).
|
||||
|
||||
- **DB support for SQLite on disk, and removal of Postgres support:** Version 1.3.0 now directly supports both SQLite in memory and on disk. We've removed support for Postgres based on feedback that the installation has been a huge burden for the minimal amount of data that is stored in ripple-rest. The installation with SQLite is now much leaner and configuring a new database is as simple as pointing to a flat file location in the config.json. In the future, we may revisit adding additional database connectors for clustered and high availability deployments, but we’re much more keen on the usability and simplicity of only supporting SQLite at this point.
|
||||
|
||||
- **Config.json 2.0:** The previous config.json 1.0.1 was confusing and disabling things like SSL required removal of lines inside the config file while environment variables could be set to overwrite config file values. We’ve cleaned up a lot of that messiness and we’ve modified the new config.json so that all configurations are fully transparent. SSL can be disabled simply by setting “ssl\_enabled” as false and in order to switch to SQLite in memory the “db\_path” should be set to “:memory:” instead of pointing to a flat file. Lastly, as a reminder to folks who didn’t know, ripple-rest does support a multi-server configuration in the array of “rippled\_servers”. Documentation on config file can be found [here](https://github.com/ripple/ripple-rest/blob/develop/docs/server-configuration.md)
|
||||
|
||||
- **/v1/wallet/new endpoint:** Easy and simple way to generate ripple wallets! No explanation needed!
|
||||
|
||||
- **Removed /v1/tx/{:hash} and /v1/transaction/{:hash}:** Use \`/**v1/transactions/{:hash}\`**. This change serves to provide consistency with REST standards.
|
||||
|
||||
- **Removed /v1/payments:** Use \`**/v1/accounts/{source\_address}/payments\`** to submit a payment. This change serves to provide consistency in the payment flow.
|
||||
|
||||
We appreciate the continued feedback from those of you who are building integrations with ripple-rest and appreciate all the support that you’ve given us so far.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Turn your exchange into a Ripple Gateway
|
||||
|
||||
Throughout 2014 we've talked to businesses all over the world, both big and small, who are interested in tapping into Ripple's increasing liquidity and settlement capabilities. For exchanges dealing in bitcoins and other assets, the value proposition is clear - deeper orderbooks and the ability for customers to hop between different assets instantly is a major boon to their service. The natural follow-up question is how to get started.
|
||||
|
||||
As such, we've developed a [high-level integration guide for exchanges](https://ripple.com/files/exchange_to_ripple_gateway.pdf) that covers the basic accounting concepts of operating a gateway on Ripple and some of the API calls you can use to interact with the network. For the purposes of this guide, we've outlined an example integration for the fictional Acme Bitcoin Exchange. While specifically referencing bitcoins as the asset handled by this gateway, note that the concepts are applicable to other forms of value such as physical commodities, securities, fiat currencies, and more.
|
||||
|
||||
Feel free to email us at <developers@ripple.com> with any questions or thoughts on how this could be improved.
|
||||
23
content/blog/2014/use-of-cpp14-in-rippled.md
Normal file
23
content/blog/2014/use-of-cpp14-in-rippled.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Use of C++14 in rippled
|
||||
|
||||
_Posted by Howard Hinnant_
|
||||
|
||||
C++ is a language under constant development, resulting in alternating minor and major releases. The last major release of C++ was C++11. [A minor release](https://isocpp.org/blog/2014/08/we-have-cpp14) has just been approved by all participating national bodies (zero negative votes). This will be C++14. C++17 is the next planned major release and is currently under development by the committee.
|
||||
|
||||
Rippled has already adopted a number of useful C++14 features. We’ve done this through the development environment where native support is available, or by emulating the features through providing compatible implementations using our beast cxx14 compatibility library ( [https://github.com/ripple/rippled/tree/develop/src/beast/beast/cxx14](https://github.com/ripple/rippled/tree/0.26.2/src/beast/beast/cxx14)).
|
||||
|
||||
<!-- BREAK -->
|
||||
|
||||
A brief list of notable features:
|
||||
|
||||
- Use of [std::make_unique](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3656.htm)<b> </b>for secure and exception safe allocations. For a more in-depth discussion, have a look at this wikipedia article on [Resource Acquisition is Initialization](http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)
|
||||
|
||||
- Simplified use of type transformations with [type aliased type_traits](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3655.pdf). See cppreference.com for [some developer friendly details](http://en.cppreference.com/w/cpp/language/type_alias).
|
||||
|
||||
- Resistance to buffer overrun attacks via [secure <algorithm>](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3671.html)
|
||||
|
||||
- [integer_sequence](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3658.html) facilitates interoperation with the `boost::asio` asynchronous network library
|
||||
|
||||
Like its predecessors, C++14 represents another significant improvement to an already-great language in the area of producing verifiably correct and concise algorithms. Since Ripple Labs operates in the space of financial transactions, the rippled team uses all available tools to ensure that its software behaves predictably and remains auditable to field experts.
|
||||
|
||||
_Howard Hinnant is a Sr. C++ Engineer at Ripple Labs as well as Library Working Group Chair Emeritus at the Standard C++ Foundation. He was lead author of several C++11 features including: move semantics, `unique_ptr`, and the headers `<mutex>`, `<condition_variable>` and `<chrono>`. For C++14 he contributed the `<shared_mutex>` library. Howard was the lead author of the `std::lib` implementation libc++ found at libcxx.llvm.org._
|
||||
@@ -0,0 +1,43 @@
|
||||
# Why the Stellar Forking Issue Does Not Affect Ripple
|
||||
|
||||
The Stellar Development Foundation (SDF) which maintains Stellar, a network built on a modified version of the Ripple code base, recently published a post claiming flaws in the Ripple consensus algorithm. We take any reports about possible security issues very seriously and after reviewing the information conclude that there is no threat to the continued operation of the Ripple network. We'd like to share our thoughts.
|
||||
|
||||
Quoting the post in question:
|
||||
|
||||
> **Issue 1: Sacrificing safety over liveness and fault tolerance—potential for double spends**
|
||||
>
|
||||
> _The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), guaranteed termination or liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of one node at any point). This is a proven result._
|
||||
|
||||
This is correct.
|
||||
|
||||
> _Any distributed consensus system on the Internet must sacrifice one of these features._
|
||||
|
||||
This is potentially misleading. The FLP result shows that no system can provide those guarantees and reach consensus in bounded time. Real-world implementations of consensus like Paxos and Ripple however use probability to achieve safety, liveness and fault tolerance within a given time limit with very high likelihood.
|
||||
|
||||
If consensus is not achieved in this timeframe, the algorithm will retry and once again achieve consensus with very high likelihood and so on. In statistical terms, consensus will eventually be reached with [probability 1](http://en.wikipedia.org/wiki/Almost_surely), satisfying liveness under a probabilistic model. In practice, progress is usually made every round and two or more rounds are very rarely needed.
|
||||
|
||||
This means that distributed consensus systems like the Ripple network and Google’s Spanner database exist and can provide extremely high availability if configured correctly.
|
||||
|
||||
> _The existing Ripple/Stellar consensus algorithm is implemented in a way that favors fault tolerance and termination over safety._
|
||||
|
||||
This is incorrect. We have not reviewed Stellar's modified version of Ripple consensus, but as far as the Ripple consensus algorithm is concerned, the protocol provides safety and fault tolerance assuming the validators are configured correctly. For a detailed proof, please see our [consensus white paper](https://ripple.com/files/ripple_consensus_whitepaper.pdf).
|
||||
|
||||
> _This means it prioritizes ledger closes and availability over everyone actually agreeing on what the ledger is—thus opening up several potential risk scenarios._
|
||||
|
||||
This is incorrect. If a quorum cannot be reached, validators will retry until connectivity has been restored.
|
||||
|
||||
> **Issue 2: Provable correctness**
|
||||
>
|
||||
> _Prof. David Mazières, head of Stanford’s Secure Computing Group, reviewed the Ripple/Stellar consensus system and reached the conclusion that the existing algorithm was unlikely to be safe under all circumstances._
|
||||
|
||||
We look forward to reading Prof. Mazières' findings once they are published.
|
||||
|
||||
> _Based \[on\] these findings, we decided to create a new consensus system with provable correctness._
|
||||
|
||||
As mentioned before, a proof of Ripple's correctness is available in the form of the Ripple [consensus white paper](https://ripple.com/files/ripple_consensus_whitepaper.pdf).
|
||||
|
||||
As Ripple Labs' chief cryptographer and the original developer of Ripple consensus David Schwartz [pointed out yesterday](https://forum.ripple.com/viewtopic.php?f=1&t=8629&p=59073#p59073) _(dead link)_, there cannot be two conflicting majority sets without overlap. For bootstrapping with a small set of trusted validators, it is appropriate to use a crash-recovery fault model, meaning a simple majority such as three out of five is sufficient. In other words, it is impossible for the Ripple network to experience an unintentional ledger fork as Stellar’s did because our nodes require votes from a majority of validators. In the future, we will generally recommend a supermajority greater than two thirds to account for Byzantine faults (validators that act arbitrarily or maliciously), but otherwise the same concepts apply.
|
||||
|
||||
In either case, anyone wishing to join a specific set of mutually consenting validators in the Ripple topology can do so by configuring their local Ripple node appropriately. We recognize the immense task of building the world's first global consensus graph. It is a hard problem, but not an impossible one. Like the transition from Arpanet to the distributed routing topology of the modern internet, it will require time, education and a great deal of caution. But thanks to our amazing partners and colleagues, we are ready to tackle this challenge.
|
||||
|
||||
The Ripple network and its distributed ledger have used the Ripple consensus protocol to operate reliably for two years and currently manage $1.4 million in daily volume. We continue to invest in scaling Ripple to support the world's cross-border transactions with bank partners in the U.S. and Europe actively integrating today.
|
||||
57
content/blog/2014/xrp-giveaway-for-developers.md
Normal file
57
content/blog/2014/xrp-giveaway-for-developers.md
Normal file
@@ -0,0 +1,57 @@
|
||||
# XRP Giveaway for Developers
|
||||
|
||||
Ripple Labs has partnered with [Assembla](https://www.assembla.com/home) to send qualified developers 1,000 XRP to their Ripple Trade account. To apply for this giveaway please fill out and submit [the application form](https://www.assembla.com/ripple). If you’re interested in developing on Ripple please check out the [Primer](https://ripple.com/ripple_primer.pdf) for a high level overview. From there you can dive into different layers of the Ripple ecosystem.
|
||||
|
||||
## Bounties
|
||||
|
||||
The Ripple Labs Development Team is always looking to get the community involved. Check out the [Ripple Bountysource page](https://www.bountysource.com/teams/ripple/bounties), [contribute to the codebase](https://github.com/ripple), and make some XRP!
|
||||
|
||||
## Rippled
|
||||
|
||||
Want to have your own server on the Ripple Network? Set up a rippled Instance and know that you have a secure connection to Ripple. Check out the [installation](https://ripple.com/wiki/Rippled) guide.
|
||||
|
||||
### Ripple Lib API
|
||||
|
||||
Use the [official javascript library](https://github.com/ripple/ripple-lib) to communicate with Ripple.
|
||||
|
||||
### Ripple WebSocket API
|
||||
|
||||
Use the [Websocket Protocol](https://ripple.com/wiki/Websocket_API) to maintain persistent two-way communication with Ripple.
|
||||
|
||||
### JSON-RPC API
|
||||
|
||||
A simple request-response communication via HTTP. For more information, click [here](https://ripple.com/wiki/Sending_RPC_Commands).
|
||||
|
||||
## Middleware
|
||||
|
||||
###
|
||||
|
||||
### Ripple Rest API
|
||||
|
||||
Use the [official REST API](https://github.com/ripple/ripple-rest) to easily interact with Ripple. Check balances, send payments, set trustlines, and more. Additionally, check out the [community made libraries](https://github.com/ripplelabsbounties) for Ripple Rest.
|
||||
|
||||
### Ripple Data API
|
||||
|
||||
Search the vast data stored in closed ledgers through the [Data API](https://github.com/ripple/ripple-data-api).
|
||||
|
||||
## Applications
|
||||
|
||||
### Ripple Trade
|
||||
|
||||
Interested in building a wallet? Check the open source [Ripple Trade Client](https://www.rippletrade.com). Contribute to the [project](https://github.com/ripple/ripple-client) or fork it and make your own!
|
||||
|
||||
### Ripple Charts
|
||||
|
||||
The open source [Ripple Charts Client](https://xrpcharts.ripple.com/) contains beautiful charts and graphs to show what is happening on the Ripple network. Check out the [project on github](https://github.com/ripple/ripplecharts-frontend) where you can contribute and fork the project.
|
||||
|
||||
### Ripple Graph
|
||||
|
||||
Enter a Ripple Wallet address and see beautiful graphs of transaction and trust lines associated with that address using the [Graph Tool](https://ripple.com/graph).
|
||||
|
||||
## Bug Tracking
|
||||
|
||||
You can see the status of our development process on [our JIRA instance](https://ripplelabs.atlassian.net/secure/Dashboard.jspa). Contribute bug reports and feature requests!
|
||||
|
||||
## Collaborative Resources
|
||||
|
||||
We have a Ripple Application Development Skype chat, email <developers@ripple.com> with your Skype handle to join. Additionally, join the Forums to see what the community is up to. If you have any questions don’t hesitate to email <developers@ripple.com>.
|
||||
Reference in New Issue
Block a user