From b4489f86490fb90b7c7707e263ec21b74b07a6c5 Mon Sep 17 00:00:00 2001 From: Amarantha Kulkarni Date: Wed, 24 Jan 2024 12:32:55 -0800 Subject: [PATCH] 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 --- .../biweekly-release-notes-14-august-2014.md | 62 ++ ...iweekly-release-notes-17-september-2014.md | 61 ++ ...biweekly-release-notes-3-september-2014.md | 64 ++ .../biweekly-release-notes-31-july-2014.md | 81 +++ content/blog/2014/curves-with-a-twist.md | 75 +++ .../blog/2014/dev-portal-adds-rippled-apis.md | 29 + ...ateway-advisory-on-partial-payment-flag.md | 7 + .../2014/how-ripple-labs-supports-gateways.md | 42 ++ .../2014/introducing-offer-autobridging.md | 83 +++ content/blog/2014/introducing-ripple-names.md | 54 ++ .../2014/release-notes-14-october-2014.md | 96 +++ .../2014/release-notes-19-november-2014.md | 105 +++ .../2014/release-notes-29-october-2014.md | 60 ++ .../2014/release-notes-3-december-2014.md | 28 + ...bs-bounty-program-moves-to-bountysource.md | 17 + content/blog/2014/ripplerest-1.3-release.md | 19 + ...urn-your-exchange-into-a-ripple-gateway.md | 7 + content/blog/2014/use-of-cpp14-in-rippled.md | 23 + ...ar-forking-issue-does-not-affect-ripple.md | 43 ++ .../blog/2014/xrp-giveaway-for-developers.md | 57 ++ ...ating-balance-changes-for-a-transaction.md | 201 ++++++ .../2015/correction-to-ripple-white-paper.md | 11 + ...-you-have-what-it-takes-to-be-a-gateway.md | 7 + .../blog/2015/gatewayd-no-longer-available.md | 7 + content/blog/2015/introducing-the-data-api.md | 46 ++ ...-update-payment-volume-and-issued-value.md | 22 + content/blog/2015/validator-registry.md | 20 + content/blog/2016/data-api-v2.2.md | 15 + content/blog/2016/flow-available.md | 33 + content/blog/2016/flow-reminder.md | 33 + content/blog/2016/flow-voting.md | 33 + content/blog/2016/flowv2-vetoed.md | 34 + content/blog/2016/flowv2-voting.md | 30 + content/blog/2016/introducing-rippleapi.md | 44 ++ content/blog/2016/multisign-available.md | 34 + content/blog/2016/multisign-reminder.md | 10 + content/blog/2016/rippled-0.30.1.md | 7 + content/blog/2016/rippled-0.31.2-updates.md | 50 ++ content/blog/2016/rippled-0.32.0.md | 48 ++ content/blog/2016/rippled-0.32.1.md | 81 +++ content/blog/2016/rippled-0.33.0-hf1.md | 44 ++ content/blog/2016/rippled-0.33.0.md | 95 +++ content/blog/2016/rippled-0.40.0.md | 80 +++ content/blog/2016/testnet-ledger-reset.md | 32 + content/blog/2016/trustsetauth-available.md | 29 + content/blog/2016/trustsetauth-reminder.md | 26 + content/blog/2016/trustsetauth-voting.md | 16 + .../blog/2017/data-api-load-balancing-test.md | 23 + content/blog/2017/decent-strategy-update.md | 43 ++ .../2017/escrow-paychan-fix1368-reminder.md | 38 ++ .../2017/explanation-of-ripples-xrp-escrow.md | 25 + .../blog/2017/high-scalability-xrp-ledger.md | 11 + content/blog/2017/invariant-checking.md | 26 + .../2017/response-to-china-cert-report.md | 17 + ...an-sustain-1000-transactions-per-second.md | 15 + content/blog/2017/rippled-0.40.1.md | 44 ++ content/blog/2017/rippled-0.50.0.md | 138 ++++ content/blog/2017/rippled-0.50.2.md | 47 ++ content/blog/2017/rippled-0.50.3.md | 59 ++ content/blog/2017/rippled-0.60.0.md | 124 ++++ content/blog/2017/rippled-0.60.1.md | 51 ++ content/blog/2017/rippled-0.60.2-2-rpm.md | 42 ++ content/blog/2017/rippled-0.60.2.md | 56 ++ content/blog/2017/rippled-0.60.3.md | 46 ++ content/blog/2017/rippled-0.70.0.md | 121 ++++ content/blog/2017/rippled-0.70.1.md | 56 ++ content/blog/2017/rippled-0.70.2.md | 51 ++ content/blog/2017/rippled-0.80.0.md | 97 +++ content/blog/2017/rippled-0.80.2.md | 71 +++ content/blog/2017/ticksize-3days.md | 28 + content/blog/2017/ticksize-7days.md | 28 + content/blog/2017/ticksize-available.md | 37 ++ content/blog/2017/ticksize-voting.md | 114 ++++ .../blog/2017/trust-line-quality-sendmax.md | 36 ++ .../blog/2018/data-api-validations-changes.md | 36 ++ .../2018/depositauth-fix1513-available.md | 43 ++ .../2018/depositpreauth-fix1515-enabled.md | 53 ++ .../2018/fix1543-fix1571-fix1623-voting.md | 35 + content/blog/2018/fix1571-enabled.md | 36 ++ .../blog/2018/introducing-history-sharding.md | 51 ++ content/blog/2018/ripple-lib-1.0.0.md | 74 +++ content/blog/2018/rippled-0.81.0.md | 82 +++ content/blog/2018/rippled-0.90.0.md | 160 +++++ content/blog/2018/rippled-0.90.1.md | 92 +++ content/blog/2018/rippled-1.0.0.md | 164 +++++ content/blog/2018/rippled-1.0.1.md | 80 +++ content/blog/2018/rippled-1.1.0.md | 136 ++++ content/blog/2018/rippled-1.1.1.md | 65 ++ content/blog/2018/rippled-1.1.2.md | 84 +++ content/blog/2018/rippled-boost166-warning.md | 33 + .../2018/rippled-validator-key-replacement.md | 94 +++ .../biased-nonce-sense-flowchart-source.uxf | 318 +++++++++ ...rections-to-data-api-xrp-charts-metrics.md | 12 + .../blog/2019/discover-xrp-ledger-explorer.md | 28 + content/blog/2019/fix1578-enabled.md | 37 ++ content/blog/2019/fix1578-expected.md | 55 ++ .../2019/fixmasterkeyasregularkey-1day.md | 42 ++ .../2019/fixmasterkeyasregularkey-enabled.md | 37 ++ .../2019/fixmasterkeyasregularkey-expected.md | 42 ++ .../2019/fixtakerdryofferremoval-enabled.md | 41 ++ content/blog/2019/interledger-checkin.md | 59 ++ .../2019/labeling-the-internet-of-value.md | 161 +++++ content/blog/2019/multisignreserve-enabled.md | 27 + .../blog/2019/multisignreserve-expected.md | 28 + content/blog/2019/rippled-1.2.0.md | 227 +++++++ content/blog/2019/rippled-1.2.1.md | 115 ++++ content/blog/2019/rippled-1.2.2.md | 99 +++ content/blog/2019/rippled-1.2.3.md | 101 +++ content/blog/2019/rippled-1.2.4.md | 100 +++ content/blog/2019/rippled-1.3.1.md | 186 ++++++ content/blog/2019/rippled-1.4.0.md | 316 +++++++++ .../blog/2019/secure-development-practices.md | 46 ++ ...atement-on-the-biased-nonce-sense-paper.md | 25 + content/blog/2019/testnet-reset.md | 44 ++ content/blog/2019/websocket-tool-update.md | 72 +++ content/blog/2019/welcome-to-xrpl-org.md | 9 + content/blog/2019/xrpl-devnet-launch.md | 20 + content/blog/2020/checks-enabled.md | 33 + content/blog/2020/checks-expected.md | 33 + .../blog/2020/deletableaccounts-enabled.md | 38 ++ .../blog/2020/deletableaccounts-expected.md | 74 +++ .../2020/developer-reflections-xrp-toolkit.md | 27 + .../2020/developer-reflections-xrplorer.md | 34 + .../2020/developer-reflections-xrpscan.md | 28 + ...ng-fixpaychanrecipientownerdir-expected.md | 50 ++ ...xpaychanrecipientownerdir-lost-majority.md | 37 ++ .../2020/get-ready-for-deletable-accounts.md | 77 +++ content/blog/2020/moving-devnet-to-vl.md | 70 ++ .../2020/requirefullycanonicalsig-expected.md | 46 ++ ...-fixqualityupperbound-flowcross-enabled.md | 69 ++ .../2020/rippled-1.4.0-upgrade-advisory.md | 74 +++ content/blog/2020/rippled-1.5.0.md | 150 +++++ content/blog/2020/rippled-1.6.0.md | 285 +++++++++ .../2020/running-an-xrp-ledger-validator.md | 43 ++ .../2020/testnet-amendments-rippled-1.5.0.md | 43 ++ content/blog/2020/two-fixes-enabled.md | 40 ++ ...ity-spotlight-developing-wallet-protect.md | 45 ++ content/blog/2021/five-upcoming-amendments.md | 82 +++ content/blog/2021/introducing-xrpl-js.md | 44 ++ .../introducing-xrpl-py-for-pythonistas.md | 36 ++ content/blog/2021/introducing-xrpl4j.md | 27 + ...tions-pt-1-proposal-validation-relaying.md | 139 ++++ content/blog/2021/reserves-lowered.md | 41 ++ .../2021/ripple-lib-drops-lodash-browsers.md | 69 ++ content/blog/2021/rippled-1.7.0.md | 207 ++++++ content/blog/2021/rippled-1.7.2.md | 94 +++ content/blog/2021/rippled-1.7.3.md | 45 ++ content/blog/2021/rippled-1.8.1.md | 83 +++ content/blog/2021/rippled-1.8.2.md | 41 ++ ...r-1-7-improving-efficiency-and-security.md | 36 ++ .../2021/sidechain-engineering-preview.md | 28 + .../blog/2021/three-amendments-expected.md | 60 ++ ...-phase-of-open-decentralized-innovation.md | 88 +++ content/blog/2021/xrpl-node-configurator.md | 170 +++++ content/blog/2022/clio-1.0.0.md | 42 ++ content/blog/2022/cryptoiso20022interop.md | 30 + content/blog/2022/dev-reflections-relaunch.md | 55 ++ ...signerlist-enabled-and-nfts-approaching.md | 70 ++ content/blog/2022/gemwallet.md | 27 + content/blog/2022/get-ready-for-nfts.md | 74 +++ content/blog/2022/introducing-clio.md | 35 + .../blog/2022/introducing-learning-portal.md | 34 + .../2022/introducing-xrpl-py-2.0.0beta.md | 125 ++++ content/blog/2022/nft-devnet-reset.md | 21 + content/blog/2022/nftmaster.md | 23 + .../non-fungible-tokens-are-now-available.md | 61 ++ content/blog/2022/rippled-1.8.4.md | 73 +++ content/blog/2022/rippled-1.8.5.md | 53 ++ content/blog/2022/rippled-1.9.0.md | 112 ++++ content/blog/2022/rippled-1.9.1.md | 98 +++ content/blog/2022/rippled-1.9.2.md | 83 +++ content/blog/2022/rippled-1.9.3.md | 60 ++ content/blog/2022/rippled-1.9.4.md | 82 +++ content/blog/2022/xpmarket.md | 34 + content/blog/2022/ziggurat.md | 29 + content/blog/2023/aesthetes.md | 23 + content/blog/2023/bei-api.md | 26 + content/blog/2023/blockdaemon.md | 39 ++ content/blog/2023/chispend.md | 27 + content/blog/2023/ciso.md | 34 + content/blog/2023/clio-2.0.0.md | 52 ++ content/blog/2023/data-api-v2-deprecated.md | 28 + .../blog/2023/decommissioning-amm-devnet.md | 16 + .../devnet-reset-scheduled-sep-19-2023.md | 47 ++ .../disallowincoming-and-others-expected.md | 99 +++ content/blog/2023/edge.md | 32 + content/blog/2023/fieldboss.md | 27 + content/blog/2023/gemwallet-update.md | 76 +++ content/blog/2023/mandla-money.md | 28 + content/blog/2023/nft-devnet-decommission.md | 33 + content/blog/2023/rippled-1.10.0.md | 184 ++++++ content/blog/2023/rippled-1.11.0.md | 187 ++++++ content/blog/2023/rippled-1.12.0.md | 146 +++++ content/blog/2023/santiment.md | 41 ++ content/blog/2023/stably.md | 28 + .../blog/2023/summarizing-xrpl-docs-iav3.md | 74 +++ content/blog/2023/upcoming-devnet-reset.md | 67 ++ content/blog/2023/xrp-toolkit.md | 35 + content/blog/2023/xrpcafe.md | 39 ++ content/blog/2023/xrpl-py-2.0-release.md | 366 +++++++++++ content/blog/2023/zoetic.md | 32 + content/blog/2024/rippled-2.0.0.md | 232 +++++++ content/blog/2024/web3auth.md | 43 ++ .../blog/img/biased-nonce-sense-flowchart.png | Bin 0 -> 63520 bytes content/blog/img/cryptoiso20022-balances.png | Bin 0 -> 46665 bytes .../img/cryptoiso20022-payment-detail.png | Bin 0 -> 51593 bytes .../blog/img/cryptoiso20022-send-payments.png | Bin 0 -> 33905 bytes .../blog/img/dev-reflections-aesthetes.png | Bin 0 -> 821875 bytes content/blog/img/dev-reflections-bei-api.png | Bin 0 -> 415679 bytes .../img/dev-reflections-blockdaemon-logo.png | Bin 0 -> 42335 bytes .../dev-reflections-blockdaemon-platform.png | Bin 0 -> 185150 bytes content/blog/img/dev-reflections-chispend.png | Bin 0 -> 220745 bytes .../img/dev-reflections-ciso-integration.png | Bin 0 -> 142450 bytes content/blog/img/dev-reflections-edge.png | Bin 0 -> 1062047 bytes .../blog/img/dev-reflections-fieldboss.jpg | Bin 0 -> 154726 bytes .../img/dev-reflections-gemwallet-2023.png | Bin 0 -> 88744 bytes .../blog/img/dev-reflections-gemwallet.png | Bin 0 -> 551629 bytes .../blog/img/dev-reflections-mandla-money.png | Bin 0 -> 748263 bytes .../blog/img/dev-reflections-nftmaster.png | Bin 0 -> 750102 bytes .../img/dev-reflections-santiment-metrics.png | Bin 0 -> 997132 bytes content/blog/img/dev-reflections-stably-1.png | Bin 0 -> 820461 bytes content/blog/img/dev-reflections-stably-2.png | Bin 0 -> 48509 bytes .../img/dev-reflections-web3auth-logo.png | Bin 0 -> 7922 bytes .../blog/img/dev-reflections-web3auth-mpc.png | Bin 0 -> 536332 bytes .../img/dev-reflections-web3auth-signin.png | Bin 0 -> 1146517 bytes .../blog/img/dev-reflections-xpmarket-1.png | Bin 0 -> 874454 bytes .../blog/img/dev-reflections-xpmarket-2.jpg | Bin 0 -> 79636 bytes .../blog/img/dev-reflections-xpmarket-3.jpg | Bin 0 -> 86239 bytes .../blog/img/dev-reflections-xpmarket-4.png | Bin 0 -> 1962133 bytes ...ev-reflections-xrp-toolkit-account-tab.png | Bin 0 -> 200425 bytes ...dev-reflections-xrp-toolkit-escrow-tab.png | Bin 0 -> 163007 bytes ...flections-xrp-toolkit-send-payment-tab.png | Bin 0 -> 129673 bytes .../dev-reflections-xrp-toolkit-trade-tab.png | Bin 0 -> 327028 bytes content/blog/img/dev-reflections-xrpcafe.png | Bin 0 -> 93593 bytes .../blog/img/dev-reflections-xrpscan-1.webp | Bin 0 -> 36614 bytes .../blog/img/dev-reflections-xrpscan-2.webp | Bin 0 -> 28500 bytes .../blog/img/dev-reflections-xrpscan-3.webp | Bin 0 -> 32840 bytes .../blog/img/dev-reflections-xrpscan-4.webp | Bin 0 -> 33112 bytes content/blog/img/dev-reflections-zoetic.png | Bin 0 -> 130587 bytes content/blog/img/devreflections-ziggurat.png | Bin 0 -> 34486 bytes .../blog/img/docs-iav3/xrpl-docs-concepts.png | Bin 0 -> 31880 bytes content/blog/img/docs-iav3/xrpl-docs-home.png | Bin 0 -> 273075 bytes .../docs-iav3/xrpl-docs-infrastructure.png | Bin 0 -> 38281 bytes .../xrpl-docs-revised-introduction.png | Bin 0 -> 174512 bytes .../img/docs-iav3/xrpl-docs-tutorials.png | Bin 0 -> 26153 bytes .../img/docs-iav3/xrpl-docs-use-cases.png | Bin 0 -> 81390 bytes content/blog/img/gatehub-coincover.png | Bin 0 -> 29837 bytes content/blog/img/learning-portal-1.png | Bin 0 -> 478336 bytes .../fig-1-redundant-message-propagation.png | Bin 0 -> 3172 bytes .../fig-2-relay-reduction-concept.png | Bin 0 -> 17429 bytes .../fig-3-spanning-tree-broadcast.png | Bin 0 -> 16742 bytes .../message-routing/fig-4-links-over-time.png | Bin 0 -> 27538 bytes .../blog/img/wstool-curl-syntax-button.png | Bin 0 -> 437 bytes .../blog/img/wstool-error-highlighting.png | Bin 0 -> 22132 bytes .../img/wstool-message-history-management.png | Bin 0 -> 7699 bytes content/blog/img/wstool-permalink-button.png | Bin 0 -> 774 bytes content/blog/img/wstool-server-selector.png | Bin 0 -> 2613 bytes content/blog/img/xrp-toolkit/account-tab.png | Bin 0 -> 92858 bytes content/blog/img/xrp-toolkit/escrow-tab.png | Bin 0 -> 77431 bytes content/blog/img/xrp-toolkit/send-tab.png | Bin 0 -> 71850 bytes content/blog/img/xrp-toolkit/trade-tab.png | Bin 0 -> 127306 bytes .../xrplorer/xrpl-visualized-by-silkjaer.png | Bin 0 -> 1168880 bytes .../xrplorer-amendment-blocked-tweet.png | Bin 0 -> 78363 bytes .../img/xrplorer/xrplorer-anti-scam-tweet.png | Bin 0 -> 377045 bytes .../blog/img/xrplorer/xrplorer-screenshot.png | Bin 0 -> 363957 bytes content/blog/index.md | 10 + content/blog/redirects.yaml | 603 ++++++++++++++++++ content/blog/sidebars.yaml | 239 +++++++ content/docs.page.tsx | 4 +- 269 files changed, 13832 insertions(+), 2 deletions(-) create mode 100644 content/blog/2014/biweekly-release-notes-14-august-2014.md create mode 100644 content/blog/2014/biweekly-release-notes-17-september-2014.md create mode 100644 content/blog/2014/biweekly-release-notes-3-september-2014.md create mode 100644 content/blog/2014/biweekly-release-notes-31-july-2014.md create mode 100644 content/blog/2014/curves-with-a-twist.md create mode 100644 content/blog/2014/dev-portal-adds-rippled-apis.md create mode 100644 content/blog/2014/gateway-advisory-on-partial-payment-flag.md create mode 100644 content/blog/2014/how-ripple-labs-supports-gateways.md create mode 100644 content/blog/2014/introducing-offer-autobridging.md create mode 100644 content/blog/2014/introducing-ripple-names.md create mode 100644 content/blog/2014/release-notes-14-october-2014.md create mode 100644 content/blog/2014/release-notes-19-november-2014.md create mode 100644 content/blog/2014/release-notes-29-october-2014.md create mode 100644 content/blog/2014/release-notes-3-december-2014.md create mode 100644 content/blog/2014/ripple-labs-bounty-program-moves-to-bountysource.md create mode 100644 content/blog/2014/ripplerest-1.3-release.md create mode 100644 content/blog/2014/turn-your-exchange-into-a-ripple-gateway.md create mode 100644 content/blog/2014/use-of-cpp14-in-rippled.md create mode 100644 content/blog/2014/why-the-stellar-forking-issue-does-not-affect-ripple.md create mode 100644 content/blog/2014/xrp-giveaway-for-developers.md create mode 100644 content/blog/2015/calculating-balance-changes-for-a-transaction.md create mode 100644 content/blog/2015/correction-to-ripple-white-paper.md create mode 100644 content/blog/2015/do-you-have-what-it-takes-to-be-a-gateway.md create mode 100644 content/blog/2015/gatewayd-no-longer-available.md create mode 100644 content/blog/2015/introducing-the-data-api.md create mode 100644 content/blog/2015/ripple-charts-update-payment-volume-and-issued-value.md create mode 100644 content/blog/2015/validator-registry.md create mode 100644 content/blog/2016/data-api-v2.2.md create mode 100644 content/blog/2016/flow-available.md create mode 100644 content/blog/2016/flow-reminder.md create mode 100644 content/blog/2016/flow-voting.md create mode 100644 content/blog/2016/flowv2-vetoed.md create mode 100644 content/blog/2016/flowv2-voting.md create mode 100644 content/blog/2016/introducing-rippleapi.md create mode 100644 content/blog/2016/multisign-available.md create mode 100644 content/blog/2016/multisign-reminder.md create mode 100644 content/blog/2016/rippled-0.30.1.md create mode 100644 content/blog/2016/rippled-0.31.2-updates.md create mode 100644 content/blog/2016/rippled-0.32.0.md create mode 100644 content/blog/2016/rippled-0.32.1.md create mode 100644 content/blog/2016/rippled-0.33.0-hf1.md create mode 100644 content/blog/2016/rippled-0.33.0.md create mode 100644 content/blog/2016/rippled-0.40.0.md create mode 100644 content/blog/2016/testnet-ledger-reset.md create mode 100644 content/blog/2016/trustsetauth-available.md create mode 100644 content/blog/2016/trustsetauth-reminder.md create mode 100644 content/blog/2016/trustsetauth-voting.md create mode 100644 content/blog/2017/data-api-load-balancing-test.md create mode 100644 content/blog/2017/decent-strategy-update.md create mode 100644 content/blog/2017/escrow-paychan-fix1368-reminder.md create mode 100644 content/blog/2017/explanation-of-ripples-xrp-escrow.md create mode 100644 content/blog/2017/high-scalability-xrp-ledger.md create mode 100644 content/blog/2017/invariant-checking.md create mode 100644 content/blog/2017/response-to-china-cert-report.md create mode 100644 content/blog/2017/ripple-consensus-ledger-can-sustain-1000-transactions-per-second.md create mode 100644 content/blog/2017/rippled-0.40.1.md create mode 100644 content/blog/2017/rippled-0.50.0.md create mode 100644 content/blog/2017/rippled-0.50.2.md create mode 100644 content/blog/2017/rippled-0.50.3.md create mode 100644 content/blog/2017/rippled-0.60.0.md create mode 100644 content/blog/2017/rippled-0.60.1.md create mode 100644 content/blog/2017/rippled-0.60.2-2-rpm.md create mode 100644 content/blog/2017/rippled-0.60.2.md create mode 100644 content/blog/2017/rippled-0.60.3.md create mode 100644 content/blog/2017/rippled-0.70.0.md create mode 100644 content/blog/2017/rippled-0.70.1.md create mode 100644 content/blog/2017/rippled-0.70.2.md create mode 100644 content/blog/2017/rippled-0.80.0.md create mode 100644 content/blog/2017/rippled-0.80.2.md create mode 100644 content/blog/2017/ticksize-3days.md create mode 100644 content/blog/2017/ticksize-7days.md create mode 100644 content/blog/2017/ticksize-available.md create mode 100644 content/blog/2017/ticksize-voting.md create mode 100644 content/blog/2017/trust-line-quality-sendmax.md create mode 100644 content/blog/2018/data-api-validations-changes.md create mode 100644 content/blog/2018/depositauth-fix1513-available.md create mode 100644 content/blog/2018/depositpreauth-fix1515-enabled.md create mode 100644 content/blog/2018/fix1543-fix1571-fix1623-voting.md create mode 100644 content/blog/2018/fix1571-enabled.md create mode 100644 content/blog/2018/introducing-history-sharding.md create mode 100644 content/blog/2018/ripple-lib-1.0.0.md create mode 100644 content/blog/2018/rippled-0.81.0.md create mode 100644 content/blog/2018/rippled-0.90.0.md create mode 100644 content/blog/2018/rippled-0.90.1.md create mode 100644 content/blog/2018/rippled-1.0.0.md create mode 100644 content/blog/2018/rippled-1.0.1.md create mode 100644 content/blog/2018/rippled-1.1.0.md create mode 100644 content/blog/2018/rippled-1.1.1.md create mode 100644 content/blog/2018/rippled-1.1.2.md create mode 100644 content/blog/2018/rippled-boost166-warning.md create mode 100644 content/blog/2018/rippled-validator-key-replacement.md create mode 100644 content/blog/2019/biased-nonce-sense-flowchart-source.uxf create mode 100644 content/blog/2019/corrections-to-data-api-xrp-charts-metrics.md create mode 100644 content/blog/2019/discover-xrp-ledger-explorer.md create mode 100644 content/blog/2019/fix1578-enabled.md create mode 100644 content/blog/2019/fix1578-expected.md create mode 100644 content/blog/2019/fixmasterkeyasregularkey-1day.md create mode 100644 content/blog/2019/fixmasterkeyasregularkey-enabled.md create mode 100644 content/blog/2019/fixmasterkeyasregularkey-expected.md create mode 100644 content/blog/2019/fixtakerdryofferremoval-enabled.md create mode 100644 content/blog/2019/interledger-checkin.md create mode 100644 content/blog/2019/labeling-the-internet-of-value.md create mode 100644 content/blog/2019/multisignreserve-enabled.md create mode 100644 content/blog/2019/multisignreserve-expected.md create mode 100644 content/blog/2019/rippled-1.2.0.md create mode 100644 content/blog/2019/rippled-1.2.1.md create mode 100644 content/blog/2019/rippled-1.2.2.md create mode 100644 content/blog/2019/rippled-1.2.3.md create mode 100644 content/blog/2019/rippled-1.2.4.md create mode 100644 content/blog/2019/rippled-1.3.1.md create mode 100644 content/blog/2019/rippled-1.4.0.md create mode 100644 content/blog/2019/secure-development-practices.md create mode 100644 content/blog/2019/statement-on-the-biased-nonce-sense-paper.md create mode 100644 content/blog/2019/testnet-reset.md create mode 100644 content/blog/2019/websocket-tool-update.md create mode 100644 content/blog/2019/welcome-to-xrpl-org.md create mode 100644 content/blog/2019/xrpl-devnet-launch.md create mode 100644 content/blog/2020/checks-enabled.md create mode 100644 content/blog/2020/checks-expected.md create mode 100644 content/blog/2020/deletableaccounts-enabled.md create mode 100644 content/blog/2020/deletableaccounts-expected.md create mode 100644 content/blog/2020/developer-reflections-xrp-toolkit.md create mode 100644 content/blog/2020/developer-reflections-xrplorer.md create mode 100644 content/blog/2020/developer-reflections-xrpscan.md create mode 100644 content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.md create mode 100644 content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-lost-majority.md create mode 100644 content/blog/2020/get-ready-for-deletable-accounts.md create mode 100644 content/blog/2020/moving-devnet-to-vl.md create mode 100644 content/blog/2020/requirefullycanonicalsig-expected.md create mode 100644 content/blog/2020/requirefullycanonicalsig-fixqualityupperbound-flowcross-enabled.md create mode 100644 content/blog/2020/rippled-1.4.0-upgrade-advisory.md create mode 100644 content/blog/2020/rippled-1.5.0.md create mode 100644 content/blog/2020/rippled-1.6.0.md create mode 100644 content/blog/2020/running-an-xrp-ledger-validator.md create mode 100644 content/blog/2020/testnet-amendments-rippled-1.5.0.md create mode 100644 content/blog/2020/two-fixes-enabled.md create mode 100644 content/blog/2021/community-spotlight-developing-wallet-protect.md create mode 100644 content/blog/2021/five-upcoming-amendments.md create mode 100644 content/blog/2021/introducing-xrpl-js.md create mode 100644 content/blog/2021/introducing-xrpl-py-for-pythonistas.md create mode 100644 content/blog/2021/introducing-xrpl4j.md create mode 100644 content/blog/2021/message-routing-optimizations-pt-1-proposal-validation-relaying.md create mode 100644 content/blog/2021/reserves-lowered.md create mode 100644 content/blog/2021/ripple-lib-drops-lodash-browsers.md create mode 100644 content/blog/2021/rippled-1.7.0.md create mode 100644 content/blog/2021/rippled-1.7.2.md create mode 100644 content/blog/2021/rippled-1.7.3.md create mode 100644 content/blog/2021/rippled-1.8.1.md create mode 100644 content/blog/2021/rippled-1.8.2.md create mode 100644 content/blog/2021/road-to-xrp-ledger-1-7-improving-efficiency-and-security.md create mode 100644 content/blog/2021/sidechain-engineering-preview.md create mode 100644 content/blog/2021/three-amendments-expected.md create mode 100644 content/blog/2021/xrpl-grants-funding-the-next-phase-of-open-decentralized-innovation.md create mode 100644 content/blog/2021/xrpl-node-configurator.md create mode 100644 content/blog/2022/clio-1.0.0.md create mode 100644 content/blog/2022/cryptoiso20022interop.md create mode 100644 content/blog/2022/dev-reflections-relaunch.md create mode 100644 content/blog/2022/expandedsignerlist-enabled-and-nfts-approaching.md create mode 100644 content/blog/2022/gemwallet.md create mode 100644 content/blog/2022/get-ready-for-nfts.md create mode 100644 content/blog/2022/introducing-clio.md create mode 100644 content/blog/2022/introducing-learning-portal.md create mode 100644 content/blog/2022/introducing-xrpl-py-2.0.0beta.md create mode 100644 content/blog/2022/nft-devnet-reset.md create mode 100644 content/blog/2022/nftmaster.md create mode 100644 content/blog/2022/non-fungible-tokens-are-now-available.md create mode 100644 content/blog/2022/rippled-1.8.4.md create mode 100644 content/blog/2022/rippled-1.8.5.md create mode 100644 content/blog/2022/rippled-1.9.0.md create mode 100644 content/blog/2022/rippled-1.9.1.md create mode 100644 content/blog/2022/rippled-1.9.2.md create mode 100644 content/blog/2022/rippled-1.9.3.md create mode 100644 content/blog/2022/rippled-1.9.4.md create mode 100644 content/blog/2022/xpmarket.md create mode 100644 content/blog/2022/ziggurat.md create mode 100644 content/blog/2023/aesthetes.md create mode 100644 content/blog/2023/bei-api.md create mode 100644 content/blog/2023/blockdaemon.md create mode 100644 content/blog/2023/chispend.md create mode 100644 content/blog/2023/ciso.md create mode 100644 content/blog/2023/clio-2.0.0.md create mode 100644 content/blog/2023/data-api-v2-deprecated.md create mode 100644 content/blog/2023/decommissioning-amm-devnet.md create mode 100644 content/blog/2023/devnet-reset-scheduled-sep-19-2023.md create mode 100644 content/blog/2023/disallowincoming-and-others-expected.md create mode 100644 content/blog/2023/edge.md create mode 100644 content/blog/2023/fieldboss.md create mode 100644 content/blog/2023/gemwallet-update.md create mode 100644 content/blog/2023/mandla-money.md create mode 100644 content/blog/2023/nft-devnet-decommission.md create mode 100644 content/blog/2023/rippled-1.10.0.md create mode 100644 content/blog/2023/rippled-1.11.0.md create mode 100644 content/blog/2023/rippled-1.12.0.md create mode 100644 content/blog/2023/santiment.md create mode 100644 content/blog/2023/stably.md create mode 100644 content/blog/2023/summarizing-xrpl-docs-iav3.md create mode 100644 content/blog/2023/upcoming-devnet-reset.md create mode 100644 content/blog/2023/xrp-toolkit.md create mode 100644 content/blog/2023/xrpcafe.md create mode 100644 content/blog/2023/xrpl-py-2.0-release.md create mode 100644 content/blog/2023/zoetic.md create mode 100644 content/blog/2024/rippled-2.0.0.md create mode 100644 content/blog/2024/web3auth.md create mode 100644 content/blog/img/biased-nonce-sense-flowchart.png create mode 100644 content/blog/img/cryptoiso20022-balances.png create mode 100644 content/blog/img/cryptoiso20022-payment-detail.png create mode 100644 content/blog/img/cryptoiso20022-send-payments.png create mode 100644 content/blog/img/dev-reflections-aesthetes.png create mode 100644 content/blog/img/dev-reflections-bei-api.png create mode 100644 content/blog/img/dev-reflections-blockdaemon-logo.png create mode 100644 content/blog/img/dev-reflections-blockdaemon-platform.png create mode 100644 content/blog/img/dev-reflections-chispend.png create mode 100644 content/blog/img/dev-reflections-ciso-integration.png create mode 100644 content/blog/img/dev-reflections-edge.png create mode 100644 content/blog/img/dev-reflections-fieldboss.jpg create mode 100644 content/blog/img/dev-reflections-gemwallet-2023.png create mode 100644 content/blog/img/dev-reflections-gemwallet.png create mode 100644 content/blog/img/dev-reflections-mandla-money.png create mode 100644 content/blog/img/dev-reflections-nftmaster.png create mode 100644 content/blog/img/dev-reflections-santiment-metrics.png create mode 100644 content/blog/img/dev-reflections-stably-1.png create mode 100644 content/blog/img/dev-reflections-stably-2.png create mode 100644 content/blog/img/dev-reflections-web3auth-logo.png create mode 100644 content/blog/img/dev-reflections-web3auth-mpc.png create mode 100644 content/blog/img/dev-reflections-web3auth-signin.png create mode 100644 content/blog/img/dev-reflections-xpmarket-1.png create mode 100644 content/blog/img/dev-reflections-xpmarket-2.jpg create mode 100644 content/blog/img/dev-reflections-xpmarket-3.jpg create mode 100644 content/blog/img/dev-reflections-xpmarket-4.png create mode 100644 content/blog/img/dev-reflections-xrp-toolkit-account-tab.png create mode 100644 content/blog/img/dev-reflections-xrp-toolkit-escrow-tab.png create mode 100644 content/blog/img/dev-reflections-xrp-toolkit-send-payment-tab.png create mode 100644 content/blog/img/dev-reflections-xrp-toolkit-trade-tab.png create mode 100644 content/blog/img/dev-reflections-xrpcafe.png create mode 100644 content/blog/img/dev-reflections-xrpscan-1.webp create mode 100644 content/blog/img/dev-reflections-xrpscan-2.webp create mode 100644 content/blog/img/dev-reflections-xrpscan-3.webp create mode 100644 content/blog/img/dev-reflections-xrpscan-4.webp create mode 100644 content/blog/img/dev-reflections-zoetic.png create mode 100644 content/blog/img/devreflections-ziggurat.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-concepts.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-home.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-infrastructure.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-revised-introduction.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-tutorials.png create mode 100644 content/blog/img/docs-iav3/xrpl-docs-use-cases.png create mode 100644 content/blog/img/gatehub-coincover.png create mode 100644 content/blog/img/learning-portal-1.png create mode 100644 content/blog/img/message-routing/fig-1-redundant-message-propagation.png create mode 100644 content/blog/img/message-routing/fig-2-relay-reduction-concept.png create mode 100644 content/blog/img/message-routing/fig-3-spanning-tree-broadcast.png create mode 100644 content/blog/img/message-routing/fig-4-links-over-time.png create mode 100644 content/blog/img/wstool-curl-syntax-button.png create mode 100644 content/blog/img/wstool-error-highlighting.png create mode 100644 content/blog/img/wstool-message-history-management.png create mode 100644 content/blog/img/wstool-permalink-button.png create mode 100644 content/blog/img/wstool-server-selector.png create mode 100644 content/blog/img/xrp-toolkit/account-tab.png create mode 100644 content/blog/img/xrp-toolkit/escrow-tab.png create mode 100644 content/blog/img/xrp-toolkit/send-tab.png create mode 100644 content/blog/img/xrp-toolkit/trade-tab.png create mode 100644 content/blog/img/xrplorer/xrpl-visualized-by-silkjaer.png create mode 100644 content/blog/img/xrplorer/xrplorer-amendment-blocked-tweet.png create mode 100644 content/blog/img/xrplorer/xrplorer-anti-scam-tweet.png create mode 100644 content/blog/img/xrplorer/xrplorer-screenshot.png create mode 100644 content/blog/index.md create mode 100644 content/blog/redirects.yaml create mode 100644 content/blog/sidebars.yaml diff --git a/content/blog/2014/biweekly-release-notes-14-august-2014.md b/content/blog/2014/biweekly-release-notes-14-august-2014.md new file mode 100644 index 0000000000..b78d8b106a --- /dev/null +++ b/content/blog/2014/biweekly-release-notes-14-august-2014.md @@ -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)) + +  diff --git a/content/blog/2014/biweekly-release-notes-17-september-2014.md b/content/blog/2014/biweekly-release-notes-17-september-2014.md new file mode 100644 index 0000000000..b454942716 --- /dev/null +++ b/content/blog/2014/biweekly-release-notes-17-september-2014.md @@ -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 diff --git a/content/blog/2014/biweekly-release-notes-3-september-2014.md b/content/blog/2014/biweekly-release-notes-3-september-2014.md new file mode 100644 index 0000000000..53cc95f39b --- /dev/null +++ b/content/blog/2014/biweekly-release-notes-3-september-2014.md @@ -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 diff --git a/content/blog/2014/biweekly-release-notes-31-july-2014.md b/content/blog/2014/biweekly-release-notes-31-july-2014.md new file mode 100644 index 0000000000..745cab4659 --- /dev/null +++ b/content/blog/2014/biweekly-release-notes-31-july-2014.md @@ -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* diff --git a/content/blog/2014/curves-with-a-twist.md b/content/blog/2014/curves-with-a-twist.md new file mode 100644 index 0000000000..1016f16fe5 --- /dev/null +++ b/content/blog/2014/curves-with-a-twist.md @@ -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 + +[![Curve25519 compared to secp256k1](https://cdn.ripple.com/wp-content/uploads/2014/06/curved2.png)](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). + +[![DSA process compared to Schnorr process](https://cdn.ripple.com/wp-content/uploads/2014/06/dsa-schnorr.png)](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. diff --git a/content/blog/2014/dev-portal-adds-rippled-apis.md b/content/blog/2014/dev-portal-adds-rippled-apis.md new file mode 100644 index 0000000000..e33b6faaad --- /dev/null +++ b/content/blog/2014/dev-portal-adds-rippled-apis.md @@ -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). + + + +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:** + +[![Old documentation screenshot](https://cdn.ripple.com/wp-content/uploads/2014/08/Screen-Shot-2014-08-01-at-2.45.28-PM.png)](https://cdn.ripple.com/wp-content/uploads/2014/08/Screen-Shot-2014-08-01-at-2.45.28-PM.png) + + +**After:** + +[![New documentation screenshot](https://cdn.ripple.com/wp-content/uploads/2014/08/Screen-Shot-2014-08-01-at-2.47.50-PM1.png)](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 long.) 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. diff --git a/content/blog/2014/gateway-advisory-on-partial-payment-flag.md b/content/blog/2014/gateway-advisory-on-partial-payment-flag.md new file mode 100644 index 0000000000..50f1c4e77e --- /dev/null +++ b/content/blog/2014/gateway-advisory-on-partial-payment-flag.md @@ -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). diff --git a/content/blog/2014/how-ripple-labs-supports-gateways.md b/content/blog/2014/how-ripple-labs-supports-gateways.md new file mode 100644 index 0000000000..543453fbd7 --- /dev/null +++ b/content/blog/2014/how-ripple-labs-supports-gateways.md @@ -0,0 +1,42 @@ +# How Ripple Labs supports gateways + +
This program is no longer active.
+ +_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! diff --git a/content/blog/2014/introducing-offer-autobridging.md b/content/blog/2014/introducing-offer-autobridging.md new file mode 100644 index 0000000000..cd332b03e3 --- /dev/null +++ b/content/blog/2014/introducing-offer-autobridging.md @@ -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. + +[![Autobridging diagram](https://cdn.ripple.com/wp-content/uploads/2014/07/autobridging-graphic.png)](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: _ + +_Follow him on Twitter: [@nbougalis](https://twitter.com/nbougalis)_ diff --git a/content/blog/2014/introducing-ripple-names.md b/content/blog/2014/introducing-ripple-names.md new file mode 100644 index 0000000000..19ea06fdaf --- /dev/null +++ b/content/blog/2014/introducing-ripple-names.md @@ -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. diff --git a/content/blog/2014/release-notes-14-october-2014.md b/content/blog/2014/release-notes-14-october-2014.md new file mode 100644 index 0000000000..21c63713fc --- /dev/null +++ b/content/blog/2014/release-notes-14-october-2014.md @@ -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. diff --git a/content/blog/2014/release-notes-19-november-2014.md b/content/blog/2014/release-notes-19-november-2014.md new file mode 100644 index 0000000000..5187bafc34 --- /dev/null +++ b/content/blog/2014/release-notes-19-november-2014.md @@ -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 diff --git a/content/blog/2014/release-notes-29-october-2014.md b/content/blog/2014/release-notes-29-october-2014.md new file mode 100644 index 0000000000..7beeff81b5 --- /dev/null +++ b/content/blog/2014/release-notes-29-october-2014.md @@ -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 diff --git a/content/blog/2014/release-notes-3-december-2014.md b/content/blog/2014/release-notes-3-december-2014.md new file mode 100644 index 0000000000..04059e4ad1 --- /dev/null +++ b/content/blog/2014/release-notes-3-december-2014.md @@ -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* diff --git a/content/blog/2014/ripple-labs-bounty-program-moves-to-bountysource.md b/content/blog/2014/ripple-labs-bounty-program-moves-to-bountysource.md new file mode 100644 index 0000000000..6ccaab17df --- /dev/null +++ b/content/blog/2014/ripple-labs-bounty-program-moves-to-bountysource.md @@ -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! diff --git a/content/blog/2014/ripplerest-1.3-release.md b/content/blog/2014/ripplerest-1.3-release.md new file mode 100644 index 0000000000..d2ee2cb094 --- /dev/null +++ b/content/blog/2014/ripplerest-1.3-release.md @@ -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. diff --git a/content/blog/2014/turn-your-exchange-into-a-ripple-gateway.md b/content/blog/2014/turn-your-exchange-into-a-ripple-gateway.md new file mode 100644 index 0000000000..42c89dd14f --- /dev/null +++ b/content/blog/2014/turn-your-exchange-into-a-ripple-gateway.md @@ -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 with any questions or thoughts on how this could be improved. diff --git a/content/blog/2014/use-of-cpp14-in-rippled.md b/content/blog/2014/use-of-cpp14-in-rippled.md new file mode 100644 index 0000000000..f8c7989397 --- /dev/null +++ b/content/blog/2014/use-of-cpp14-in-rippled.md @@ -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)). + + + +A brief list of notable features: + +- Use of [std::make_unique](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3656.htm) 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 ``, `` and ``. For C++14 he contributed the `` library. Howard was the lead author of the `std::lib` implementation libc++ found at libcxx.llvm.org._ diff --git a/content/blog/2014/why-the-stellar-forking-issue-does-not-affect-ripple.md b/content/blog/2014/why-the-stellar-forking-issue-does-not-affect-ripple.md new file mode 100644 index 0000000000..cb0b5ef30f --- /dev/null +++ b/content/blog/2014/why-the-stellar-forking-issue-does-not-affect-ripple.md @@ -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. diff --git a/content/blog/2014/xrp-giveaway-for-developers.md b/content/blog/2014/xrp-giveaway-for-developers.md new file mode 100644 index 0000000000..9bc72f958b --- /dev/null +++ b/content/blog/2014/xrp-giveaway-for-developers.md @@ -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 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 . diff --git a/content/blog/2015/calculating-balance-changes-for-a-transaction.md b/content/blog/2015/calculating-balance-changes-for-a-transaction.md new file mode 100644 index 0000000000..3882a17990 --- /dev/null +++ b/content/blog/2015/calculating-balance-changes-for-a-transaction.md @@ -0,0 +1,201 @@ +# Calculating Balance Changes for a Transaction + +## Introduction + +When interacting with Transactions on the Ripple Network you often care about the changes that have been made to a specific account. For example, if you make a payment, you want to know by how much the balance on your account has been decreased. Parsing out the exact balance changes from a transaction can often be complicated and we’ve spend a lot of time to provide a simple method for getting accurate information. In an effort to standardize the way we deal with balance changes and make sure we have one place that captures our efforts, we released a module, called [ripple-lib-transactionparser](https://www.npmjs.com/package/ripple-lib-transactionparser). We’ve made the module available on npm and you can find the source on our [github](https://github.com/ripple/ripple-lib-extensions/tree/master/transactionparser) + +In this post we want to provide some background on why parsing balance changes is hard and give details on how a transaction’s meta should be interpreted. + +### Table of Contents + +- **[Installation Instructions](#installation-instructions)** +- **[Why is parsing transactions hard?](#why-is-parsing-transactions-hard)** +- **[The solution](#the-solution)** +- **[Counterparty vs Issuer](#counterparty-vs-issuer)** +- **[Additonal notes on meta](#additional-notes-on-meta)** + +## Installation Instructions + +To install this package in your Node project, run: + + npm install ripple-lib-transactionparser + +Given a `transactionResponse`, which is a return for a transaction submission or transaction lookup, you can use it as follows: + + var parseBalanceChanges = require(‘ripple-lib-transactionparser’).parseBalanceChanges; + … + var balanceChanges = parseBalanceChanges(transactionResponse.meta); + +## Why is parsing Transactions hard? + +Each host on the Ripple Network runs a program called [rippled](https://github.com/ripple/rippled) that is responsible for maintaining the Ripple ledger and reaching consensus. The rippled application is written in C++ and it’s interface is geared more for machine consumption than human consumption, so it doesn’t directly tell you higher-level information like what balances were affected by a specific transaction. Instead, it provides some `meta` about how various nodes changed in the ledger, which can be used to compute balance changes for transactions that affect balances. + +Extracting the balance changes from a transaction’s meta isn’t straightforward. Objects in the AffectedNodes array describe the changes to nodes in the ledger, but how a balance or a affected account has changed requires some parsing of the given meta. + +### Transaction meta + +Below is an example of what the relevant transaction meta that comes from rippled looks like + + { + "AffectedNodes": [ + { + "ModifiedNode": { + "FinalFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "1.525330905250352" + }, + "Flags": 1114112, + "HighLimit": { + "currency": "USD", + "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", + "value": "0" + }, + "HighNode": "00000000000001E8", + "LowLimit": { + "currency": "USD", + "issuer": "rKmBGxocj9Abgy25J51Mk1iqFzW9aVF9Tc", + "value": "1000000000" + }, + "LowNode": "0000000000000000" + }, + "LedgerEntryType": "RippleState", + "LedgerIndex": "2F323020B4288ACD4066CC64C89DAD2E4D5DFC2D44571942A51C005BF79D6E25", + "PreviousFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "1.535330905250352" + } + }, + "PreviousTxnID": "DC061E6F47B1B6E9A496A31B1AF87194B4CB24B2EBF8A59F35E31E12509238BD", + "PreviousTxnLgrSeq": 10459364 + } + }, + { + "ModifiedNode": { + "FinalFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "0.02" + }, + "Flags": 1114112, + "HighLimit": { + "currency": "USD", + "issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q", + "value": "0" + }, + "HighNode": "00000000000001E8", + "LowLimit": { + "currency": "USD", + "issuer": "rLDYrujdKUfVx28T9vRDAbyJ7G2WVXKo4K", + "value": "1000000000" + }, + "LowNode": "0000000000000000" + }, + "LedgerEntryType": "RippleState", + "LedgerIndex": "AAE13AF5192EFBFD49A8EEE5869595563FEB73228C0B38FED9CC3D20EE74F399", + "PreviousFields": { + "Balance": { + "currency": "USD", + "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", + "value": "0.01" + } + }, + "PreviousTxnID": "DC061E6F47B1B6E9A496A31B1AF87194B4CB24B2EBF8A59F35E31E12509238BD", + "PreviousTxnLgrSeq": 10459364 + } + }, + { + "ModifiedNode": { + "FinalFields": { + "Account": "rKmBGxocj9Abgy25J51Mk1iqFzW9aVF9Tc", + "Balance": "239555992", + "Flags": 0, + "OwnerCount": 1, + "Sequence": 38 + }, + "LedgerEntryType": "AccountRoot", + "LedgerIndex": "E9A39B0BA8703D5FFD05D9EAD01EE6C0E7A15CF33C2C6B7269107BD2BD535818", + "PreviousFields": { + "Balance": "239567992", + "Sequence": 37 + }, + "PreviousTxnID": "DC061E6F47B1B6E9A496A31B1AF87194B4CB24B2EBF8A59F35E31E12509238BD", + "PreviousTxnLgrSeq": 10459364 + } + } + ], + "TransactionIndex": 2, + "TransactionResult": "tesSUCCESS" + } + +The meta above doesn’t make it obvious what the changes are to which accounts without first understanding what `HighNode`, `LowNode`, `...Limit` and the various other fields mean. + +## The solution + +We wrote the `ripple-lib-transactionparser` module to capture the logic needed to parse transaction meta like the above. We spent a lot of time discussing various edge cases and how to correctly parse the balance changes most intuitively. Using the `ripple-lib-transactionparser` the above meta will result in the following balance changes: + + { + rKmBGxocj9Abgy25J51Mk1iqFzW9aVF9Tc: [ + { + value: '-0.01', + currency: 'USD', + counterparty: 'rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q' + }, + { + value: '-0.012', + currency: 'XRP', + counterparty: '' + } + ], + rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q: [ + { + counterparty: 'rKmBGxocj9Abgy25J51Mk1iqFzW9aVF9Tc', + currency: 'USD', + value: '0.01' + }, + { + counterparty: 'rLDYrujdKUfVx28T9vRDAbyJ7G2WVXKo4K', + currency: 'USD', + value: '-0.01' + } + ], + rLDYrujdKUfVx28T9vRDAbyJ7G2WVXKo4K: [ + { + counterparty: 'rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q', + currency: 'USD', + value: '0.01' + } + ] + } + +The keys in the balance changes object (rLDY…) are the affected addresses and the values (in square brackets) are arrays of balance changes that happened on that address. Each balance change is specified with a counterparty, currency, and value, where `counterparty` refers to the address on the opposite end of the trustline. If you’re not a gateway, then the counterparty is typically the issuer of the currency (for a more detailed explanation see the section [Counterparty vs Issuer](#counterparty-vs-issuer) below). + +Let’s look at how these balance changes are computed from the meta. The meta contains an array of AffectedNodes, where each AffectedNode object contains a CreatedNode, ModifiedNode, or DeletedNode, which each correspond to a change in the ledger. The JSON is structured this way, rather than just an array of nodes with the type as a property, so that the node objects can map directly to the corresponding C++ classes. Each node has a LedgerEntryType and there are two types that can indicate a balance change: AccountRoot - holds an account’s XRP balance, last transaction sequence number, and related information RippleState - tracks credit between two accounts and associated properties (corresponds to a trustline) So AccountRoot nodes appear when XRP balances change and RippleState nodes appear when trustline balances change. + +Calculating XRP balance changes from AccountRoot nodes is straightforward; subtract the balance in the FinalFields from the balance in the PreviousFields and convert from drops to XRP (all XRP balances from rippled are specified in drops, where one XRP is equivalent to one million drops). If a new account is created, a CreatedNode will be found instead of a ModifiedNode, in which case PreviousFields won’t exist and FinalFields will be replaced with NewFields. DeletedNodes still have FinalFields and PreviousFields, just like ModifiedNodes. + +Calculating the balance changes for a trustline is similar, but with an additional complication: the sign of the balances are oriented with respect to the `low node`, which is the node with the lower address of the two on the trustline (the address is treated as a numerical value, so for example `rKm…` is lower than `rMw…` since `K` comes before `M` in the [base58 dictionary](https://xrpl.org/base58-encodings.html)). This convention was established in rippled so that the hash of a trustline between A and B is the same as the hash of a trustline between B and A. Therefore, the balance is negated when generating the balance change for the high address. Two balance changes are created for each trustline balance change, one from the perspective of each address on the trustline, which are extracted from the HighLimit and LowLimit objects. + +## Counterparty vs. Issuer + +Through the Ripple products we sometimes use the concept of `issuer` instead of `counterparty`. Ripple-REST for example has been using the term `issuer` and it shows up throughout our documentation. The `issuer` is the party on a trustline that owes the other party, so the party on a trustline that has credited the party. The `counterparty` is the party on the other side of the trustline from the perspective of a given party, regardless of who owes who. For calculating balance changes, `counterparty` is more useful. If we were to use `issuer`, gateways would not be able to see balance changes that shift money between their trustlines because both changes would have the same issuer and would cancel out. A gateway may want to monitor such changes in order to mirror balances to an off-ledger accounting system. + +It might seem like you would need the concept of `issuer` in order to keep track of who issued your USD because only the issuer will redeem it. But any USD that you have on a trustline with a gateway is automatically issued by that gateway. There’s no way to take USD from gateway A and move it to a trustline with gateway B because that would require increasing your balance with gateway B, which is something that only gateway B is allowed to do. If Alice sends SnapSwap-USD to Bob, it moves from Alice’s trustline with SnapSwap to Bob’s trustline with SnapSwap; SnapSwap-USDs never leave SnapSwap’s trustlines. Actually even calling them SnapSwap-USDs makes it sound like the currency itself is tied to SnapSwap, but the currency format doesn’t specify any address for the issuer, so SnapSwap-USDs are really just USDs on a SnapSwap trustline. + +## Additional Notes on meta + +### LowNode and HighNode + +The LowNode and HighNode fields may be confusing. They are hints to make node deletion happen in constant time in rippled and should always be ignored outside of rippled. More precisely, LowNode is the integer number of the page in the low account's owner directory that contains the reference to the trust line. + +### ACCOUNT\_ONE + +The issuer listed in the balance fields is `rrrrrrrrrrrrrrrrrrrrBZbvji`, which is referred to as [ACCOUNT\_ONE](https://xrpl.org/accounts.html#special-addresses) and is the encoding that corresponds to the numerical value 1. This convention is used because the addresses on the trustline are already specified in the HighLimit and LowLimit objects, so specifying them here would be redundant. + +## Conclusion + +Parsing balance changes from a transaction is hard, so we made a module that makes it easy. Find it on NPM: And here's the github: For any issues or questions, please use the github issues page. diff --git a/content/blog/2015/correction-to-ripple-white-paper.md b/content/blog/2015/correction-to-ripple-white-paper.md new file mode 100644 index 0000000000..fe16c25a06 --- /dev/null +++ b/content/blog/2015/correction-to-ripple-white-paper.md @@ -0,0 +1,11 @@ +# Correction to Ripple White Paper + +We've recently been made aware of a [paper](http://www.ghassankarame.com/ripple.pdf) discussing the possibility of forks in the Ripple system. We agree with the authors' conclusion that a fork is not possible given that the UNL overlap is greater than 40%. Unfortunately, this is different than the 20% figure stated in our [2014 white paper](https://ripple.com/consensus-whitepaper/). We apologize for the oversight and are issuing a corrected version. + +We'd like to point out that our validators are in fact configured with an overlap of 100%, which is also our current recommendation to partners. In other words, these new findings confirm our understanding that the live Ripple network has been and continues to be safe from forks. + +In the paper the authors reference “several forks” in distributed ledger protocols, citing two sources. The first one is a blog post about [a fork in the Bitcoin network](https://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-blockchain-fork/). The second is a blog post about [a fork in the Stellar network](https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/). We’d like to point out that neither of these systems use the Ripple consensus protocol in conjunction with our recommended configuration. There has been no such incident on the Ripple network after nearly three years of operation and more than 15 million ledger closes. + +We're excited to see increased interest from the academic community in Ripple consensus. As we work to diversify validator sets, we are also increasing our own efforts to contribute to consensus research. Our 2014 white paper was the first formal description of Ripple-style consensus and there’s a lot more to explore. We're working to provide more detailed descriptions of Byzantine fault tolerance in Ripple and the safety of certain topologies of validators. + +If you are currently in academia studying consensus or graph problems, please reach out to us at . diff --git a/content/blog/2015/do-you-have-what-it-takes-to-be-a-gateway.md b/content/blog/2015/do-you-have-what-it-takes-to-be-a-gateway.md new file mode 100644 index 0000000000..7f62c6de39 --- /dev/null +++ b/content/blog/2015/do-you-have-what-it-takes-to-be-a-gateway.md @@ -0,0 +1,7 @@ +# Do You Have What It Takes to Be a Gateway? + +We're proud to announce the first release of [our new Gateway Guide](https://developers.ripple.com/become-an-xrp-ledger-gateway.html), a comprehensive manual to operating a gateway in the Ripple network. Whether you're trying to understand [how a gateway makes revenue](https://developers.ripple.com/become-an-xrp-ledger-gateway.html#fees-and-revenue-sources), or how to use the [authorized accounts](https://developers.ripple.com/become-an-xrp-ledger-gateway.html#authorized-trust-lines) feature, or even just [what a warm wallet is](https://developers.ripple.com/issuing-and-operational-addresses.html), the gateway guide has you covered. + +The guide comes with step-by-step, diagrammed explanations of typical gateway operations, a hefty [list of precautions](https://developers.ripple.com/become-an-xrp-ledger-gateway.html#precautions) to make your gateway safer, and concrete examples of all the API calls you need to perform in order to get your gateway accounts set up and secure. + +We're proud of all the work we've done to make the business of running a gateway easier, but there's still more work to do. If you have any questions, comments, or ideas, please send feedback to - or post it on our forums. We'd love to hear from you! diff --git a/content/blog/2015/gatewayd-no-longer-available.md b/content/blog/2015/gatewayd-no-longer-available.md new file mode 100644 index 0000000000..a2256cc096 --- /dev/null +++ b/content/blog/2015/gatewayd-no-longer-available.md @@ -0,0 +1,7 @@ +# Gatewayd No Longer Available + +In the interest of focusing our resources on other projects, starting today, Gatewayd will no longer be available on Github. + +Gatewayd was an open-source project that began roughly one year ago, and it was broadly designed for the use-cases we discovered in the open-source community. Throughout the past year, we’ve explored these various use-cases and decided to narrow our focus. As such, we’re working on developing a more focused set of products to support our partners. + +We would like to thank everyone who regularly used gatewayd. We appreciate your ongoing feedback, and we are continuously working on new products to better suit our customers’ needs. More details will be announced in the near future. Please contact us at with any questions. diff --git a/content/blog/2015/introducing-the-data-api.md b/content/blog/2015/introducing-the-data-api.md new file mode 100644 index 0000000000..8e0b23c090 --- /dev/null +++ b/content/blog/2015/introducing-the-data-api.md @@ -0,0 +1,46 @@ +# Introducing the Data API + +Ripple Labs data is moving under one roof, the Data API – a version two of the Historical Database API – and one infrastructure, Hadoop. We are building a much more robust and reliable way to import, parse, and house data that is not taxing on the Ripple network. Housing all of our endpoints together will allow us to scale much faster and with more confidence as the ledger and our data needs grow. + +The Data API also includes a lot of new capabilities, including: + +- historical normalization of currency values against XRP +- added fields for exchanges that show the makers and takers of liquidity +- more information on each account, including the funding source and date +- a new endpoint to show account balance changes +- new metrics in transaction stats + +We are making these changes quickly and are focusing our resources on building out and testing new endpoints. Documentation for the Data API will soon be available on [ripple.com/build](http://ripple.com/build). The API will live at [data.ripple.com](http://data.ripple.com). In the meantime, you can look through the [Data API in GitHub](https://github.com/ripple/rippled-historical-database/blob/develop/README.md). + +Because we are pulling all of the data endpoints under one API, we are shutting down some of our underutilized endpoints that are relying on infrastructure we are not moving forward with. The first shutdown will be CouchDB on August 19th, which we used early on for Ripple Charts. We are replacing some of the endpoints that hit CouchDB in the Data API, but other, less frequently used calls are being removed. In the next few months, we will also be shutting down the Ripple Charts API and replacing aspects of that by expanding the Data API. The Historical Database API – version one – will live in parallel to the Data API as we make this transition. It will be deprecated by the end of the year. + +The following endpoints will be shut down: + +- /api/totalNetworkValue +- /api/totalValueSent +- /api/valueSent +- /api/offers +- /api/currencyBalances +- /api/accounttransactionstats +- /api/accounttrust +- /api/ledgersclosed + + +The following endpoints will be replicated on the Data API: + +| Current | Data API | +|:----------------------------|:--------------------------------| +| /api/offersExercised | /v2/exchanges | +| /api/exchangeRates | /v2/exchange_rates | +| /api/topMarkets | TBD | +| /api/totalIssued | TBD | +| /api/totalPaymentVolume | TBD | +| /api/payments | TBD | +| /api/accountsCreated | /v2/accounts | +| /api/gateways | TBD | +| /api/currencies | TBD | +| /api/marketTraders | TBD | +| /api/issuerCapitalization | TBD | +| /api/accounttransactions | /v2/accounts/:account/payments | +| /api/accountoffersexercised | /v2/accounts/:account/exchanges | +| /api/transactionstats | /v2/stats | diff --git a/content/blog/2015/ripple-charts-update-payment-volume-and-issued-value.md b/content/blog/2015/ripple-charts-update-payment-volume-and-issued-value.md new file mode 100644 index 0000000000..05babbb4c2 --- /dev/null +++ b/content/blog/2015/ripple-charts-update-payment-volume-and-issued-value.md @@ -0,0 +1,22 @@ +# Ripple Charts Update: Payment Volume and Issued Value + +Starting today, we are rolling out a small update to Ripple Charts that may seem minor but hopefully will have a big impact in the way we look at Ripple in the future. + +On the Ripple Charts landing page we will be replacing two items: + +## 1. "Transaction Volume" will be now changed to "Payment Volume" + +We wanted to clearly distinguish that this number was specifically tracking payment transactions separate from any other transaction. Since the term transaction can mean many things in Ripple, we hope this adjustments makes things more clear. + +![payment charts screenshot](https://cdn.ripple.com/wp-content/uploads/2015/06/payment-charts.jpg) + +## 2. "Total Network Value" will be broken down into two separate numbers, "XRP Capitalization" and "Issued Value" + +As we spend more and more effort around building liquid assets on the Network, we didn't want to specifically tie real fiat currency assets with the volatility of XRP. + +As many users pointed out in the forums, "Total Network Value" often ranged quite a bit due to the large influence of XRP price. We believe that this new addition will allow us to watch our issued value grow on the network while still being able to track the value of XRP going forward as well. + +![issued charts screenshot](https://cdn.ripple.com/wp-content/uploads/2015/06/issuedcharts.jpg) + + +We’d like to thank all of our passionate fans who regularly use Ripple Charts. We love and appreciate your ongoing feedback given our commitment to improving the charts experience—not only from the perspective of user experience but also in a way that best reflects the evolving direction of Ripple Labs. diff --git a/content/blog/2015/validator-registry.md b/content/blog/2015/validator-registry.md new file mode 100644 index 0000000000..a547b306d9 --- /dev/null +++ b/content/blog/2015/validator-registry.md @@ -0,0 +1,20 @@ +# Validator Registry + +At Ripple Labs, our goal is to expand the size and diversity of the Ripple consensus network by enabling people to easily run rippled validators and understand how those validators perform. We aim to create a network where validating participants are well known and respected by gathering and publicizing identity information of validators in addition to performance statistics. + +Today, we are excited to announce the launch of the Ripple Validator Registry at [xrpcharts.ripple.com/#/validators](https://xrpcharts.ripple.com/#/validators). The Validator Registry gathers and publishes data for all network validators, enabling rippled operators to determine which validators to trust. An [http-based API](https://data.ripple.com/v2/network/validators) is also available for dynamically constructing rippled configurations. + + +## Build a UNL +Running rippled involves selecting a UNL - a unique node list of trusted validators. There are two primary factors in determining validator trustworthiness: performance and operator identity. + +### Performance +The Validator Registry provides several metrics for each validator based on uptime and network agreement: + +- agreement - the percentage of ledgers that passed consensus that were validated by the validator +- disagreement - the percentage of ledgers validated by the validator that did not pass consensus + +### Identity +Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they operate by following the steps on the [Ripple Dev Portal](https://ripple.com/build/rippled-apis/rippled-setup/#domain-verification). The Validator Registry verifies these domains and lists them with the validators. + +As the consensus network continues to grow, we hope the Validator Registry plays a key role in decentralizing and strengthening the network through open data. diff --git a/content/blog/2016/data-api-v2.2.md b/content/blog/2016/data-api-v2.2.md new file mode 100644 index 0000000000..69b6f902d2 --- /dev/null +++ b/content/blog/2016/data-api-v2.2.md @@ -0,0 +1,15 @@ +# Data API v2.2 Released + +The Data team is proud to announce the release of the [Ripple Data API v2.2](https://github.com/ripple/rippled-historical-database/releases/tag/v2.2.0)! This release includes lots of new features, including a total of 15 new methods, improvements in data quality, and documentation. + +One of the biggest changes in the new version is the incorporation of data relating to the Ripple network itself. This includes expanded information on [validator reports](https://ripple.com/build/data-api-v2/#get-daily-validator-reports), [network topology](https://ripple.com/build/data-api-v2/#get-topology), and the [XRP transaction costs](https://ripple.com/build/data-api-v2/#get-transaction-costs) currently being paid to the network. You can interact with all of the new methods using our [Data API Tool](https://ripple.com/build/data-api-tool/). + +Also part of the new release is a method to calculate the [distribution of XRP](https://ripple.com/build/data-api-v2/#get-xrp-distribution) from Ripple (the company) to others, along with the total amount of XRP in existence. The [XRP Portal](https://ripple.com/xrp-portal/) is already using the new method to report the most recent totals automatically. + +For more information, check out the following resources: + +* [Data API Docs in the Ripple Developer Center](https://ripple.com/build/data-api-v2/) +* [Data API source code](https://github.com/ripple/rippled-historical-database) +* [Data visualizations on Ripple Charts](https://xrpcharts.ripple.com/) + +We look forward to seeing what you developers can do with all this data! diff --git a/content/blog/2016/flow-available.md b/content/blog/2016/flow-available.md new file mode 100644 index 0000000000..cac441827f --- /dev/null +++ b/content/blog/2016/flow-available.md @@ -0,0 +1,33 @@ +# The Flow Amendment is Now Available + +The Flow Amendment became available on the Ripple Consensus Ledger in ledger 24,970,753 [(2016-10-21T19:47:22Z)](https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC). + +This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling. + + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to version 0.33.0 or later, immediately, for service continuity.** + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.33.0 or later, immediately, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +For other platforms, please [compile version 0.33.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2016/flow-reminder.md b/content/blog/2016/flow-reminder.md new file mode 100644 index 0000000000..0e93324434 --- /dev/null +++ b/content/blog/2016/flow-reminder.md @@ -0,0 +1,33 @@ +# The Flow Amendment Will Soon Be Available + +A majority of `rippled` validators voted to enable the [Flow Amendment](https://ripple.com/build/amendments/#flow), which is scheduled to become active on the protocol on Thursday, 2016-10-20. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling. + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to version 0.33.0 or later by Thursday, 2016-10-20, for service continuity.** + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.33.0 by Thursday, 2016-10-20, when Flow is expected to be enabled via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments + +If the Flow amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +## Learn, ask questions, and discuss + +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2016/flow-voting.md b/content/blog/2016/flow-voting.md new file mode 100644 index 0000000000..a38df5a47a --- /dev/null +++ b/content/blog/2016/flow-voting.md @@ -0,0 +1,33 @@ +# The Flow Amendment is Open for Voting + +Originally introduced in `rippled` [version 0.32.1](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), but later [vetoed](https://developers.ripple.com/blog/2016/flowv2-vetoed.html) after a flaw was discovered in the code while testing, the new [Flow Amendment](https://ripple.com/build/amendments/#flow) is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new payments engine adds no new features, but improves efficiency and robustness in payment handling. + + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to version 0.33.0 by Thursday, 2016-10-20, for service continuity.** + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.33.0 by Thursday, 2016-10-20, when Flow is expected to be enabled via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments + +If the Flow amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2016/flowv2-vetoed.md b/content/blog/2016/flowv2-vetoed.md new file mode 100644 index 0000000000..55458008f3 --- /dev/null +++ b/content/blog/2016/flowv2-vetoed.md @@ -0,0 +1,34 @@ +# The FlowV2 Amendment Was Vetoed + +## Background + +[Originally](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), the [FlowV2 amendment](https://ripple.com/build/amendments/#flowv2) was planned to replace `rippled`’s payment processing engine with a more robust and efficient implementation. It was previously expected to become active on Wednesday, 2016-08-24. + +## FlowV2 Was Vetoed + +The `rippled` team found a flaw in FlowV2 while testing. As a result, the Ripple network has [vetoed](https://ripple.com/build/amendments/#amendment-voting) the new payment engine amendment. + +A corrected version of the payment processing engine has been created and is now undergoing further testing. It is scheduled to be included in a future version of `rippled` as an amendment called [Flow](https://github.com/seelabs/rippled/blob/6466629f935821583eeddadbd06fabd9ea0875d0/src/ripple/app/main/Amendments.cpp#L50-L51). + +This demonstrates the robustness of Ripple’s amendment process. The review period and governance code with vetoing working as intended. + +## Action Recommended + +No action is currently required. However, Ripple recommends that validator operators also veto the FlowV2 amendment to ensure it does not regain a majority. + +To veto the amendment, add the following, single line, under the `[veto_amendments]` stanza to the `rippled.cfg` file on validators: + +``` +5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 FlowV2 +``` + +## Learn, Ask Questions, and Discuss + +Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: + +### Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: +* XRP Chat: diff --git a/content/blog/2016/flowv2-voting.md b/content/blog/2016/flowv2-voting.md new file mode 100644 index 0000000000..284cbc90e6 --- /dev/null +++ b/content/blog/2016/flowv2-voting.md @@ -0,0 +1,30 @@ +# The FlowV2 Amendment is Open for Voting + +The [FlowV2 Amendment](https://ripple.com/build/amendments/#flowv2) is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the FlowV2 engine. The new version of the payment processing engine is intended to follow the same rules as the old engine. However, the new engine occasionally produces different results due to floating point rounding. + +The FlowV2 Engine also makes it easier to improve and expand the payment engine with further Amendments. Ripple’s validators will vote in favor of the FlowV2 amendment. We expect the new feature to become active on Wednesday, 2016-08-24. + +## Actions Required + +If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24 for the best performance. + +**Note:** A previous version of this post incorrectly stated that backend software must be updated to construct transactions for the new payment processing engine. The process of creating and submitting transactions for the FlowV2 payment engine is the same as for the previous payment engine. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24 (when FlowV2 is expected to become available via Amendment) then your server will become "amendment blocked" and unable to process transactions or evaluate the validity of ledgers. + +For instruction on updating `rippled` on supported platforms, see: + +For other platforms, please compile version 0.32.1 from source. For details, see + +## Learn, Ask Questions, and Discuss + +Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: + +## Other Resources + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: support@ripple.com +* XRP Chat: diff --git a/content/blog/2016/introducing-rippleapi.md b/content/blog/2016/introducing-rippleapi.md new file mode 100644 index 0000000000..020f997c29 --- /dev/null +++ b/content/blog/2016/introducing-rippleapi.md @@ -0,0 +1,44 @@ +# Introducing RippleAPI + +Ripple is proud to announce an improved, unified interface to the Ripple Consensus Ledger: the new **RippleAPI**! RippleAPI merges ripple-lib and Ripple-REST into a single high-level interface for JavaScript that is fully-documented, fully-tested, schema-validated, stateless, and easier to use. + +If you’re excited to get started with the new RippleAPI right away, jump right in with the following resources: + +1. [RippleAPI Beginners Guide](https://ripple.com/build/rippleapi-beginners-guide/) - A tutorial that introduces the basics of RippleAPI, even if you have minimal prior experience writing JavaScript applications. +2. [RippleAPI Reference](https://ripple.com/build/rippleapi/) - A thorough reference of all methods and features contained in the new API. +3. [Sample Code](https://github.com/ripple/ripple-lib/tree/develop/docs/samples) - Additional code samples for a growing variety of use cases. +4. [`ripple-lib` on GitHub](https://github.com/ripple/ripple-lib) - The RippleAPI source code is available under an open-source license so you can freely download, modify, and contribute back to the project. + +For more information on how and why we built RippleAPI, read on. + +## Background and Rationale + +Prior to RippleAPI, there were three very different APIs to the Ripple Consensus Ledger: + +1. The `rippled` APIs: a low-level interface, not designed for ease of use. +2. The ripple-lib API: a low-level javascript interface, largely undocumented +3. The Ripple-REST API: a high-level HTTP interface + +In order to better focus our efforts as a company, as well as providing a better experience for all users, we merged \#2 and \#3 into a single high-level JavaScript interface. + +Unfortunately, all good things come to an end, and this is the end of the line for Ripple-REST. We are no longer developing or supporting Ripple-REST, and we recommend you migrate your applications away from it. Fortunately, RippleAPI also includes an [experimental REST-like HTTP API](https://github.com/ripple/ripple-lib/blob/0.17.1/src/index.js#L7-L8), although this interface is currently unsupported. + +Meanwhile, the [`rippled` APIs](https://ripple.com/build/rippled-apis/) continue to provide an alternative method of interacting with the Ripple Consensus Ledger, providing maximum power at a cost of increased complexity, so you can choose the tradeoffs that are best for your use case. + +## Source Code Improvements + +The RippleAPI source code is written in ECMAScript 6 (the latest JavaScript standard) and uses [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) to return values from asynchronous calls. The new source code also follows many of the paradigms of [functional programming](https://en.wikipedia.org/wiki/Functional_programming). The result is that the we reduced 15,000 lines of source code in ripple-lib and 6,000 lines in Ripple-REST to just 4,000 lines total in RippleAPI. + +For better organization, we used the “weak layering principle” to structure the source, according to which each layer can only depend on layers below it. This means that the source files are structured into subdirectories and there are very few imports that reach into parent or sibling directories. + +## Testing and Documentation + +RippleAPI comes with a comprehensive array of tests, including 100% unit test coverage, integration tests for every method, flow type checking, ESLint checks, and automated testing of the documentation. + +All API methods have JSON schemas that specify the return values and parameter types. The unit tests use the schemas to validate the return values, which guarantees that the API results are consistent with expectations. + +We generate human-readable documentation using Embedded JavaScript, which utilizes the schemas to generate parameter tables and the test fixtures as code samples. Every Git commit comes with the latest copy of the resulting Markdown documentation, thanks to unit tests which ensure that the documentation has been re-generated whenever changes are made. As long as the unit tests are passing, the documentation is consistent with the tests, and therefore with the source code. + +## Conclusion + +We hope that RippleAPI will help developers harness the power of the Ripple Consensus Ledger. So [get started](https://xrpl.org/get-started-with-rippleapi-for-javascript.html), and let us know on the forums how we’re doing! diff --git a/content/blog/2016/multisign-available.md b/content/blog/2016/multisign-available.md new file mode 100644 index 0000000000..bea7ea1b8d --- /dev/null +++ b/content/blog/2016/multisign-available.md @@ -0,0 +1,34 @@ +# Multi-Signing Now Available # + +As [predicted previously](https://developers.ripple.com/blog/2016/multisign-reminder.html), multi-signing became available on the Ripple Consensus Ledger this afternoon in Pacific time ([2016-06-27T11:34:41Z](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7), to be exact). + +Multi-signing provides more flexibility for sending transactions from your Ripple address. You can use multi-signing alongside a master key pair or regular key pair, or you can disable your other keys and use multi-signing exclusively. You can set and update a list of up to 8 signers, with customizable weights and quorum enabling many different use cases. The members of your signer list can be any Ripple addresses, whether they're funded addresses in the ledger or not. + +Institutional users, in particular, can use the greater security of requiring multiple keys stored in different places to protect high-value addresses and large XRP holdings. Makers and experimenters should find lots of potential applications relating to internet-of-things and smart contracts. Here are just a few ideas of ways you might set up multi-signing for an address: + +- **N-factor Auth:** Store 2 or more keys on different devices, and require all the devices to sign each transaction. +- **M-of-N:** Give keys to multiple people, and require a majority of signers to sign each transaction. +- **Delegate a backup plan:** Designate a team of people who can send transactions for you by working together, in case you're unavailable. Keep using single signatures for normal business. +- **Primary and Approvals:** Use the weights in your signer list to require a specific signer along with at least one other. + +The Ripple Consensus Ledger's multi-signing feature also allows signers to independently rotate their keys, for even greater security. Here's a brief look at how: + +1. Include the signer's address in your SignerList. +2. Fund the signer's address in the ledger. +3. Assign a [Regular Key Pair](https://ripple.com/build/transactions/#setregularkey) to the signer's address and disable its master key. (Funded addresses can only sign using their master key pair if it's not disabled.) +4. Have that signer use its regular key pair to contribute to your multi-signatures. + + +## Further Reading ## + +- [Multi-Signing Summary](https://ripple.com/build/transactions/#multi-signing) +- [How to Multi-Sign](https://ripple.com/build/how-to-multi-sign/) +- [MultiSign Amendment](https://ripple.com/build/amendments/#multisign) + + +## Other resources: ## + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: [support@ripple.com](mailto:support@ripple.com) +* XRP Chat: diff --git a/content/blog/2016/multisign-reminder.md b/content/blog/2016/multisign-reminder.md new file mode 100644 index 0000000000..b5263b4f7a --- /dev/null +++ b/content/blog/2016/multisign-reminder.md @@ -0,0 +1,10 @@ +# Multi-Signing Will Soon Be Available # + +The multi-signing amendment is currently supported by the majority of voting validators on Ripple, and is scheduled to become active on the protocol on Monday, **2016-06-27**. For more information, please see the multi-signing documentation in the Ripple Developer Portal: + +* [How to Multi-Sign](https://ripple.com/build/how-to-multi-sign/) +* [MultiSign Amendment Information](https://ripple.com/build/amendments/#multisign) + +To continue receiving updates about the `rippled` server, please subscribe to the Ripple Server Google Group: + + diff --git a/content/blog/2016/rippled-0.30.1.md b/content/blog/2016/rippled-0.30.1.md new file mode 100644 index 0000000000..678492c4c9 --- /dev/null +++ b/content/blog/2016/rippled-0.30.1.md @@ -0,0 +1,7 @@ +# rippled 0.30.1 Released + +The latest version of `rippled`, the core server of the Ripple Consensus Ledger, is here! Version 0.30.1 contains lots of small features and improvements, including updates to account\_offers, server\_info, peer subscriptions, and more. It also adds several optimizations to the consensus process that have already led to a dramatic increase in the number of ledgers validated per day! Learn more: + +- See the full [rippled 0.30.1 Release Notes](https://github.com/ripple/rippled/releases/0.30.1). +- See our [installation instructions](https://ripple.com/build/rippled-setup/#installing-rippled) to set up `rippled` yourself. +- Visit the [Developer Center](https://ripple.com/build/) for more information on how to use the Ripple Consensus Ledger. diff --git a/content/blog/2016/rippled-0.31.2-updates.md b/content/blog/2016/rippled-0.31.2-updates.md new file mode 100644 index 0000000000..a003cf6b83 --- /dev/null +++ b/content/blog/2016/rippled-0.31.2-updates.md @@ -0,0 +1,50 @@ +# rippled 0.31.2 and Other Updates + +The `rippled` team is proud to announce a bundle of related news items: + +* [`rippled` release 0.31.2](#rippled-0312) +* [Amendments system](#amendments-system) +* [Transaction cost changes](#transaction-cost-changes) +* [Multi-signing](#multi-signing) + +## rippled 0.31.2 ## + +`rippled` 0.31 introduced several new features, including Amendments, Multi-Signing, a transaction queue, and changes to transaction cost escalation. Version 0.31.2 includes important fixes for security, stability, and compatibility with the official validators run by Ripple (the company). + +We recommend all users, especially validators, upgrade as soon as possible: + +* For Red Hat Enterprise Linux 7 or CentOS, you can [update to the new version using `yum`](https://ripple.com/build/rippled-setup/#updating-rippled). +* For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). +* For more information, see the `rippled` [0.31.2 release notes](https://github.com/ripple/rippled/releases/tag/0.31.2) and [0.31.0 release notes](https://github.com/ripple/rippled/releases/tag/0.31.0) on GitHub. + +## Amendments System ## + +Amendments are a new feature introduced in `rippled` 0.31.0. The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The first amendment, FeeEscalation, is already live, having been approved on 2016-05-05. This amendment provides improvements to the handling of transactions when the network is under load. + +The next amendment, MultiSign, introduces a way to authorize transactions using multiple signatures, for greater security and flexibility. + +For more information, see [Amendments in the Ripple Developer Center](https://ripple.com/build/amendments/). + +## Transaction Cost Changes ## + +We have brought two significant changes to [transaction costs](https://ripple.com/build/transaction-cost/) in the `rippled` 0.31 releases. First, the FeeEscalation amendment changed the way the network escalates transaction costs under load. Second, `rippled` 0.31.2 has decreased the minimum transaction cost back to its previous value of 0.00001 XRP (10 drops). + +Previously, transaction costs tended to spike rapidly when the network was under load and drop quickly when the backlog was processed, causing network volatility. As a temporary fix, Ripple configured the official validating servers to always report a load multiplier of 1000 or more. This effectively increased transaction costs from 0.00001 XRP to 0.01 XRP. + +The FeeEscalation amendment, introduced in `rippled` 0.31.0 and approved by consensus on 2016-05-05, fixes this problem. The new algorithm dynamically adjusts the transaction cost based on the number of unconfirmed transactions relative to the number the network is able to confirm each round. The new algorithm reduces volatility and gives users more control over the XRP costs they pay for transactions. + +An integral part of the new transaction cost algorithm is a transaction queue. If transaction costs rise because of high network load, users can submit low priority, legitimate transactions to the transaction queue to be considered for future ledgers when load decreases and transaction costs drop. The queue also makes transactions submitted during high traffic periods more likely to succeed. + +With the new algorithm in place, the transaction cost escalation actually works better without the load multiplier artificially increased. Consequently, `rippled` version 0.31.2 removes the 1000× minimum from the load multiplier. Effective immediately, the minimum transaction cost is back to 0.00001 XRP. When load on the consensus network is higher, you can queue a transaction for a later ledger by paying this cost, or pay a higher XRP cost to get into the current open ledger. (How much higher depends on how large the transaction backlog is.) + +## Multi-signing ## + +The `rippled` team is excited to announce that the next feature to be enabled by Amendment is the ability to multi-sign transactions. Multi-signing is a new way of authorizing transactions for the Ripple Consensus Ledger, using multiple secret keys. After setting up multi-signing for an account, you can put the master secret in cold storage, or even disable the master key entirely. With multiple secret keys required to authorize a multi-signature, you can improve security in many ways. + +Ripple plans to configure its validators to start voting in favor of the MultiSign amendment on 2016-06-13. If the feature maintains a majority for two weeks after that, multi-signing will become an active part of the protocol starting **2016-06-27**. + +For more information, see the following articles in the Ripple Developer Center: + +* [MultiSign Amendment](https://ripple.com/build/amendments/#multisign) +* [Multi-Signing transaction reference](https://ripple.com/build/transactions/#multi-signing) +* [How to Multi-Sign Tutorial](https://ripple.com/build/how-to-multi-sign/) diff --git a/content/blog/2016/rippled-0.32.0.md b/content/blog/2016/rippled-0.32.0.md new file mode 100644 index 0000000000..753941a4d5 --- /dev/null +++ b/content/blog/2016/rippled-0.32.0.md @@ -0,0 +1,48 @@ +# rippled version 0.32.0 has been released # + +Ripple is proud to announce the release of `rippled` version 0.32.0. This release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to the new version. + +Highlights of this release include: + +* The transaction queue now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. This encourages liquidity for XRP since important transactions now have a more reliable way of getting into the ledger. For more information, see [Queued Transactions](https://ripple.com/build/transaction-cost/#queued-transactions) in the Ripple Developer Portal. +* The `server_info` and `server_state` commands now include information on transaction cost multipliers. Customers who want to robustly submit transactions now have additional tools for accurately setting the fee based on changing network conditions. Furthermore, the `fee` command is now available to unprivileged users. For more information, see the [`rippled` API Method Reference](https://ripple.com/build/rippled-apis/#api-methods) in the Ripple Developer Portal. +* There's a new WebSocket implementation based on [Beast](https://github.com/vinniefalco/Beast). Use of this implementation is optional. A future version of `rippled` will make this WebSocket implementation the default, with the old implementation removed. + +Read the complete [release notes in GitHub](https://github.com/ripple/rippled/releases/tag/0.32.0). + +## Actions Required ## + +1. If you operate a `rippled` server, you should upgrade to version 0.32.0 for the best performance. +2. If you have backend software which constructs and submits transactions to the Ripple network, you may need to adapt it to correctly use the network’s new transaction queue mechanism. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.32.0, your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. + +For instruction on updating rippled on supported platforms, please see [Updating `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled) in the Ripple Developer Center. + +The md5sum for the rpm is: **1b37fd80fd869e42a715f17a9e30c81a**. +The md5sum for the source rpm is: **d43f4d371416b213d6197fb1c630cf44**. + +For other platforms, please compile version 0.32.0 from source. See [`rippled` Build Instructions](https://github.com/ripple/rippled/tree/master/Builds) for details. + +The first log entry should be the change setting the version: + + commit d22eb0caa25ecfbd373cc9af0347e56031a23646 + Author: seelabs + Date: Fri Jun 24 11:30:09 2016 -0400 + + Set version to 0.32.0 + +## Network Update ## +The Ripple operations team plans to deploy version 0.32.0 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Wednesday, 2016-06-29. The deployment is expected to complete within 4 hours. + +## Learn, ask questions, and discuss ## +Ripple supported documentation including detailed example API calls and web tools for API testing are located on the Ripple Developer Portal: + +### Other resources: ### + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: [support@ripple.com](mailto:support@ripple.com) +* XRP Chat: diff --git a/content/blog/2016/rippled-0.32.1.md b/content/blog/2016/rippled-0.32.1.md new file mode 100644 index 0000000000..a94fcef3b7 --- /dev/null +++ b/content/blog/2016/rippled-0.32.1.md @@ -0,0 +1,81 @@ +# rippled version 0.32.1 + +Ripple is proud to announce the release of `rippled` version 0.32.1, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. + +Highlights of this release include: + +* A new, optional WebSocket implementation based on [Beast](https://github.com/vinniefalco/Beast). See below for details. +* An improved version of the payment code, which we expect to be available via an [Amendment named "FlowV2"](https://ripple.com/build/amendments/#flowv2) on Wednesday, 2016-08-24. See below for details. + +## Actions Required + +1. If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. +2. If you have backend software which constructs and submits transactions to the Ripple network, you need to adapt it to correctly use the network’s new payment engine. + +## Impact of Not Upgrading +If you operate a rippled server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24, when FlowV2 is expected to become available via Amendment, then your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. Any rippled server operator running versions prior to 0.32.1, will also become amendment blocked. + +For supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: 5dcdcef01f3cfc452b0b503eaaeb07bb + +The md5sum for the source rpm is: 3180fca1e83001307346f85628823a9c + +For other platforms, please [compile version 0.32.1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 1ff972fbd3b82f0f7062f05f64f1abd5e274a7bc + Author: Nik Bougalis + Date: Fri Jul 29 12:52:26 2016 -0700 + + Set version to 0.32.1 + + +## Network Update +The Ripple operations team plans to deploy version 0.32.1 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Thursday, 2016-08-04. The deployment is expected to complete within 4 hours. The network will continue operating during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) + + +## Full Release Notes +The `rippled` 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients. + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + +**New and Updated Features** + +An improved version of the payment processing engine, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling. + +The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding. Once FlowV2 is enabled on the network then old servers without the FlowV2 amendment will lose sync more frequently because of these differences. + +**Beast WebSocket** + +A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for `rippled` administrators. To enable this new implementation, change the “protocol” field in `rippled.cfg` from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example: + + [port_ws_public] + port = 5006 + ip = 0.0.0.0 + protocol = wss2 + +The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to support@ripple.com. A future version of rippled will remove the old WebSocket implementation, and use only the new one. + +**Bug fixes** + +Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219) + +Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251) + +Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200) + +Remove incompatible OS X switches in Test.py (RIPD-1250) + +Autofilling a transaction fee (sign / submit) with the experimental `x-queue-okay` parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194) diff --git a/content/blog/2016/rippled-0.33.0-hf1.md b/content/blog/2016/rippled-0.33.0-hf1.md new file mode 100644 index 0000000000..51d6481cb7 --- /dev/null +++ b/content/blog/2016/rippled-0.33.0-hf1.md @@ -0,0 +1,44 @@ +# rippled version 0.33.0-hf1 + +Ripple has released `rippled` version 0.33.0-hf1, which fixes a JSON parsing issue in all `rippled` servers. Ripple recommends upgrading to 0.33.0-hf1 only if server operators are experiencing a `jsonInvalid` error response to client requests. There are no new or updated features in the 0.33.0-hf1 release. + +## Action Recommended + +**If you operate a `rippled` server and are experiencing a `jsonInvalid` error response to client requests, then you should upgrade to 0.33.0-hf1 immediately.** + +## Impact of Not Upgrading + +If you operate a `rippled` server and are experiencing a `jsonInvalid` error response to client requests, but don’t upgrade to version 0.33.0-hf1, then your server will continue to experience failing client requests. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: f181f1fc801e3387487d246f9a975517 + +The md5sum for the source rpm is: 7993f125ed05bfeeda4e091761021429 + +For other platforms, please [compile version 0.33.0-hf1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 98f878cf10a32e26021b6a6ed44990bccbbc92c2 + Author: Vinnie Falco + Date: Sat Oct 1 12:12:34 2016 -0400 + + Set version to 0.33.0-hf1 + +## Bug Fixes + +Fix a JSON parsing issue that can fail to parse valid JSON requests when the data received by the server is broken up into more than one contiguous buffer. [(#1863)](https://github.com/ripple/rippled/commit/69b47890e69cea46c403e6354742c3653f125c6f) + +## Network Update +The Ripple operations team has deployed version 0.33.0-hf1 to all client facing `rippled` servers under its operational control. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2016/rippled-0.33.0.md b/content/blog/2016/rippled-0.33.0.md new file mode 100644 index 0000000000..6c1861032e --- /dev/null +++ b/content/blog/2016/rippled-0.33.0.md @@ -0,0 +1,95 @@ +# rippled version 0.33.0 + +Ripple has released `rippled` version 0.33.0, which introduces several new enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.33.0 by Wednesday, 2016-10-20, for service continuity. + +Highlights of this release include: + +* An improved version of the payment code, which Ripple expects to be available via an [Amendment named "Flow"](https://ripple.com/build/amendments/#flow) on Wednesday, 2016-10-20. See below for details. +* Payment Channels that permit scalable, off-ledger checkpoints for high volume, low value payments flowing in a single direction, which Ripple expects to be activated via an [Amendment named “PayChan”](https://ripple.com/build/amendments/#paychan) on a future date TBA. See below for details. +* SHAMapV2 changes the hash tree structure that rippled uses to represent a ledger, which Ripple expects to be activated via an [Amendment named SHAMapV2](https://ripple.com/build/amendments/#shamapv2) on a future date TBA. See below for details. + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to version 0.33.0 by Wednesday, 2016-10-20, for service continuity.** + +## Impact of Not Upgrading + +The Flow amendment is expected to be activated on Wednesday, 2016-10-20. If you operate a rippled server but don't upgrade to version 0.33.0 by that time, then your server will become amendment blocked, which means that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments + +If the Flow amendment is vetoed or does not pass via majority vote, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: 5ad8fa43e9acf645a76d0a383eb5600a + +The md5sum for the source rpm is: 38fe8c022e2fe5086f71fb9623a18064 + +For other platforms, please [compile version 0.33.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit f05321d501002cd7b8e7fba3ef361834689b3c26 + Author: Nik Bougalis + Date: Thu Sep 29 09:25:46 2016 -0700 + + Set version to 0.33.0 + +## Network Update +The Ripple operations team plans to deploy version 0.33.0 to all rippled servers under its operational control, including private clusters, starting at 2:00 PM PDT on Thursday, 2016-09-29. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +The `rippled` 0.33.0 release includes: + +* The ["Flow"](https://ripple.com/build/amendments/#flow) amendment. Ripple expects this amendment to be on Wednesday, 2016-10-20. + +* XRP Payment Channels. Payment channels are a new structure in the ledger designed to support [Interledger Protocol](https://interledger.org/) trust lines as balances get substantial. Ripple expects to be activated via Amendment on a future date (TBA) with the name [“PayChan”](https://ripple.com/build/amendments/#paychan). + +* Changes to the hash tree structure, which `rippled` uses hash trees to represent a ledger. Ripple expects these changes expect to be available via Amendment on a future date (TBA) with the name [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + +**New and Updated Features** + +A fixed version of the new payment processing engine, which Ripple initially [announced on Friday, 2016-07-29](https://developers.ripple.com/blog/2016/rippled-0.32.1.html), is expected to be available via Amendment on Wednesday, 2016-10-20 with the name ["Flow"](https://ripple.com/build/amendments/#flow). The new payments code adds no new features, but improves efficiency and robustness in payment handling. + +Ripple will be introducing changes to the hash tree structure that rippled uses to represent a ledger. Ripple expects these changes to be activated via Amendment on a future date (TBA) with the name [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences. The activation of the SHAMapV2 amendment will require brief scheduled allowable downtime, while the changes to the hash tree structure are propagated by the network. Ripple will keep the community updated as we progress towards this date (TBA). + +In an effort to make RCL more scalable and to support [Interledger Protocol](https://interledger.org/) (ILP) trust lines as balances get more substantial, Ripple is introducing XRP Payment Channels, a new structure in the ledger, which we expect to be available via Amendment on a future date (TBA) with the name [“PayChan”](https://ripple.com/build/amendments/#paychan). + +XRP Payment Channels permit scalable, intermittent, off-ledger settlement of ILP trust lines for high volume, low value payments flowing in a single direction. For bidirectional channels, an XRP Payment Channel can be used in each direction. The recipient can claim any unpaid balance at any time. The owner can top off the channel as needed. The owner must wait out a delay to close the channel to give the recipient a chance to supply any claims. The total amount paid increases monotonically as newer claims are issued. + +The initial concept behind payment channels was discussed as [early as 2011](https://bitcointalk.org/index.php?topic=25786.0) and the first implementation was done by Mike Hearn [in bitcoinj](https://bitcoinj.github.io/working-with-micropayments). Recent work being done by [Lightning Network](https://en.bitcoin.it/wiki/Lightning_Network) has showcased examples of the many use cases for payment channels. The introduction of XRP Payment Channels allows for a more efficient integration between RCL and ILP to further support enterprise use cases for high volume, low value payments. + +* The account_info command can now return information about queued transactions - [RIPD-1205] +* Automatically-provided sequence numbers now consider the transaction queue - [RIPD-1206] +* The server_info and server_state commands now include the queue-related escalated fee factor in the load_factor field of the response - [RIPD-1207] +* A transaction with a high transaction cost can now cause transactions from the same sender queued in front of it to get into the open ledger if the transaction costs are high enough on average across all such transactions. - [RIPD-1246] +* Reorganization: Move LoadFeeTrack to app/tx and clean up functions - [RIPD-956] +* Reorganization: unit test source files - [RIPD-1132] +* Reorganization: NuDB stand-alone repository - [RIPD-1163] +* Reorganization: Add BEAST_EXPECT to Beast - [RIPD-1243] +* Reorganization: Beast 64-bit CMake/Bjam target on Windows - [RIPD-1262] + +**Bug Fixes** + +Correct an issue with PaymentSandbox::balanceHook that can return the wrong issuer, which could cause the transfer fee to be incorrectly by-passed in rare circumstances. [(#1827)](https://github.com/ripple/rippled/commit/cf8b6be494c3537f3d6eeeb0a23d5454402688b1) + +Correct an issue with the new websocket implementation, which could cause concurrent writes on a single websocket connection. This could result in sporadic crashes when the server was under high load. [(#1806)](https://github.com/ripple/rippled/commit/e8a7ad47487aba3490bb63359ff17cfe584cd58c) + +Add HTTP status page for new websocket implementation. [(#1855)](https://github.com/ripple/rippled/commit/b2499c8fa015ac0121b81dcf8f1a92d9e1fd6a4b) diff --git a/content/blog/2016/rippled-0.40.0.md b/content/blog/2016/rippled-0.40.0.md new file mode 100644 index 0000000000..3293ec9505 --- /dev/null +++ b/content/blog/2016/rippled-0.40.0.md @@ -0,0 +1,80 @@ +# rippled version 0.40.0 + +Ripple has released `rippled` version 0.40.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.40.0 by Tuesday, 2017-01-17, for service continuity. + +Highlights of this release include: + +* Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17. See below for details. + +## Action Required + +If you operate a `rippled` server, then you should upgrade to version 0.40.0 by Tuesday, 2017-01-17, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.40.0 by Wednesday, 2017-01-17, when SusPay is expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the SusPay amendment is vetoed or does not pass via majority vote, then your server will not become amendment blocked. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: 27d0d142f29bcde7d240d91d44b5d7dc + +The md5sum for the source rpm is: b3b5ab6897f3c08b492f383ef7763c21 + +For other platforms, please [compile version 0.40.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 7fc780dd70faef819eace27a12de35dd1363c069 + Author: Nik Bougalis + Date: Tue Dec 20 09:20:17 2016 -0800 + + Set version to 0.40.0 + +## Network Update +The Ripple operations team plans to deploy version 0.40.0 to a subset of rippled servers under its operational control configured with the new websocket implementation, starting at 2:00 PM PDT on Thursday, 2017-12-20. The network will continue operating during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +The `rippled` 0.40.0 release includes Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to lock XRP until a cryptographic condition is met or it expires. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17. + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + +**New and Updated Features** + +Previously, Ripple [announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) the introduction of Payment Channels during the release of rippled version 0.33.0, which permit scalable, off-ledger checkpoints of high volume, low value payments flowing in a single direction. This was the first step in a multi-phase effort to make RCL more scalable and to support [Interledger Protocol](https://interledger.org/interledger.pdf) (ILP). Ripple expects Payment Channels to be enabled via an [Amendment called PayChan](https://ripple.com/build/amendments/#paychan) on a future date to be determined. + +In the second phase towards making RCL more scalable and compatible with ILP, Ripple is introducing Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users to cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an [Amendment named “SusPay”](https://ripple.com/build/amendments/#suspay) on Tuesday, 2017-01-17. + +A Suspended Payment can be created, which deducts the funds from the sending account. It can then be either fulfilled or canceled. It can only be fulfilled if the fulfillment transaction makes it into a ledger with a CloseTime lower than the expiry date of the transaction. It can be canceled with a transaction that makes it into a ledger with a CloseTime greater than the expiry date of the transaction. + +In the third phase towards making RCL more scalable and compatible with ILP, Ripple plans to introduce additional library support for crypto-conditions, which are distributable event descriptions written in a standard format that describe how to recognize a fulfillment message without saying exactly what the fulfillment is. Fulfillments are cryptographically verifiable messages that prove an event occurred. If you transmit a fulfillment, then everyone who has the condition can agree that the condition has been met. Fulfillment requires the submission of a signature that matches the condition (message hash and public key). This format supports multiple algorithms, including different hash functions and cryptographic signing schemes. Crypto-conditions can be nested in multiple levels, with each level possibly having multiple signatures. + +Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that rippled uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). This will require brief scheduled allowable downtime while the changes to the hash tree structure are propagated by the network. We will keep the community updated as we progress towards this date (TBA). + +* Consensus refactor [(#1874)](https://github.com/ripple/rippled/pull/1874) + +**Bug Fixes** + +* Correct an issue in payment flow code that did not remove an unfunded offer [(#1860)](https://github.com/ripple/rippled/pull/1860) + +* Sign validator manifests with both ephemeral and master keys [(#1865)](https://github.com/ripple/rippled/pull/1865) + +* Correctly parse multi-buffer JSON messages [(#1862)](https://github.com/ripple/rippled/pull/1862) diff --git a/content/blog/2016/testnet-ledger-reset.md b/content/blog/2016/testnet-ledger-reset.md new file mode 100644 index 0000000000..fa65cd8aae --- /dev/null +++ b/content/blog/2016/testnet-ledger-reset.md @@ -0,0 +1,32 @@ +# Ripple Test Network Ledger Will Be Reset + +## Summary + +On 2016-09-02, Ripple will be resetting the [test network](https://xrpl.org/xrp-test-net-faucet.html) ledger and balances. This means that all test net order books will be deleted and all account balances will be depleted. + +This will have absolutely no effect on the live, production Ripple Consensus Ledger (RCL). + +## Action Required + +If you have projects built or scripts running on test net, then new order books will have to be created and new account balances will have to be topped up. + +## Background + +Ripple operates the test network to ensure new features and fixes operate as planned before rolling them out to the live network. As a matter of policy, we have always stated publicly that the test net will be be reset on a regular basis, however in practice the ledger and balances have never been reset. As the Ripple network continues to grow, we view this as necessary. + +## Schedule + +Moving forward, we will likely be resetting the test net ledger and balances on or around the first of every month. + +We hope that this new planned schedule will also help the community plan their development projects and tests accordingly, although the test net may also be reset from time to time without notice. + +## Learn, Ask Questions, and Discuss + +Please refer to the Test Net page for information on generating new test net credentials and connecting to test net servers: + +### Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: +* XRP Chat: diff --git a/content/blog/2016/trustsetauth-available.md b/content/blog/2016/trustsetauth-available.md new file mode 100644 index 0000000000..0dec356b2b --- /dev/null +++ b/content/blog/2016/trustsetauth-available.md @@ -0,0 +1,29 @@ +# TrustSetAuth is Now Available + +As [predicted previously](https://developers.ripple.com/blog/2016/trustsetauth-reminder.html), TrustSetAuth became available on the Ripple Consensus Ledger this afternoon (PDT) in ledger 22,721,281 ([2016-07-19T15:10](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF)). + +This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts. + +## Action Required + +To remain operational, all `rippled` instances running on a version earlier than 0.31.0 must be [upgraded](https://ripple.com/build/rippled-setup/#updating-rippled) to `rippled` server **[version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html)** immediately. + +See [Updating `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled) for more information about upgrading `rippled`. + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version earlier than 0.31.0 but do not upgrade to version 0.32.0 immediately, then your server will not be able to synchronize with the rest of the upgraded network. + +## Why is the TrustSetAuth Amendment Important? + +With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the counterparty to take action. Without the amendment enabled, currency issuers cannot authorize other addresses to hold their issued currencies unless the currency holder first creates an accounting relationship with the currency issuer and sets a limit with a TrustSet transaction. + +## Learn More + +For more information, please see the TrustSetAuth documentation in the [Ripple Developer Portal](https://ripple.com/build/): + +* [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts) + +* [Amendments](https://ripple.com/build/amendments/#trustsetauth) + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server diff --git a/content/blog/2016/trustsetauth-reminder.md b/content/blog/2016/trustsetauth-reminder.md new file mode 100644 index 0000000000..afb7fd48d3 --- /dev/null +++ b/content/blog/2016/trustsetauth-reminder.md @@ -0,0 +1,26 @@ +TrustSetAuth Will Soon Be Available +=================================== + +This notice is for all validator operators, and may be useful for gateways that utilize the Authorized Accounts feature. + +A majority of trusted validators voted to enable the TrustSetAuth amendment, which is scheduled to become active on the protocol on Tuesday, 2016-07-19. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts. + +With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a TrustSet transaction. + +## Action Required ## + +To remain operational, all `rippled` instances running on the version below 0.31.0 must be upgraded to `rippled` server **[version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html)** by Tuesday, 2016-07-19. + +## Impact of Not Upgrading ## + +If you operate a `rippled` server on a version below 0.31.0 but do not upgrade to [version 0.32.0](https://developers.ripple.com/blog/2016/rippled-0.32.0.html) by Tuesday, 2016-07-19, then your server will not be able to synchronize with the rest of the upgraded network. + +## Learn More ## + +For more information, please see the documentation in the Ripple Developer Portal: + +* [Upgrading `rippled`](https://ripple.com/build/rippled-setup/#updating-rippled) +* [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts) +* [TrustSetAuth Amendment](https://ripple.com/build/amendments/#trustsetauth) + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: diff --git a/content/blog/2016/trustsetauth-voting.md b/content/blog/2016/trustsetauth-voting.md new file mode 100644 index 0000000000..b7dda5c854 --- /dev/null +++ b/content/blog/2016/trustsetauth-voting.md @@ -0,0 +1,16 @@ +# The TrustSetAuth Amendment Is Open For Voting # + +This notice is for all validator operators, and may be relevant to gateways that utilize the Authorized Account feature. + +The new [TrustSetAuth amendment](https://ripple.com/build/amendments/#trustsetauth) is open for voting now. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Accounts](https://ripple.com/build/gateway-guide/#authorized-accounts). With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a [TrustSet transaction](https://ripple.com/build/transactions/#trustset). + +Ripple's validators will vote in favor of the TrustSetAuth amendment, and we expect the new feature to become active by 2016-07-19. + +For more information, see the following articles in the Ripple Developer Center: + +* Authorized Accounts: +* Amendments: + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: + + diff --git a/content/blog/2017/data-api-load-balancing-test.md b/content/blog/2017/data-api-load-balancing-test.md new file mode 100644 index 0000000000..05a9f0ceac --- /dev/null +++ b/content/blog/2017/data-api-load-balancing-test.md @@ -0,0 +1,23 @@ +# Load Testing Data API + +The Ripple Data team will be running load balancing tests on Ripple Data API starting Wednesday, 2017-01-18, at 2pm PST, which will last approximately 15 minutes. The Ripple Data API is an open and free resource that provides access to information about changes in the Ripple Consensus Ledger, including transaction history and processed analytical data. + +## Action Recommended + +**If you operate software or services that rely on the Ripple Data API, then we recommend that you alert end users with the relevant information provided in this post.** + +## Impact of Tests + +If you operate software or services that rely on the Ripple Data API, then you may experience a brief outage and / or inconsistent data, including transaction history and processed analytical data, for a period of approximately 15 mins. + +For more information regarding the Ripple Data API, please see [Ripple Data API Documentation](https://ripple.com/build/data-api-v2/). + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/decent-strategy-update.md b/content/blog/2017/decent-strategy-update.md new file mode 100644 index 0000000000..feeb6142f7 --- /dev/null +++ b/content/blog/2017/decent-strategy-update.md @@ -0,0 +1,43 @@ +# Decentralization Strategy Update + +As Ripple progresses towards further decentralizing the XRP Ledger, we want to make server operators and members of the XRP Ledger community aware of a few upcoming changes to help ensure the reliability and stability of the network as it transitions to a distributed architecture with fully decentralized validators. + +## Background + +The XRP Ledger (formerly called the Ripple Consensus Ledger) was created in 2012, as a trust-based alternative to the proof-of-work consensus mechanism originated by Bitcoin. So far, most of that trust has relied upon validators owned and controlled by Ripple, the company leading development of the XRP Ledger. + +Ripple chose deliberately to be the most trusted validator operator in the network during the initial stages of development of the XRP Ledger. This decision involved trade-offs to prioritize security and scalability ahead of decentralization. + +Since inception, the XRP Ledger has closed over 33 million ledgers, processed over 600 million transactions amounting to more than $15 billion in transaction volume, with no major issues or network forks. + +At present, the XRP Ledger can natively scale to 1,500 transactions per second. With Payment Channels, XRP can theoretically scale to tens of thousands of transactions per second—throughput levels comparable to VISA. + +With the security, stability, and throughput of the XRP Ledger thoroughly proven, Ripple feels that now is the time for a crucial next step in decentralization, while continuing to improve all aspects of the XRP Ledger software. + +## Strategy + +To meet the growing needs of customers, and further increase resiliency and stability of the XRP Ledger, Ripple is in a great position to fully execute on its [decentralization strategy](https://ripple.com/insights/how-we-are-further-decentralizing-the-ripple-consensus-ledger-rcl-to-bolster-robustness-for-enterprise-use/), which has been an ongoing process since 2012. + +Phase one includes the diversification of validators by identity, location, hardware and software, in an effort to further mitigate the risk of a single point of failure. At the time of the announcement, 25 validator nodes were running with 5 trusted validators owned and managed by Ripple. Currently, [over 70 validator nodes](https://xrpcharts.ripple.com/#/validators) are running globally. During this phase Ripple will be adding 16 more trusted validators, in preparation for phase two. + +During the second phase, for every two of the most reliable, reputable, stable, secure and attested validators added to the recommended list of trusted nodes, one validator node currently controlled by Ripple will be removed, until no entity operates a majority of recommended trusted nodes on the XRP Ledger. + +The validator operators on this recommended list of trusted nodes believe in the long term vision of XRP and want to participate in the consensus process, which involves voting on proposed amendments, modifying fees and validating transactions. + +## Changes + +Before Ripple can progress to phase two, a few changes have to be made to ensure a safe transition. + +With the 0.80.0 release, Ripple will transition its recommended validator list to a new hosted site. This involves a change in the default `rippled` configuration file. The `[validators]` field with its static list of trusted validators will be replaced with `[validator_list_keys]` and `[validator_list_sites]` fields containing the key Ripple will use to sign its newly recommended validator list as well as the URLs where the dynamic list can be found. + +These changes will allow new validators to be safely added to the recommended validator list for phase two without requiring every `rippled` operator to manually update their configuration with each new addition. + +It is important to note that, for operators who already use the recommended validator list, no further trust in Ripple is required during phase 1, despite the significant increase of validators under Ripple’s operational control. The validator list currently recommended by Ripple contains 5 validators operated by Ripple, and at the end of phase 1, the list will contain 16 such validators. + +During phases 1 and 2, Ripple strongly recommends that operators use only the default Ripple-provided validator list. Consistent with this recommendation, the next scheduled release of `rippled`, version 0.81.0, will ship with a default configuration file using that list by default. + +During phase 2, Ripple will begin decommissioning one validator under its operational control for every two third-party validators that demonstrate a strong reputation for stability, security and reliability. Ripple will also be working with other entities to establish independent providers of validator lists. + +## Conclusion + +Ripple remains committed to decentralizing the XRP Ledger and divesting itself of operational control. This multi-phase approach does that, but is intentionally conservative and has been devised with a single goal in mind: to ensure the reliability and stability of the network during the transition period to a fully decentralized and distributed architecture. diff --git a/content/blog/2017/escrow-paychan-fix1368-reminder.md b/content/blog/2017/escrow-paychan-fix1368-reminder.md new file mode 100644 index 0000000000..a6da98d690 --- /dev/null +++ b/content/blog/2017/escrow-paychan-fix1368-reminder.md @@ -0,0 +1,38 @@ +# Escrow, PayChan, and fix1368 Will Be Available in 3 Days + +A majority of `rippled` validators voted to enable the [Escrow](https://ripple.com/build/amendments/#escrow), [PayChan](https://ripple.com/build/amendments/#paychan), and [fix1368](https://ripple.com/build/amendments/#fix1368) Amendments, which are scheduled to become enabled on the network on Thursday, 2017-03-30. + +* **Escrow** (previously called SusPay), designed for low volume, high value transactions, permits users to cryptographically escrow XRP on RCL with an expiration date using a [hashlock crypto-condition](https://interledgerjs.github.io/five-bells-condition/jsdoc/). + +* **PayChan**, designed for high volume, low value transactions, flowing in a single direction. The scalability of these transactions is not limited by the Ripple Consensus ledger, and they do not incur the risks typically associated with delayed settlement. + +* **fix1368** fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. + + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.60.0 by Thursday, 2017-03-30, when **Escrow, PayChan & fix1368** are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **Escrow, PayChan & fix1368** amendments do not get approved, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/explanation-of-ripples-xrp-escrow.md b/content/blog/2017/explanation-of-ripples-xrp-escrow.md new file mode 100644 index 0000000000..cd7d354e70 --- /dev/null +++ b/content/blog/2017/explanation-of-ripples-xrp-escrow.md @@ -0,0 +1,25 @@ +# An Explanation of Ripple’s XRP Escrow + +To provide additional predictability to the XRP supply, Ripple has locked 55 billion XRP (55% of the total possible supply) into a series of escrows. These escrows are on the ledger itself and the ledger mechanics, enforced by consensus, control the release of the XRP. + +The escrow consists of independent on ledger escrows that release a total of one billion XRP each month over the next 55 months. This provides an upper limit on the amount of new XRP that can be brought into circulation. The amount of XRP actually released into circulation will likely be much less than this. Any additional XRP leftover each month will be placed into a new escrow to release in the first month in which no escrow currently releases. + +During the process of moving Ripple’s XRP into escrow, we also changed our account security model. The XRP Ledger supports a native multisign scheme and Ripple secured the accounts the escrows release into using this scheme. + +The multisignature scheme has numerous advantages over the schemes other ledgers use. For example, the signers or quorum can be changed without changing the receiving address. Individual signers can rotate their own credentials without disturbing the funds on the ledger. + +## Ledger Mechanics + +The XRP Ledger’s escrow system is designed to handle two use cases. The one that gives it its name is its ability to lock funds on the ledger subject to release to one of two accounts depending on whether a particular condition occurs by a particular time. This supports Interledger transactions or cross-ledger atomic swaps. + +The escrow system consists of three types of transactions and one type of ledger entry. Escrows are created with an “EscrowCreate” transaction. This creates the “Escrow” ledger entry. An escrow can then be either cancelled or finished with an “EscrowCancel” or an “EscrowFinish” transaction. + +If an escrow is successfully finished, it delivers the XRP held to its destination account. If the escrow is cancelled, it delivers the XRP back to the source account. A ledger can have a date before which it cannot be cancelled, a date before which it cannot be finished, and a condition which must be satisfied to permit it to be finished. + +An escrow as a time lock several different ways, but the simplest one is to create an escrow that cannot be cancelled, cannot be finished before a particular date, and requires no additional condition to finish. For simplicity, the destination account can be set to be identical to the source account. + +On the ledger, an “Escrow” entry has a source account, a destination account, and an XRP amount. It is considered owned by the account that created it and increases the required XRP reserve for that account until it is completed or cancelled. Escrow entries can optionally have a cryptocondition that must be satisfied to finish the escrow, a date before which it cannot be cancelled, and a date before which it cannot be completed. + +Escrows can also have source and destination tags. Source and destination tags on the XRP Ledger provide a uniform and reliable way to support hosted accounts where an agent (such as an exchange) performs a transaction on behalf of its customer. The destination tag informs the recipient of which customer to credit. The source tag permits a payment to be refunded and the refund to be credited to the proper customer. This permits exchanges (or hosted wallet providers) to perform and receive escrowed payments on behalf of their customers. + +While the escrow is currently being used to provide more predictability to the XRP supply, Ripple expects that escrow will increasingly be used for higher-value, on-ledger and cross-ledger atomic payments using the Interledger Protocol. The XRP Ledger also provides payment channels for lower-value, off-ledger payments and micropayments. diff --git a/content/blog/2017/high-scalability-xrp-ledger.md b/content/blog/2017/high-scalability-xrp-ledger.md new file mode 100644 index 0000000000..1f193871c6 --- /dev/null +++ b/content/blog/2017/high-scalability-xrp-ledger.md @@ -0,0 +1,11 @@ +# The Most (Demonstrably) Scalable Blockchain + +Blockchain technology is set to fundamentally transform the way the world moves value, but to do so, it must first meet a number of challenges. + +In previous posts on this blog, we have highlighted our engineering practices and how they help us built robust and secure software—an important consideration for these new systems. + +The ability to handle volume is equally important, and today, we are sharing some more details about that aspect of our process. In [a feature article about the XRP Ledger on High Scalability](http://highscalability.com/blog/2017/10/2/ripple-the-most-demonstrably-scalable-blockchain.html)—the premiere news source about scalable, high performance Internet applications—we are proud to talk about our development and benchmarking practices and to discuss the data-driven changes we made to increase transaction throughput by a factor of 10 since we began performance testing. + +The XRP Ledger has been designed from the ground up with scalability in mind and the underlying architecture has only been improved over time. As our data shows, the XRP Ledger is now capable of sustaining a throughput of **1,500 transactions per second** on commodity hardware. + +We hope that this will be the first article in a series highlighting our continued efforts to scale the performance of the XRP Ledger to meet not only the demands of the present, but of the future as we help the Internet of Value take shape. diff --git a/content/blog/2017/invariant-checking.md b/content/blog/2017/invariant-checking.md new file mode 100644 index 0000000000..42930a5c7f --- /dev/null +++ b/content/blog/2017/invariant-checking.md @@ -0,0 +1,26 @@ +# Protecting the Ledger: Invariant Checking + +_By Nik Bougalis, Engineering Manager_ + +At Ripple, we have been developing next-generation financial infrastructure with an eye towards making value move as fast and as efficiently as information does today. + +But we are also keenly aware of the need for value to also move securely and reliably, so we place heavy emphasis on writing solid, secure and robust code. Our singular focus on code quality is the reason that the Ripple network experienced no service outages through 2016 or, so far, in 2017. + +With the release of rippled 0.70.0, and as part of our long-standing and enduring commitment to a reliable and error-free XRP Ledger, we are going further than before. We are adding code that runs automatically and in real time after each transaction completes, and examines the changes it made for correctness before the results are committed to the ledger. + +This is the idea behind the [recently activated](https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6) [EnforceInvariants amendment](https://ripple.com/build/amendments/#enforceinvariants), which will make it possible to verify that key properties of the system are not violated. The new checks—which we believe will never trigger—help protect the integrity of the XRP Ledger from bugs yet to be discovered, or even created. + +What’s more, the process is transparent and public: problematic transactions are marked with a **tecINVARIANT_FAILED** result code and are included in the ledger. This broad exposure, coupled with Ripple’s powerful ability to step through the execution of past transactions, makes it possible to quickly identify and fix any logic flaws in the code. + +One key property of the invariant checking functions is that they are simple: each check only does one thing and is easy to read and understand. This means that it is trivial to verify the correctness of the implementation by inspection—an important consideration in any security critical code. + +Our existing software development and quality assurance process places heavy emphasis on correctness and security. Over the past five years, we've honed this process to cover the entire software development lifecycle. Some of the systems we've put in place include: + +- Extensive unit tests, with tests as a requirement to merge any new code +- Regular use of tools to objectively assess the quality of the codebase +- A rigorous and public review process by Ripple’s world-class team of developers and third-party contributors +- Regular security audits by subject matter experts from the crypto, fintech and C++ communities. + +The new invariant checking sits atop and enhances our existing process by extending real-time protection to the XRP Ledger to help ensure its long-term health and security. + +As we continue to improve the XRP Ledger by adding new features and by further improving performance, we will also work to refine our process to help ensure that the financial infrastructure of the future will not only be fast, but also robust and secure. diff --git a/content/blog/2017/response-to-china-cert-report.md b/content/blog/2017/response-to-china-cert-report.md new file mode 100644 index 0000000000..387ef3af62 --- /dev/null +++ b/content/blog/2017/response-to-china-cert-report.md @@ -0,0 +1,17 @@ +# Response to China CERT Report + +As a leader in open-source, distributed financial technology, Ripple recognizes the importance of security researchers and we always encourage responsible disclosure of potential security vulnerabilities via our [bug bounty program](https://ripple.com/bug-bounty/). Ripple also employs regular external security audits and, as a matter of practice, the maintainers of the Ripple Consensus Ledger (RCL) technology (`rippled`) routinely use static and dynamic analysis tools on the C++ codebase (most recently version 0.50.0-b1). + +The results of the last internal static analyzer run determined that the defect rate of rippled was below the threshold that is typical for open source projects. To date, there have been no critical vulnerabilities discovered through static and dynamic analysis of the rippled C++ codebase, and the issues that have been found have been false-positives. In addition to using automated scanning tools, manual reviews of the code by multiple engineers have failed to identify a single vulnerability and the minor issues that have been discovered have long been fixed. + +Further, a recent independent security audit conducted by the NCC Group, a global security risk mitigation firm, revealed no serious security vulnerabilities, and found rippled “to be well-written and designed” before adding that it was clear that Ripple “has taken time to carefully consider the implementation.” + +In a recent [blockchain security report](http://if.cert.org.cn/res/web_file/bug_analyze_report.pdf) _(dead link)_, China CERT claimed that software related to Ripple’s open-sourced, distributed ledger technology has “230 high-risk security vulnerabilities.” Unfortunately, since the researchers behind the report did not demonstrate responsible disclosure by contacting Ripple prior to publication, we do not know what testing methodology or techniques were used nor which code repositories were tested. As a result, we were forced to investigate the claims being made after the fact, with no guidance from the security researchers and very little context. + +From what we can determine, the methodology appears to have been strictly limited to automated analysis tools run over a mixture of both security critical code and code that has no security implications whatsoever. The quantitative results were determined by the number of possible vulnerabilities identified by the tool and the possible severity of actual vulnerabilities in that class. (for example, any code that might have a buffer overflow would be identified as high risk, because if there actually is a buffer overflow issue and the code is actually security relevant, that could cause a significant compromise). + +Automated analysis tools typically have extremely high false positive rates of about 99%. When projects that already use this same methodology are tested in this way, the false positive rate nears 100% since all actual vulnerabilities that could be found in this way already have been found. + +Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report. Furthermore, based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either. + +We will continue to promptly and vigorously investigate all reports of security vulnerabilities, and urge anyone who thinks they have identified such a vulnerability to responsibly disclose it to us via our [bug bounty program](https://ripple.com/bug-bounty/). diff --git a/content/blog/2017/ripple-consensus-ledger-can-sustain-1000-transactions-per-second.md b/content/blog/2017/ripple-consensus-ledger-can-sustain-1000-transactions-per-second.md new file mode 100644 index 0000000000..486d8ba248 --- /dev/null +++ b/content/blog/2017/ripple-consensus-ledger-can-sustain-1000-transactions-per-second.md @@ -0,0 +1,15 @@ +# Ripple Consensus Ledger Can Sustain 1000 Transactions per Second + +2016 was an [important year for Ripple](https://ripple.com/insights/ripple-2016-year-review/). Banks were added to our [growing network](http://www.ibtimes.co.uk/seven-banks-kick-off-ripples-blockchain-network-including-santander-ubs-unicredit-90-more-1566894), we completed a successful [Series B investment round](https://ripple.com/insights/ripple-raises-55-million-in-series-b-funding/) and formed the [Global Payments Steering Group](https://ripple.com/insights/announcing-ripples-global-payments-steering-group/). Underlying all those milestones was the Ripple Consensus Ledger (RCL), which runs 24 hours a day, 7 days a week and recently celebrated its 4th birthday on February 17, 2017. In 2016 alone, RCL closed over 8 million ledgers, processing more than 225 million transactions and handling more than $1 Billion dollars in payment volume throughout the year. + +Today, for the first time, Ripple is proud to publicly announce that in recent internal benchmark testing, across 16 geographically distributed validators, the RCL is able to sustain nearly 1000 transactions per second. + +For even higher throughput transactions, we recently introduced [XRP payment channels](https://developers.ripple.com/blog/2016/rippled-0.33.0.html), which allow for zero-latency XRP payments. Although payment channels achieve practically infinite scalability by decoupling payment from settlement, they do so without incurring the risk typically associated with delayed settlement. + +Throughout 2016, the network received upgrades that seamlessly enabled new functionality and significantly improved performance. Fast ledger close times have been the hallmark of RCL since its inception and those were further improved last year. Ledgers now close, on average, every 3.5 seconds - a full 20% faster than they did a year ago. + +The new [fee escalation code ](https://ripple.com/build/transaction-cost/)was introduced to constantly monitor network load and adjust (in near real-time) the cost of executing transactions, which makes it more difficult to overload the network and further helps to ensure the long-term health and stability of RCL. + +Stability, however, goes beyond improving performance and adding new features. At Ripple we place heavy emphasis on writing code that is secure, solid and robust. This singular focus on code quality has helped the Ripple network achieve availability and reliability well beyond industry standards with no outages. + +With 2017 now well under way, we remain hard at work, focused on adding exciting new features to the RCL and further improving the performance, stability and quality of the [rippled](https://github.com/ripple/rippled) open source codebase. Most importantly, we remain more committed than ever to the simple goal of making XRP the world’s reserve digital currency. diff --git a/content/blog/2017/rippled-0.40.1.md b/content/blog/2017/rippled-0.40.1.md new file mode 100644 index 0000000000..b1cc49af7f --- /dev/null +++ b/content/blog/2017/rippled-0.40.1.md @@ -0,0 +1,44 @@ +# rippled version 0.40.1 + +The `rippled` team has released version 0.40.1, which increases SQLite database limits in all `rippled` full-history servers. Ripple recommends upgrading to 0.40.1 only if server operators are running `rippled` servers with full-history of the ledger. There are no new or updated features in the 0.40.1 release. + +## Action Recommended + +**If you operate a `rippled` server and have full-history of the ledger, then you should upgrade to 0.40.1 immediately.** + +## Impact of Not Upgrading + +If you operate a `rippled` server and have full-history of the ledger, but don’t upgrade to version 0.40.1, then your server may crash when restarted. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: e876816f4ddb38bec28d158083020fa9 + +The md5sum for the source rpm is: 3ed1569bd0dbba5ff1d1ef1abfca7ed7 + +For other platforms, please [compile version 0.40.1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + $ git log -1 upstream/master + commit e91aacc9a3d2f332a93981270c3812e26189226e + Author: Nik Bougalis + Date: Thu Jan 5 09:38:28 2017 -0800 + + Set version to 0.40.1 + +## Bug Fixes +Increase SQLite database limits to prevent full-history servers from crashing when restarting. [(#1961)](https://github.com/ripple/rippled/commit/610e51a162a6ef06accf8733b3b35b492963a78b) + +## Network Update +The Ripple operations team has deployed version 0.40.1 to all full-history `rippled` servers under its operational control. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.50.0.md b/content/blog/2017/rippled-0.50.0.md new file mode 100644 index 0000000000..aff59ff670 --- /dev/null +++ b/content/blog/2017/rippled-0.50.0.md @@ -0,0 +1,138 @@ +# rippled version 0.50.0 + +Ripple has released `rippled` version 0.50.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL). Ripple recommends that all server operators upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity. + +Highlights of this release include: + +* **TickSize**, which allows gateways to set a "tick size" for assets they issue to help promote faster price discovery and deeper liquidity, as well as reduce transaction spam and ledger churn on RCL. Ripple expects **TickSize** to be enabled via an [Amendment named “TickSize”](https://ripple.com/build/amendments/#ticksize) on Tuesday, 2017-02-21. See below for details. + +## Action Required + +**1. If you operate a `rippled` server, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity.** + +**2. If you are a gateway issuer, then please review forthcoming documentation for the TickSize amendment to determine what tick size is appropriate for your issuing asset.** + +**3. If you are a market maker and have algorithmic trading bots, then please review forthcoming documentation for the TickSize amendment to update your trading system to check the tick size for a given issuer.** + +**4. If you have backend software which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review forthcoming documentation for the TickSize amendment to adapt it for correct usage.** + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.50.0 by Tuesday, 2017-02-21, when **TickSize** is expected to be activated via Amendment, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **TickSize** amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: 82eb29f7e464e44eb24e3c891a021041 + +The md5sum for the source rpm is: 7bf25c86f018daf82c5d5f8ab621153a + +For other platforms, please [compile version 0.50.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 77999579b535373872d8cce7ddc8b12cdcc39d84 + Author: Nik Bougalis + Date: Thu Jan 26 13:26:03 2017 -0800 + + Set version to 0.50.0 + +## Network Update +The Ripple operations team plans to deploy version 0.50.0 to all `rippled` servers under its operational control, including private clusters, starting at 11:00 AM PDT on Friday, 2017-01-27. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +The `rippled` 0.50.0 release includes **TickSize**, which allows gateways to set a "tick size" for assets they issue to to help promote faster price discovery and deeper liquidity, as well as reduce transaction spam and ledger churn on RCL. Ripple expects TickSize to be enabled via an Amendment called **TickSize** on Tuesday, 2017-02-21. This feature underlines Ripple’s continued support to improving RCL and making it even better suited for settlement of global payments. + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + +**New and Updated Features** + +**Problem & Solution** + +Currently, offers on RCL can differ by as little as one part in a quadrillion. This means that there is essentially no value to placing an offer early, as an offer placed later at a microscopically better price gets priority over it. The **TickSize** Amendment solves this problem by introducing a minimum tick size that a price must move for an offer to be considered to be at a better price. The tick size is controlled by the issuers of the assets involved. + +When you place a buy offer, the amount of currency you will buy is respected. When you place a sell offer, the amount of currency you will sell is respected. If a tick size is in force, the other side of the offer will be rounded (in your favor) such that the ratio is rounded to the tick size before the offer is placed on the books. + +**TickSize** does not affect the size of an offer. A trader can still trade microscopic amounts of an asset. It just affects the prices (ratio of in to out) at which offers can be placed on the books. For asset pairs with XRP, the tick size imposed, if any, is the tick size of the issuer of the non-XRP asset. For asset pairs without XRP, the tick size imposed, if any, is the smaller of the two issuer's configured tick sizes. + +The tick size is imposed by rounding the offer quality down to the nearest tick and recomputing the non-critical side of the offer. For a buy, the amount offered is rounded down. For a sell, the amount charged is rounded up. + +**Effects of TickSize Change** + +This change lets issuers quantize the exchange rates of offers to use a specified number of significant digits. Gateways must enable a TickSize on their account for this feature to benefit them. A single AccountSet transaction may set a "TickSize" parameter. Legal values are 0 and 3-15 inclusive. Zero removes the setting. 3-15 allow that many decimal digits of precision in the pricing of offers for assets issued by this account. It will still be possible to place an offer to buy or sell any amount of an asset and the offer will still keep that amount as exactly as it does now. If an offer involves two assets that each have a tick size, the smaller number of significant figures (larger ticks) controls. + +**Benefits of TickSize Change** + +The primary expected benefits of the TickSize amendment is the reduction of bots fighting over the tip of the order book, which means: + +* Quicker price discovery +* Traders can't be outbid by a microscopic amount +* More offers left on the books +* A reduction in offer creation and cancellation spam + +We also expect larger tick sizes to benefit market makers in the following ways: + +* They increase the delta between the fair market value and the trade price, ultimately reducing spreads +* They prevent market makers from consuming each other's offers due to slight changes in perceived fair market value, which promotes liquidity +* They promote faster price discovery since traders have to adjust their prices in financially distinct increments +* They reduce transaction spam by reducing fighting over the tip of the order book and reducing the need to change offers due to slight price changes +* They reduce ledger churn and metadata sizes by reducing the number of indexes each order book must have +* They allow the order book as presented to traders to better reflect the actual book since these presentations are inevitably aggregated into ticks + +**Hardened TLS configuration** + +This release updates the default TLS configuration for `rippled`. The new release supports only 2048-bit DH parameters and defines a new default set of modern ciphers to use, removing support for ciphers and hash functions that are no longer considered secure. + +Server administrators who wish to have different settings can configure custom global and per-port cipher suites in the configuration file using the ssl_ciphers directive. + +## 0.50.0 Change Log + +* Remove websocketpp support [(#1910)](https://github.com/ripple/rippled/pull/1910) +* Increase OpenSSL requirements & harden default TLS cipher suites [(#1913)](https://github.com/ripple/rippled/pull/1913) +* Move test support sources out of ripple directory [(#1916)](https://github.com/ripple/rippled/pull/1916) +* Enhance ledger header RPC commands [(#1918)](https://github.com/ripple/rippled/pull/1918) +* Add support for tick sizes [(#1922)](https://github.com/ripple/rippled/pull/1922) +* Port discrepancy-test.coffee to c++ [(#1930)](https://github.com/ripple/rippled/pull/1930) +* Remove redundant call to clearNeedNetworkLedger [(#1931)](https://github.com/ripple/rippled/pull/1931) +* Port freeze-test.coffee to C++ unit test. [(#1934)](https://github.com/ripple/rippled/pull/1934) +* Fix CMake docs target to work if BOOST_ROOT is not set [(#1937)](https://github.com/ripple/rippled/pull/1937) +* Improve setup for account_tx paging test [(#1942)](https://github.com/ripple/rippled/pull/1942) +* Eliminate npm tests [(#1943)](https://github.com/ripple/rippled/pull/1943) +* Port uniport js test to cpp [(#1944)](https://github.com/ripple/rippled/pull/1944) +* Enable amendments in genesis ledger [(#1944)](https://github.com/ripple/rippled/pull/1944) +* Trim ledger data in Discrepancy_test [(#1948)](https://github.com/ripple/rippled/pull/1948) +* Add "current_ledger" field to "fee" result [(#1949)](https://github.com/ripple/rippled/pull/1949) +* Cleanup unit test support code [(#1953)](https://github.com/ripple/rippled/pull/1953) +* Add ledger save / load tests [(#1955)](https://github.com/ripple/rippled/pull/1955) +* Remove unused websocket files [(#1957)](https://github.com/ripple/rippled/pull/1957) +* Update RPC handler role/usage [(#1966)](https://github.com/ripple/rippled/pull/1966) + +**Bug Fixes** + +* Validator's manifest not forwarded beyond directly connected peers [(#1919)](https://github.com/ripple/rippled/pull/1919) + +## Upcoming Features + +We expect the [previously](https://developers.ripple.com/blog/2016/rippled-0.40.0.html) announced Suspended Payments feature, which introduces new transaction types to the Ripple protocol that will permit users to cryptographically escrow XRP on RCL, to be enabled via the [“SusPay”](https://ripple.com/build/amendments/#suspay) Amendment on Tuesday, 2017-02-21. + +Also, we expect support for [crypto-conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), which are signature-like structures that can be used with suspended payments to support ILP integration, to be included in the next `rippled` release scheduled for March. + +Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA). diff --git a/content/blog/2017/rippled-0.50.2.md b/content/blog/2017/rippled-0.50.2.md new file mode 100644 index 0000000000..4792c860f2 --- /dev/null +++ b/content/blog/2017/rippled-0.50.2.md @@ -0,0 +1,47 @@ +# rippled version 0.50.2 + +The `rippled` team has released 0.50.2, which adjusts the default TLS cipher list and corrects a flaw that would not allow an SSL handshake to properly complete if the port was configured using the wss keyword. Ripple recommends upgrading to 0.50.2 only if server operators are running `rippled` servers that accept client connections over TLS. There are no new or updated features in the 0.50.2 release. + +## Action Recommended + +**If you operate a `rippled` server and accept secure client connections, then you should upgrade to 0.50.2 immediately.** + +## Impact of Not Upgrading + +If you operate a `rippled` server and accept secure client connections, but don’t upgrade to version 0.50.2, then your server may be unable to negotiate SSL connections. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The md5sum for the rpm is: 05cf675685158aabfc3ff6af7b1549d8 + +The md5sum for the source rpm is: 0a8c93d67e1c27726ee57693177e7745 + +For other platforms, please [compile version 0.50.2 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + +``` +commit d8a5f5b0946e2a155a1af8455512488a5f758955 +Author: Nik Bougalis +Date: Mon Jan 30 15:45:35 2017 -0800 + + Set version to 0.50.2 +``` + + +## Bug Fixes + +Adjust the default cipher list and correct a flaw that would not allow an SSL handshake to properly complete if the port was configured using the wss keyword. [(#1985)](https://github.com/ripple/rippled/pull/1985/commits/708fc6cd6f3c75d08fa409f6815ed915854438a5) + +## Network Update +The Ripple operations team has deployed a configuration-based fix to all client-facing `rippled` servers under its operational control and will not be updating to 0.50.2 at this time. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.50.3.md b/content/blog/2017/rippled-0.50.3.md new file mode 100644 index 0000000000..386d03b227 --- /dev/null +++ b/content/blog/2017/rippled-0.50.3.md @@ -0,0 +1,59 @@ +# rippled version 0.50.3 + +The `rippled` team has released version 0.50.3, which patches a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the `NoRipple` flag. Ripple recommends that all `rippled` server operators immediately upgrade to version 0.50.3, which contains a patch that fixes the exploit. There are no new or updated features in the 0.50.3 release. + +Ripple will be following up with a postmortem, explaining the exploit, the timeline of events and the actions taken in more detail at a later date. + +## Action Recommended + +**If you operate a `rippled` server**, then you should upgrade to version 0.50.3 immediately. + +**If you operate a gateway**, then you should: +1. Make sure your issuing account has not set the `NoRipple` flag on any trust lines +2. Your issuing account should have a zero limit on all trust lines +3. Make sure the `DefaultRipple` flag is set on your issuing account +4. Upgrade to `rippled` version 0.50.3 immediately + +**If you are an individual user**, then you should have the `NoRipple` flag enabled by default and set the trust line limit to zero on gateways that you do not trust. + +**If you are an individual user, and you do not have the `NoRipple` flag enabled**, and you discover a negative balance owed to an unknown account, then you should freeze that individual trust line. + +## Impact of Not Upgrading + +If you operate a `rippled` server, but don’t upgrade to `rippled` version 0.50.3, then your server may lose sync with Ripple operated validators more frequently. + +If you operate a `rippled` validating server, but don’t upgrade to `rippled` version 0.50.3, which includes a patch for the reported exploit, then your server will validate some transactions in a payment path that bypass the blocking effect of the `NoRipple` flag. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the rpm is: 2ee3e7e2912b5df9e3f8f88c5f6adfa60afbb37ef08afe50f6147795c5c2abaf + +The sha256 for the source rpm is: ada6f9ae8b8136569d28f03a43fef0f828e2c69857c81f230d17cf9f832cce0f + +For other platforms, please [compile version 0.50.3 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 82de944b30afef7fb6220424b62a79156e93b321 + Author: Nik Bougalis + Date: Mon Mar 13 15:49:21 2017 -0700 + + Set version to 0.50.3 + +## Bug Fixes + +Patch a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the `NoRipple` flag [(#2050)](https://github.com/ripple/rippled/pull/2050/commits/0b187a6a4eb503c91efca997aae32c4c9b45f115) + +## Network Update + +Ripple engineers have deployed the fix to all `rippled` validating servers under Ripple’s operational control and will not be updating client-facing `rippled` servers to 0.50.3 at this time. _(Editor's note: an earlier version of this post incorrectly stated that the fix was configuration-based. The fix was to update Ripple's validating servers to 0.50.3.)_ + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.60.0.md b/content/blog/2017/rippled-0.60.0.md new file mode 100644 index 0000000000..209d341283 --- /dev/null +++ b/content/blog/2017/rippled-0.60.0.md @@ -0,0 +1,124 @@ +# rippled Version 0.60.0 + +Ripple has released `rippled` version 0.60.0, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL), including [Interledger Protocol](https://interledger.org/overview.html) compatibility for ledger interoperability. Ripple recommends that all server operators upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity. + +Highlights of this release include: + +* **Escrow** (previously called SusPay), which permits users to cryptographically escrow XRP on RCL with an expiration date using a [hashlock crypto-condition](https://interledgerjs.github.io/five-bells-condition/jsdoc/). + +* **[Dynamic UNL Lite](https://github.com/ripple/rippled/pull/1842)**, which allows `rippled` to automatically adjust which validators it trusts based on recommended lists from trusted publishers. + +Ripple expects Escrow, the [previously announced **Payment Channels**](https://developers.ripple.com/blog/2016/rippled-0.33.0.html), and the new [**fix1368** amendment](#fix1368-amendment) to be enabled via Amendments called [Escrow](https://ripple.com/build/amendments/#escrow), [PayChan](https://ripple.com/build/amendments/#paychan), and `fix1368`, respectively, on Thursday, 2017-03-30. + + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.60.0 by Thursday, 2017-03-30, when Escrow and PayChan are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **Escrow** and **PayChan** amendments do not get approved, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the rpm is: 4d2acb2a40e2d18ba1737098efdca54caa823a403ce9562c83e2dd2c9e959588 + +The sha256 for the source rpm is: 3437a0202e762801869f31bf798417ebdb3717e16c4381dc0e9b02fe75d23024 + +For other platforms, please [compile version 0.60.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 0df1b09a731ba0feaa5d60046e1c7dd415f5f7ed + Author: Nik Bougalis + Date: Thu Mar 16 13:33:29 2017 -0700 + + Set version to 0.60.0 + +## Network Update +The Ripple operations team plans to deploy version 0.60.0 to all `rippled` servers under its operational control, including private clusters, starting at 7:00 PM PST on Thursday, 2017-03-16. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +### Escrow + +The rippled version 0.60.0 release includes Escrow, (previously called SusPay), which introduces a new ledger node type and several new transaction types to the Ripple network. Escrow permits users to cryptographically escrow XRP on RCL with an expiration date using a [crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02) called [preimage-sha-256](https://interledgerjs.github.io/five-bells-condition/jsdoc/#create-a-preimage-sha-256-condition-hashlock), commonly referred to as a hashlock. An XRP Escrow transaction on RCL can be used together with Interledger, to allow a payment to be routed without having to trust third-party intermediaries. We believe this will open a range of possibilities and use cases for XRP, particularly when sending high value, low volume payments cross-border. + +### Payment Channels + +The amendment for Payment Channels was originally introduced in version 0.33.0, but is now ready for Payment Channels to be enabled on the production Ripple Consensus Ledger. XRP [Payment Channels](https://ripple.com/build/amendments/#paychan) are intended for high volume, low value payments. They provide a method for scalable, intermittent, off-ledger settlement flowing in a single direction. For bidirectional payment channels, an XRP Payment Channel can be used in each direction. The recipient can claim any unpaid balance at any time before the channel closes. The owner can top off the channel as needed and must wait out a delay to close the channel to give the recipient a chance to supply any claims. The total amount paid increases monotonically as newer claims are issued. + +### Dynamic UNL Lite + +At the core of RCL is the [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/). Through the consensus process, validating nodes agree on a specific subset of the candidate transactions to be considered for the next ledger. Consensus is an iterative process in which nodes relay proposals, or sets of candidate transactions. Nodes communicate and update proposals until a supermajority of peers agree on the same set of candidate transactions. + +During consensus, each node evaluates proposals from a specific set of peers, called chosen validators. Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. This definition of “trust” does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network. + +The `rippled` version 0.60.0 release introduces new [Dynamic UNL](https://github.com/ripple/rippled/pull/1842) configuration options, which allow `rippled` to update its set of trusted validators without reconfiguring and restarting. Instead of specifying a static list of trusted validators in the config or validators file, you can configure a trusted publisher key and a URI where the publisher serves signed lists of validators. `rippled` will regularly query the configured URIs for the latest recommended list of validators from the trusted publishers. Configuring the validation quorum is no longer required, as `rippled` will automatically update its quorum based on its current trusted validator set. + +Dynamic UNL Lite is a progressive step towards fully automated dynamic UNLs, to which each client of the Ripple network determines its UNL through policies, rather than trusting a pre-provided list of validators. + +### fix1368 Amendment + +Version 0.60.0 also introduces the [fix1368 Amendment](https://github.com/ripple/rippled/pull/1936) to fix a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner. + +These features underline Ripple’s continued support to improving RCL by making it more stable, distributed and scalable for settlement of global payments. + +## Upcoming Features + +We do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA). + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + + +## 0.60.0 Change Log + +* Add Escrow support [(#2039)](https://github.com/ripple/rippled/pull/2039/commits/cfde591ac9deb683b9d1be8f8d4c7a14d9598507) +* Dynamize trusted validator list and quorum [(#1842)](https://github.com/ripple/rippled/pull/1842) +* Simplify fee handling during transaction submission [(#1992)](https://github.com/ripple/rippled/commit/8345475bc37a4d6bddf1e47dc06f22ef9396bbd8) +* Publish server stream when fee changes [(#2016)](https://github.com/ripple/rippled/pull/2016) +* Replace manifest with validator token [(#1975)](https://github.com/ripple/rippled/pull/1975) +* Add validator key revocations [(#2019)](https://github.com/ripple/rippled/pull/2019) +* Add SecretKey comparison operator [(#2004)](https://github.com/ripple/rippled/pull/2004/commits/a00e684bf2a088bb432b9f7c4c859ee98c730817) +* Reduce LEDGER_MIN_CONSENSUS [(#2013)](https://github.com/ripple/rippled/pull/2013) +* Update libsecp256k1 and Beast B30 [(#1983)](https://github.com/ripple/rippled/pull/1983) +* Make Config extensible via lambda [(#1993)](https://github.com/ripple/rippled/pull/1993) +* WebSocket permessage-deflate integration [(#1995)](https://github.com/ripple/rippled/pull/1995) +* Do not close socket on a foreign thread [(#2014)](https://github.com/ripple/rippled/pull/2014) +* Update build scripts to support latest boost and ubuntu distros [(#1997)](https://github.com/ripple/rippled/pull/1997) +* Handle protoc targets in scons ninja build [(#2022)](https://github.com/ripple/rippled/pull/2022) +* Specify syntax version for ripple.proto file [(#2007)](https://github.com/ripple/rippled/pull/2007) +* Eliminate protocol header dependency [(#1962)](https://github.com/ripple/rippled/pull/1962) +* Use gnu gold or clang lld linkers if available [(#2031)](https://github.com/ripple/rippled/pull/2031) +* Add tests for lookupLedger [(#1989)](https://github.com/ripple/rippled/pull/1989) +* Add unit test for get_counts RPC method [(#2011)](https://github.com/ripple/rippled/pull/2011) +* Add test for transaction_entry request [(#2017)](https://github.com/ripple/rippled/pull/2017) +* Unit tests of RPC "sign" [(#2010)](https://github.com/ripple/rippled/pull/2010) +* Add failure only unit test reporter [(#2018)](https://github.com/ripple/rippled/pull/2018) + +## Bug Fixes + +* Enforce rippling constraints during payments [(#2049)](https://github.com/ripple/rippled/pull/2049) +* Fix limiting step re-execute bug [(#1936)](https://github.com/ripple/rippled/pull/1936) +* Make "wss" work the same as "wss2" [(#2033)](https://github.com/ripple/rippled/pull/2033) +* Check for malformed public key on payment channel [(#2027)](https://github.com/ripple/rippled/pull/2027) +* Config test uses unique directories for each test [(#1984)](https://github.com/ripple/rippled/pull/1984) +* Send a websocket ping before timing out in server [(#2035)](https://github.com/ripple/rippled/pull/2035) diff --git a/content/blog/2017/rippled-0.60.1.md b/content/blog/2017/rippled-0.60.1.md new file mode 100644 index 0000000000..ab36d8c133 --- /dev/null +++ b/content/blog/2017/rippled-0.60.1.md @@ -0,0 +1,51 @@ +# rippled version 0.60.1 + +The `rippled` team has released `rippled` version 0.60.1, which corrects a technical flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values for Escrow and Payment Channel ledger entries. `rippled` version 0.60.1 also fixes a problem where the websocket timeout timer would not be cancelled when certain errors occurred during subscription streams. **Ripple strongly recommends upgrading to `rippled` version 0.60.1 immediately.** + +Ripple expects the [`Escrow`](https://ripple.com/build/amendments/#escrow) and [`PayChan`](https://ripple.com/build/amendments/#paychan) amendments to be enabled via [amendment vote](https://developers.ripple.com/blog/2017/escrow-paychan-fix1368-reminder.html) around 11:26 PM PDT on Thursday, 2017-03-30. There are no new features in the 0.60.1 release. + +## Action Required + +**If you operate a `rippled` server, then you must upgrade to 0.60.1 immediately.** + +## Impact of Not Upgrading + +* If you operate a `rippled` server, but do not upgrade to `rippled` version 0.60.1, then your `rippled` server will lose sync when processing Payment Channel or Escrow transactions. The `Escrow` and `PayChan` amendments are expected to be enabled via amendment vote around 11:26 PM PDT on Thursday, 2017-03-30. + +* If you operate a `rippled` server, but do not upgrade to version 0.60.1, then client websocket connections to your `rippled` server may continue to disconnect during subscription streams. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the RPM is: 6714050e9d1d232e8250be434fe6a61c44f78e41adc3c2b5f49df490ee5312ef + +The sha256 for the source RPM is: 5bba13e93fed160a3405315e4128e891b2bc1e439ee5f7b429294003c618f0e1 + +For other platforms, please [compile version 0.60.1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 0d4fe469c6b0ba47645b53930e74248ff789fe75 + Author: seelabs + Date: Wed Mar 29 15:41:43 2017 -0400 + + Set version to 0.60.1 + +## Bug Fixes + +Fix a flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values [(#2071)](https://github.com/ripple/rippled/pull/2071) + +Fix a problem where the WebSocket timeout timer would not be cancelled when certain errors occurred during subscription streams [(#2067)](https://github.com/ripple/rippled/pull/2067) + +## Network Update + +The Ripple technical operations team plans to deploy `rippled` version 0.60.1 to all `rippled` servers under its operational control, including private clusters, starting at 11:00 AM PDT on Thursday, 2017-03-30. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.60.2-2-rpm.md b/content/blog/2017/rippled-0.60.2-2-rpm.md new file mode 100644 index 0000000000..63db5e6c52 --- /dev/null +++ b/content/blog/2017/rippled-0.60.2-2-rpm.md @@ -0,0 +1,42 @@ +# rippled RPM version 0.60.2-2 + +Ripple has released a new `rippled` 0.60.2-2 RPM that contains an update to the [validator-keys](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#validator-keys) key generation and management tool. The latest version of validator-keys allows validator operators to [sign data with their validator key](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#signing). + +There are no changes to `rippled` with this version. + +## Action Required + +**If you operate a `rippled` validator server that was set up using validator-keys and would like to sign data with your validator key**, then you should update to the `rippled` 0.60.2-2 RPM. + +## Impact of Not Upgrading + +**If you operate a `rippled` validator server but you don’t update to the `rippled` 0.60.2-2 RPM**, then your `rippled` instance will continue to operate normally. + +**If you operate a `rippled` validator server that was set up using validator-keys but don’t update to the `rippled` 0.60.2-2 RPM**, then you will be unable to sign data using your validator key. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the RPM is: 74e2541c1c6c06bd34d102229890bb11811701d73d99e4cfb4882d430131c067 + +The sha256 for the source RPM is: aab7f247b5cf9d3a20d4720aef2c51532bb83ee91fafe584e4fdfac77171537b + +For other platforms, please [compile version 0.60.2-2 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 7cd4d7889779e6418270c8af89386194efbef24b + Author: seelabs + Date: Thu Mar 30 14:25:41 2017 -0400 + + Set version to 0.60.2 + + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.60.2.md b/content/blog/2017/rippled-0.60.2.md new file mode 100644 index 0000000000..55bae13251 --- /dev/null +++ b/content/blog/2017/rippled-0.60.2.md @@ -0,0 +1,56 @@ +# rippled version 0.60.2 + +The `rippled` team has released `rippled` version 0.60.2, which further strengthens handling of cases associated with a [previously patched exploit](https://developers.ripple.com/blog/2017/rippled-0.50.3.html), in which `NoRipple` flags were being bypassed by using offers. Ripple requires upgrading to `rippled` version 0.60.2 immediately. There are no new features in the 0.60.2 release. **Note**: This does not affect XRP transactions. + +Ripple will be following up with a postmortem, explaining the previosuly patched exploit, the timeline of events and the actions taken in more detail at a later date. + +## Action Required + +**If you operate a rippled server**, then you must upgrade to 0.60.2 immediately. + +**If you are an individual user**, then you should have the `NoRipple` flag enabled by default and set the trust line limit to zero on gateways that you do not trust. + +**If you are an individual user**, and you do not have the `NoRipple` flag enabled, and you discover a negative balance owed to an unknown account, then you should [freeze](https://ripple.com/build/freeze/#individual-freeze) that individual trust line. + + +## Impact of Not Upgrading + +**If you operate a rippled server**, but do not upgrade to `rippled` version 0.60.2, then your server may lose sync with Ripple operated validators more frequently. + +**If you operate a rippled validating server**, but do not upgrade to `rippled` version 0.60.2, which prevents `NoRipple` flags from being bypassed by using offers, then your server will validate some transactions in a payment path that bypass the blocking effect of the `NoRipple` flag using offers. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the RPM is: 3dc7412bda8986188164f0ff70ff80c351b17521e6943a876d5d3268fa07289d + +The sha256 for the source RPM is: f189ba1a8ae2201da47008ff50d027dcf719c7001c9b350b6759db279cbb48c8 + +For other platforms, please [compile version 0.60.2 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 7cd4d7889779e6418270c8af89386194efbef24b + Author: seelabs + Date: Thu Mar 30 14:25:41 2017 -0400 + + Set version to 0.60.2 + + +## Bug Fixes + +Prevent the ability to bypass `NoRipple` flags using offers [(#7cd4d78)](https://github.com/ripple/rippled/commit/4ff40d4954dfaa237c8b708c2126cb39566776da) + +## Network Update + +The Ripple technical operations team plans to deploy `rippled` version 0.60.2 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PDT on Thursday, 2017-03-30. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.60.3.md b/content/blog/2017/rippled-0.60.3.md new file mode 100644 index 0000000000..bb9d13476a --- /dev/null +++ b/content/blog/2017/rippled-0.60.3.md @@ -0,0 +1,46 @@ +# rippled version 0.60.3 + +The `rippled` team has released `rippled` version 0.60.3, which helps to increase the stability of the overlay network under increased load. Ripple recommends server operators upgrade to `rippled` version 0.60.3 immediately. There are no new features in the 0.60.3 release. + +## Action Recommended + +**If you operate a rippled server and are experiencing connection instability or your server has difficulty maintaining sync with the Ripple network during periods of increased load**, then you should upgrade to `rippled` version 0.60.3 immediately. + +## Impact of Not Upgrading + +**If you operate a rippled server**, but don’t upgrade to `rippled` version 0.60.3, then your server may experience dropped connections to other servers more frequently. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the RPM is: 3e9c8b421ea0ae6da7ae65524be60408f32ef2bd0bcfea1e1c9fb54eec5fc809 + +The sha256 for the source RPM is: 9848185e35a21ef41fcea334f8ad224c49e243f64b38dd9311ab898b97ab6c0a + +For other platforms, please [compile version 0.60.3 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 208028a1420cc187a6b5b9e97846e8cafd54f39f + Author: Nik Bougalis + Date: Tue May 9 13:37:49 2017 -0700 + + Set version to 0.60.3 + +## Change Log + +Server overlay improvements [(#2110)](https://github.com/ripple/rippled/pull/2110) + +## Network Update + +The Ripple technical operations team plans to deploy `rippled` version 0.60.3 to all `rippled` servers under its operational control, including private clusters and hubs, starting at 4:00 PM PDT on Thursday, 2017-05-11. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.70.0.md b/content/blog/2017/rippled-0.70.0.md new file mode 100644 index 0000000000..065e04c2da --- /dev/null +++ b/content/blog/2017/rippled-0.70.0.md @@ -0,0 +1,121 @@ +# rippled Version 0.70.0 + +Ripple has released `rippled` version 0.70.0, which introduces several enhancements that improve the reliability, scalability and security of the Ripple Consensus Ledger. Ripple recommends that all `rippled` server operators upgrade to version 0.70.0 by Thursday, 2017-06-29, for service continuity. + +Highlights of this release include: + +* The [**FlowCross** Amendment](https://ripple.com/build/amendments/#flowcross), which streamlines offer crossing and autobrigding logic by leveraging the new “Flow” payment engine in `rippled`. + +* The [**EnforceInvariants** Amendment](https://ripple.com/build/amendments/#enforceinvariants), which safeguards the integrity of RCL by introducing code that executes after every transaction and ensures that the execution did not violate key protocol rules. + +* [**fix1373**](https://ripple.com/build/amendments/#fix1373), which addresses an issue that would cause payments with certain path specifications to not be properly parsed. + +Ripple expects the **EnforceInvariants** and **fix1373** Amendments to be enabled on Thursday, 2017-06-29. The **FlowCross** Amendment will be enabled on a future date (TBA). + +## Operational Note + +The algorithm that determines how many threads `rippled` uses has been changed with this release. The new logic creates more threads, allowing the server to better leverage multi-core processing units. As a result of the increase in thread count, operators may find that their `rippled` instances may now utilize more memory than in the past. + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to version 0.70.0 by Thursday, 2017-06-29, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but do not upgrade to version 0.70.0 by Thursday, 2017-06-29, when **EnforceInvariants** and **fix1373** are expected to be activated via Amendment, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **EnforceInvariants** and **fix1373** Amendments do not get approved, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the rpm is: 5a617bce531f39c044de535b6bda2a59371829dfc1079b67876b68c9a9748834 + +The sha256 for the source rpm is: c51212ae374f69ddc10f967409a750834f06195cb384b2af04e4fa0c3fb81a24 + +For other platforms, please [compile version 0.70.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 7b0d48281049c3fec7fafcb7ce5cea045367ae1f + Author: Nik Bougalis + Date: Thu Jun 15 07:34:17 2017 -0700 + + Set version to 0.70.0 + +## Network Update +The Ripple operations team plans to deploy version 0.70.0 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PST on Thursday, 2017-06-15. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +At that time, `rippled` validators under Ripple’s operational control will begin voting for the **EnforceInvariants** and **fix1737** Amendments. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +### FlowCross + +Currently, the offer crossing code in `rippled` is independent of the payment flow code in `rippled`. The introduction of the **FlowCross** Amendment ensures that the same logic that drives payments also drives offer crossing. This change streamlines the code base, improves test coverage and is expected to result in some marginal performance benefits in offer crossing. For more information, see [FlowCross](https://ripple.com/build/amendments/#flowcross). + +### EnforceInvariants + +The introduction of the **EnforceInvariants** Amendment supplements existing safeguards of RCL integrity. Once the amendment activates, the servers will execute specialized code to check key system invariants after the execution of each transaction. If a transaction fails any of the checks, it will be considered as invalid. For more information, see [EnforceInvariants](https://ripple.com/build/amendments/#enforceinvariants). + +### fix1373 Amendment + +Version 0.70.0 also introduces the fix1373 Amendment to fix a minor bug in pathfinding that causes strand creation to fail. Specifically, the issue was related to paths that contain path elements where all the path elements types are set (account, currency and issuer). The fix1373 Amendment corrects the issue that caused some strand creation to fail. For more information, see [fix1373](https://ripple.com/build/amendments/#fix1373). + +These features underline Ripple’s continued support to improving RCL by making it more stable, secure and efficient for settlement of global payments. + +## Upcoming Features + +We do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA). + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + + +## 0.70.0 Change Log + +* Implement and test invariant checks for transactions [(#2054)](https://github.com/ripple/rippled/pull/2054) +* TxQ: Functionality to dump all queued transactions [(#2020)](https://github.com/ripple/rippled/pull/2020) +* Consensus refactor for simulation/cleanup [(#2040)](https://github.com/ripple/rippled/pull/2040) +* Payment flow() code should support offer crossing [(#1884)](https://github.com/ripple/rippled/pull/1884) +* Make Config init extensible via lambda [(#1993)](https://github.com/ripple/rippled/pull/1993) +* Improve Consensus Documentation [(#2064)](https://github.com/ripple/rippled/pull/2064) +* Refactor Dependencies & Unit Test Consensus [(#1941)](https://github.com/ripple/rippled/pull/1941) +* Feature RPC test [(#1988)](https://github.com/ripple/rippled/pull/1988) +* Add unit Tests for handlers/TxHistory.cpp [(#2062)](https://github.com/ripple/rippled/pull/2062) +* Add unit tests for handlers/AccountCurrenciesHandler.cpp [(#2085)](https://github.com/ripple/rippled/pull/2085) +* Add unit test for handlers/Peers.cpp [(#2060)](https://github.com/ripple/rippled/pull/2060) +* Improve logging for Transaction affects no accounts warning [(#2043)](https://github.com/ripple/rippled/pull/2043) +* Increase logging in PeerImpl fail [(#2043)](https://github.com/ripple/rippled/pull/2043) +* Allow filtering of ledger objects by type in RPC [(#2066)](https://github.com/ripple/rippled/pull/2066) +* Cleanup, refactor, and improve GetMissingNodes [(#1979)](https://github.com/ripple/rippled/pull/1979) +* Add helper to modify Env configs [(#2003)](https://github.com/ripple/rippled/pull/2003) +* Add timer start param to Application [(#2024)](https://github.com/ripple/rippled/pull/2024) +* Improve log warnings [(#2043)](https://github.com/ripple/rippled/pull/2043) +* Prevent low likelihood Database job queue crash [(#2052)](https://github.com/ripple/rippled/pull/2052) +* Remove ledger and manifest Python tools [(#2057)](https://github.com/ripple/rippled/pull/2057) + +## Bug Fixes + +* Fix displayed warning when generating brain wallets [(#2121)](https://github.com/ripple/rippled/pull/2121) +* Cmake build does not append '+DEBUG' to the version info for non-unity builds [(#1264)](https://github.com/ripple/rippled/pull/1264) +* Crossing tiny offers can misbehave on RCL [(#1884)](https://github.com/ripple/rippled/pull/1884) +* asfRequireAuth flag not always obeyed [(#2092)](https://github.com/ripple/rippled/pull/2092) +* Strand creating is incorrectly accepting invalid paths (No ticket) +* JobQueue occasionally crashes on shutdown [(#2025)](https://github.com/ripple/rippled/pull/2025) +* Prevent consensus from relaying/retrying rejected pseudo-transactions [(#2104)](https://github.com/ripple/rippled/pull/2104) +* Improve pseudo-transaction handling [(#2104)](https://github.com/ripple/rippled/pull/2104) diff --git a/content/blog/2017/rippled-0.70.1.md b/content/blog/2017/rippled-0.70.1.md new file mode 100644 index 0000000000..e2e48f9ea8 --- /dev/null +++ b/content/blog/2017/rippled-0.70.1.md @@ -0,0 +1,56 @@ +# rippled version 0.70.1 + +**UPDATE 7-12-2017:** This announcement now contains corrected SHA-256 values for the `RPM` and source `RPM`. + +The `rippled` team has released `rippled` version 0.70.1, which corrects a technical flaw in the newly [refactored](https://github.com/ripple/rippled/commit/00c60d408a887d8a986db81afbb5ead121e8310c#diff-dab2766c14d0ef8e760dc5e353fa7b9dR1389) consensus code that could, in rare cases, cause a node to get stuck in consensus due to stale votes from a peer. **Ripple requires upgrading to `rippled` version 0.70.1 immediately.** + +There are no new features in the 0.70.1 release. + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to 0.70.1 immediately.** + +## Impact of Not Upgrading + +* If you operate a `rippled` validator server, but do not upgrade to `rippled` version 0.70.1, then your `rippled` validator server could experience increased loss of synchronization with the network. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The SHA-256 for the `RPM` is: `23c8ec08d1ca8c8ce6c0602617c7e41b7f2fd249a1417a79a286a3faa5be08eb` + +The SHA-256 for the source `RPM` is: `3522546989024e783cfa933218a28ee878dcc3f334749e7456cb04a9cd07d8fc` + +For other platforms, please [compile version 0.70.1 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 3bfd9de6779994e5bbbba864791429e2f7360947 + Author: Nik Bougalis + Date: Wed Jun 28 07:15:07 2017 -0700 + + Set version to 0.70.1 + +## 0.70.1 Change Log + +* Allow compiling against OpenSSL 1.1.0, which allows compiling under the latest version of Fedora. [(#2151)](https://github.com/ripple/rippled/pull/2151) + +## Bug Fixes + +* Log invariant check messages at "fatal" level [(#2154)](https://github.com/ripple/rippled/pull/2154) + +* Fix the consensus code to update all disputed transactions after a node changes a position [(#2156)](https://github.com/ripple/rippled/pull/2156) + + +## Network Update + +The Ripple technical operations team deployed `rippled` version 0.70.1 to all `rippled` servers under its operational control, including private clusters, on Sunday, 2017-07-09. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: support@ripple.com +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.70.2.md b/content/blog/2017/rippled-0.70.2.md new file mode 100644 index 0000000000..a6ea20a128 --- /dev/null +++ b/content/blog/2017/rippled-0.70.2.md @@ -0,0 +1,51 @@ +# rippled version 0.70.2 + +The `rippled` team has released `rippled` version 0.70.2, which corrects an emergent behavior that resulted in high transaction costs and fewer transactions in validated ledgers over the past few days. The problematic behavior involved large numbers of transactions being stuck in different `rippled` instances' open ledgers without being consistently relayed to validators. The large number of "stuck" transactions filled the transaction queue and caused a dramatic increase in the open ledger cost. + +There are no new features in the 0.70.2 release. + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to 0.70.2 immediately.** + +## Impact of Not Upgrading + +If you operate a `rippled` server, but do not upgrade to `rippled` version 0.70.2, then your `rippled` server could see inconsistent transaction relaying as well as transactions getting stuck in the open ledger without being passed on to validators. In this case, your server may report very high transaction costs and brimming transaction queues. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The SHA-256 for the RPM is: b41f3d75bb0fcf67dcd3cd14fbf1a7029ce28442b6dcd19fff7df330c35ee3e7 + +The SHA-256 for the source RPM is: 8cae27e639ef57987238c7800127288857c6caa61d15342faf781749ce9ee7ff + +For other platforms, please [compile version 0.70.2 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + +``` +commit cd2d52acdcb4c58cbb5ca3f9a025a826c65f99aa +Author: Edward Hennis +Date: Tue Sep 19 14:26:06 2017 -0400 + + Set version to 0.70.2 +``` + +## 0.70.2 Change Log + +## Bug Fixes + +* Recover old open ledger transactions to the queue [(#2231)](https://github.com/ripple/rippled/pull/2231) + +## Network Update + +The Ripple operations team plans to deploy version 0.70.2 to all `rippled` servers under its operational control, including private clusters, starting at 4:00 PM PT on Thursday, 2017-09-21. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2017/rippled-0.80.0.md b/content/blog/2017/rippled-0.80.0.md new file mode 100644 index 0000000000..fd869fc38c --- /dev/null +++ b/content/blog/2017/rippled-0.80.0.md @@ -0,0 +1,97 @@ +# rippled Version 0.80.0 + +Ripple has released `rippled` version 0.80.0, which introduces several enhancements that improve the reliability, scalability and security of the XRP Ledger. Ripple recommends that all `rippled` server operators upgrade to version 0.80.0 by Tuesday, 2017-11-07, for service continuity. + +Highlights of this release include: + +* The **SortedDirectories** amendment sorts the entries in [`DirectoryNode` ledger objects](https://ripple.com/build/ledger-format/#directorynode). It also corrects a technical flaw that could, in some edge cases, prevent an empty intermediate page from being deleted. + +Ripple expects the **SortedDirectories** amendment to be enabled on Tuesday, 2017-11-07. + + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to version 0.80.0 by Tuesday, 2017-11-07, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but do not upgrade to version 0.80.0 by Tuesday, 2017-11-07, when the **SortedDirectories** Amendment is expected to be activated, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **SortedDirectories** amendment does not get approved, then your `rippled` server will not become amendment blocked and should continue to operate. + +## Action Recommended + +**If you operate a `rippled` server that uses RocksDB as its data store**, then we recommend removing the RocksDB `file_size_mb` parameter from your `rippled.cfg` config file. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the rpm is: 0f67e8fdc9c555921534b6944ca418df007cee0705ab9e2fc5423963848b2935 + +The sha256 for the source rpm is: 9c6f5074e1ec3ce6ced27c0da243bb7ed19a32a8bedf2d68809ec37845f42c1b + +For other platforms, please [compile version 0.80.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + +``` +commit cafe18c59279e7de447f25a0e00d0562d6441c7a +Author: Nik Bougalis +Date: Thu Oct 19 14:37:27 2017 -0700 + + Set version to 0.80.0 +``` + +## Network Update +The Ripple operations team plans to deploy version 0.80.0 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PST on Tuesday, 2017-10-24. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +At that time, `rippled` validators under Ripple’s operational control will begin voting for the **SortedDirectories** amendment. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +### SortedDirectories + +The **SortedDirectories** amendment addresses two distinct issues: First, it corrects a technical flaw that could, in some edge cases, prevent an empty intermediate page from being deleted. Second, it sorts directory entries within a page (other than order book page entries, which remain strictly FIFO). This makes insert operations deterministic, instead of pseudo-random and reliant on temporal ordering. Lastly, it removes the ability to perform a "soft delete" where the page number of the item to delete need not be known if the item is in the first 20 pages, and enforces a maximum limit to the number of pages that a directory can span. + + +## Upcoming Features + +The [previously announced](https://developers.ripple.com/blog/2017/rippled-0.70.0.html) FlowCross Amendment will be enabled on a future date (TBA). + +We do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA). + +You can [update to the new version](https://ripple.com/build/rippled-setup/#updating-rippled) on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please [compile the new version from source](https://github.com/ripple/rippled/tree/master/Builds). + + +## 0.80.0 Change Log + +* Improve directory insertion and deletion [(#2165)](https://github.com/ripple/rippled/pull/2165) +* Move consensus thread safety logic from the generic implementation in Consensus into the RCL adapted version RCLConsensus [(#2106)](https://github.com/ripple/rippled/pull/2106) +* Refactor Validations class into a generic version that can be adapted [(#2084)](https://github.com/ripple/rippled/pull/2084) +* Make minimum quorum Byzantine fault tolerant [(#2093)](https://github.com/ripple/rippled/pull/2093) +* Make amendment blocked state thread-safe and simplify a constructor [(#2027)](https://github.com/ripple/rippled/pull/2207/commits/be1f734845ac763ce51d61507c9ba6cf18fc3cfb) +* Use ledger hash to break ties [(#2169)](https://github.com/ripple/rippled/pull/2169) +* Refactor RangeSet [(#2113)](https://github.com/ripple/rippled/pull/2113) +* Improvements to validation quorum calculation + +## Bug Fixes + +* Check and modify amendment blocked status with each new ledger [(#2137)](https://github.com/ripple/rippled/pull/2137) +* Track escrow in recipient's owner directory [(#2212)](https://github.com/ripple/rippled/pull/2212) +* Ensure consensus close times generate identical ledgers [(#2221)](https://github.com/ripple/rippled/pull/2221) +* Recover open ledger transactions to the queue [(#2232)](https://github.com/ripple/rippled/pull/2232/commits/62127d725d801641bfaa61dee7d88c95e48820c5) diff --git a/content/blog/2017/rippled-0.80.2.md b/content/blog/2017/rippled-0.80.2.md new file mode 100644 index 0000000000..f14601d23f --- /dev/null +++ b/content/blog/2017/rippled-0.80.2.md @@ -0,0 +1,71 @@ +# rippled Version 0.80.2 + +Ripple has released `rippled` version 0.80.2, which improves the transaction dispatch logic of `rippled`, allows for more transactions to be in flight at any one time and reduces the overall resource usage of `rippled`. The improved transaction dispatch logic ensures that a transaction is dispatched at most once every 10 seconds, even if it received from multiple peers during that interval. + +The fix should also improve load accounting on peer links, reducing the number of extraneous server-server connection drops caused by redundant transaction dispatching. + +Ripple strongly recommends upgrading to `rippled` version 0.80.2 immediately. + + +## Action Required + +If you operate a `rippled` server, then you should upgrade to 0.80.2 immediately. + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to rippled version 0.80.2, then your `rippled` server will use more resources than necessary and may periodically drop transactions and fall out of sync with the network. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The SHA-256 for the RPM is: `a0f431a55a241770d7496b240e4d2c638f2cadd4126ee621c5ed980b8174223c` + +The SHA-256 for the source RPM is: `d25bda2c384c67e48fe6c29250c07039d33c6ed5d280ad19fc246469213fe251` + +For other platforms, please [compile version 0.80.2 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + +``` +commit d2fc4e3569d79d3cade78533f673f642a8d26845 +Author: Nikolaos D. Bougalis +Date: Thu Dec 14 15:30:20 2017 -0800 + + Set version to 0.80.2 +``` + +## Network Update +The Ripple technical operations team will deploy `rippled` version 0.80.2 to all production `rippled` servers under its operational control, on Friday, 12/15/2017. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + + +## 0.80.2 Change Log + +* Tune for higher transaction rate processing [(#2294)](https://github.com/ripple/rippled/pull/2294) +* Control transaction dispatch rate [(#2297)](https://github.com/ripple/rippled/pull/2297) + +## 0.80.1 Change Log + +The [previously-released `rippled` version 0.80.1](https://github.com/ripple/rippled/releases/tag/0.80.1) also included the following fixes and improvements: + +**New and Updated Features** + +- Allow including validator manifests in published list ([#2278](https://github.com/ripple/rippled/issues/2278)) +- Add validator list RPC commands ([#2242](https://github.com/ripple/rippled/issues/2242)) +- Support [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) when querying published list sites and use Windows system root certificates ([#2275](https://github.com/ripple/rippled/issues/2275)) +- Grow TxQ expected size quickly, shrink slowly ([#2235](https://github.com/ripple/rippled/issues/2235)) + +**Bug Fixes** + +- Make consensus quorum unreachable if validator list expires ([#2240](https://github.com/ripple/rippled/issues/2240)) +- Properly use ledger hash to break ties when determing working ledger for consensus ([#2257](https://github.com/ripple/rippled/issues/2257)) +- Explictly use std::deque for missing node handler in SHAMap code ([#2252](https://github.com/ripple/rippled/issues/2252)) +- Verify validator token manifest matches private key ([#2268](https://github.com/ripple/rippled/issues/2268)) diff --git a/content/blog/2017/ticksize-3days.md b/content/blog/2017/ticksize-3days.md new file mode 100644 index 0000000000..8e8e5e0f1c --- /dev/null +++ b/content/blog/2017/ticksize-3days.md @@ -0,0 +1,28 @@ +# TickSize Will Be Available in 3 Days + +This notice is for all validator operators, and may be useful for gateways that intend to use tick sizes. + +A majority of trusted validators [voted to enable the TickSize amendment](https://developers.ripple.com/blog/2017/ticksize-voting.html), which is scheduled to become active on the protocol on Tuesday, 2017-02-21. The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate. + +For a detailed look into the TickSize feature, see the [original TickSize announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html). + + +## Action Required + +1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to `rippled` version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity. + +2. **If you are a gateway issuer**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset. + +3. **If you are a market maker** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer. + +4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage. + + +## Learn More + +For more information, see the following articles in the [Ripple Developer Portal](https://ripple.com/build/): + +- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize. +- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize. + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: diff --git a/content/blog/2017/ticksize-7days.md b/content/blog/2017/ticksize-7days.md new file mode 100644 index 0000000000..7baa92a716 --- /dev/null +++ b/content/blog/2017/ticksize-7days.md @@ -0,0 +1,28 @@ +# TickSize Will Be Available in 7 Days + +This notice is for all validator operators, and may be useful for gateways that intend to use tick sizes. + +A majority of trusted validators [voted to enable the TickSize amendment](https://developers.ripple.com/blog/2017/ticksize-voting.html), which is scheduled to become active on the protocol on Tuesday, 2017-02-21. The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate. + +For a detailed look into the TickSize feature, see the [original TickSize announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html). + + +## Action Required + +1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to `rippled` version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity. + +2. **If you are a gateway issuer**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset. + +3. **If you are a market maker** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer. + +4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage. + + +## Learn More + +For more information, see the following articles in the [Ripple Developer Portal](https://ripple.com/build/): + +- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize. +- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize. + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: diff --git a/content/blog/2017/ticksize-available.md b/content/blog/2017/ticksize-available.md new file mode 100644 index 0000000000..9e8da82f01 --- /dev/null +++ b/content/blog/2017/ticksize-available.md @@ -0,0 +1,37 @@ +# TickSize is Now Available + +As [predicted previously](https://developers.ripple.com/blog/2017/ticksize-3days.html), the TickSize amendment became available on the Ripple Consensus Ledger yesterday afternoon (PST) in ledger 27841793 ([2017-02-21T23:02:52Z](https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E)). + +The amendment changes the way RCL offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate. + + +## Action Required + +1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to version 0.50.2 immediately. If you operate a `rippled` server but do not accept secure client connections, then you should upgrade to version 0.50.0 or higher immediately. + +2. **If you issue currency on the RCL**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset. If you take no action, your issued currency can still be traded using the default tick size of 15 significant digits, but Ripple strongly recommends setting a tick size between four and eight digits to provide faster price discovery and to decrease churn in the RCL order books for your currency. Ripple also recommends publishing your tick size policy to users. + +3. **If you trade on the RCL** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer. + +4. **If you have backend software** which constructs and submits transactions related to the issuing of assets on the Ripple Consensus Ledger, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt your software for correct usage. + + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.50.0 or higher, immediately, then your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments + + +## Learn More + +For more information, see the following documentation: + +- [TickSize Voting Announcement](https://developers.ripple.com/blog/2017/ticksize-voting.html) - Introduction to TickSize and recommendations for how to use it. +- [Offer Preference](https://ripple.com/build/transactions/#offer-preference) - How offers are ranked with and without TickSize. +- [AccountSet transaction](https://ripple.com/build/transactions/#accountset) - How to configure a TickSize. + +To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: diff --git a/content/blog/2017/ticksize-voting.md b/content/blog/2017/ticksize-voting.md new file mode 100644 index 0000000000..d32c09a0c1 --- /dev/null +++ b/content/blog/2017/ticksize-voting.md @@ -0,0 +1,114 @@ +# TickSize Amendment Open for Voting + +Previously [introduced](https://developers.ripple.com/blog/2017/rippled-0.50.0.html) in `rippled` version 0.50.0, the [TickSize amendment](https://ripple.com/build/amendments/#ticksize) to the Ripple Consensus Ledger is now open for voting. The amendment changes the way offers are ranked in the RCL's order books, so that currency issuers can configure how many significant digits are taken into account when ranking offers by exchange rate. + +Ripple expects several benefits to result from adoption of the TickSize amendment, including faster price discovery and deeper liquidity, as well as a reduction in transaction spam and ledger churn on the RCL. + +The introduction of TickSize demonstrates Ripple’s continued commitment to supporting the RCL as a unique distributed ledger technology for settlement of global payments. + +## Action Required + +1. **If you operate a `rippled` server and accept secure client connections**, then you should upgrade to 0.50.2 immediately. If you operate a rippled server, but do not accept secure client connections then you should upgrade to version 0.50.0 by Tuesday, 2017-02-21, for service continuity. + +2. **If you run a gateway that issues currency on the RCL**, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to determine what tick size is appropriate for your issuing asset. + +3. **If you trade on the RCL** and have algorithmic trading bots, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to update your trading system to check the tick size for a given issuer. + +4. **If you have backend software**, which constructs and submits transactions related to the issuing of assets on the Ripple network, then please review [documentation](https://ripple.com/build/transactions/#offer-preference) for the TickSize amendment to adapt it for correct usage. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 0.50.0 (or higher) by Tuesday, 2017-02-21, when **TickSize** is expected to be activated via Amendment, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **TickSize** amendment is vetoed or does not pass, then your server will not become amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + + +## TickSize Amendment Overview + +Ripple has added a new feature (called “TickSize”) to the Ripple Consensus Ledger (RCL). This feature is expected to significantly improve the performance of currency markets on RCL. Gateways (those who issue assets on the RCL) and currency traders will need to be aware of these changes as they may affect their operations. + +Currently, the RCL tracks offers to trade one currency for another with fifteen digits of price precision. This high precision has been shown to cause some poor behavior in these currency markets resulting in transaction congestion and poor liquidity. + +The tick size change permits the price granularity to be selectively reduced. Gateways must to enable this feature for their assets. Those who trade on RCL’s internal markets must be aware of the change in behavior. + +### The problem TickSize addresses + +The Ripple Consensus Ledger maintains internal order books between pairs of assets. These internal order books are used to permit cross-currency payments and to settle offers to trade assets against each other. Internally, the RCL tracks an offer’s price (that is, the rate at which the exchange takes place) with 15 digits of precision. Offers with a better price are consumed first, and offers at the same price are consumed in the order in which they were placed. + +Because the precision is so high, an offer can be placed at a microscopically better price and that offer will get priority over all existing offers at a lower price. This means that there is effectively no seniority advantage to leaving an offer on the books or stacking offers near the current exchange rate. + +A significant fraction of the RCL’s transactions are rapid sequences of the creation and deletion of offers. When a trader operating through a programmatic trading platform believes an existing price is too low, the trader places an offer at a higher price. But they will not make the price too high because that reduces their margin. Other traders react by topping their offer. This acts like an auction. + +With RCL’s microscopic tick sizes, this acts like an auction in which you can top the existing bid by a microscopic amount. As you might expect, this results in a lot of bids. Worse, it also results in slow price discovery: while these trading bots are each topping the other by a microscopic amount, the order book price remains below the true price until the order placement stabilizes. In practice, order placement never stabilizes and the flux is constant. + +### The TickSize solution + +The TickSize feature permits assets issued on the RCL to configure their tick sizes. With a tick size of three, offer prices are tracked with three digits of precision. That would mean that a trader who wanted priority over an offer to charge 1.07 dollars per Euro would have to charge no more than 1.06 dollars per Euro or a trader who wanted priority over an offer to sell bitcoins at $915 each would have to charge $914 each or less. + +This immediately makes price discovery much faster. Without the tick size, you might see a long string of offers with prices gradually going down from 1.08 to 1.07. And a payment processed at that time would get a rate worse than the fair rate. + +The TickSize feature also protects the time priority of larger orders by securing their position at the front of what may become a large queue at a specific price point; this effectively prevents front running by microscopically better price improvements. When volatility of a market becomes low versus the tick size, the economic impact of this can be significant. To the same effect, enforcing a TickSize also gives traders a larger theoretical edge versus fair value of the same asset trading on other exchanges. + +The most important long run impact of a fixed TickSize is to encourage traders to stack orders at several depths in the market in advance, with the hope of being filled when the market moves; this incentivizes traders to take inventory risk and therefore increases displayed liquidity in order books. + +In addition, if there are very small changes in the fair exchange rate, as there always are, these won’t require restructuring of the order book. Until the price variance exceeds the price increment, there is no reason for an offer to change its price and removing an existing offer would mean losing its seniority, giving priority to others who placed their offers first. + +### The mechanics of TickSize + +The TickSize amendment adds an account property also called “TickSize”. An account can set its tick size by sending an “AccountSet” transaction with a “TickSize” property. The value of the “TickSize” property should be a decimal value between 3 and 10. To clear the tick size, set the “TickSize” to zero. The configured size applies to all assets issued by the account. + +To determine an account’s configured tick size, you can use any method to get the account root (such as “account_info”). If the account has a configured tick size, there will be a “TickSize” attribute in the response. + +XRP does not have a tick size. Until configured by their issuers, issued assets use the default effective tick size of 15. If an offer is placed between two assets that do not have a tick size, no tick size is enforced. If an offer is placed between two assets that have a tick size, the smaller tick size (fewer digits of precision) controls. + +When an attempt to create an offer is made and there is a tick size, the tick size is enforced when the offer is placed into the order book. If the offer is a buy, the amount to buy is unchanged. If the offer is a sell, the amount to sell is unchanged. The tick size is enforced by adjusting the unlocked size of the offer in the offer placer’s favor towards the nearest tick size in the offer price. + +RCL internally tracks an offer’s price as the ratio of the input currency amount to the output currency amount. The price is the ratio of the input to the output or how much currency must be paid to get one unit of currency out. Offers with lower prices from the point of view of the taker are consumed first. The rounding is performed on this price. + +So, for example, if the offer at the tip of an order book were one to give 100 USD for 20 CNY, that would be internally tracked as having a price of 0.2 -- the 20 in divided by the 100 out. If the effective tick size for this order book was 4, this offer could be topped by an offer with a price of 0.1999 or less (the largest number less than 0.2 using four significant digits). So an offer to give 100.05 USD for 20 Yuan (or one to give 100 USD for 19.99 Yuan) would be needed to take the tip of the order book from the existing offer. + +The tick size is expressed as the number of digits of precision kept in the price on the books. For example, if the tick size is four, the next tick after 102.3 is 102.4, the next tick after 1.023 is 1.024, and the next tick size after 10,230 is 10,240. + +It is important to remember that it is the price (the ratio of input to output) that is rounded. Offers can still be placed for arbitrarily large or small amounts of currency and payments can still consume arbitrarily small pieces out of offers. + +### TickSize for traders + +Traders, particularly algorithmic traders, will need to be aware of how the tick size feature affects the behavior of currency markets on the RCL. We expect that gateways that opt to enable tick sizes on their assets will provide traders with reasonable notice, but traders will need to be on the lookout for those notices until the issuer of every asset they care about has published their intended policy. + +Traders will want to adjust their strategies to leave their offers on the books if the pricing is off by less than the tick size. They will want to avoid trying to top another offer by less than the tick size as this will not put their order at the tip of the order book. + +New strategies involving stacking offers near the current price should be possible. If the price moves in that direction, these offers will have a seniority advantage over newly-placed offers. + +### TickSize for gateways + +Gateways, those who issue assets on the RCL, will need to draft and publish a tick size policy. Even if a gateway opts not to set a tick size, they should still announce this intention and the amount of notice they plan to give should they ever decide to set a tick size. This will help eliminate uncertainty. + +Ripple recommends that gateways set reasonable tick sizes in pretty much all cases. This will provide better price discovery for their assets as well as improving the RCL's performance for everyone by reducing transaction spam. + +Tick sizes of between four and eight digits are reasonable. Four digits will provide rapid price discovery, but poor granularity. Seven digits will provide reasonable price discovery while preserving high granularity. If you do not select a tick size, you effectively have a tick size of 15. In almost all cases, five and six are reasonable, safe choices that should provide a good balance of granularity and rapid price discovery. + +## Upcoming Features + +The [previously announced](https://developers.ripple.com/blog/2016/rippled-0.40.0.html) Suspended Payments amendment, which introduces new transaction types to the Ripple protocol that will permit users to cryptographically escrow XRP on the RCL, will be re-introduced as an amendment simply called *Escrow*, in the next release scheduled for March. + +Also, we expect additional support for [crypto-conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), which are signature-like structures that can be used with suspended payments to support ILP integration, to be included in the next rippled release scheduled for March. + +Lastly, we do not have an update on the [previously announced](https://developers.ripple.com/blog/2016/rippled-0.33.0.html) changes to the hash tree structure that `rippled` uses to represent a ledger, called [SHAMapV2](https://ripple.com/build/amendments/#shamapv2). At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA). diff --git a/content/blog/2017/trust-line-quality-sendmax.md b/content/blog/2017/trust-line-quality-sendmax.md new file mode 100644 index 0000000000..d1f889b18f --- /dev/null +++ b/content/blog/2017/trust-line-quality-sendmax.md @@ -0,0 +1,36 @@ +# Gateway Bulletin: Setting Trust Line Quality with SendMax + +## Summary + +When you build an automated system to send payments into the Ripple Consensus Ledger (RCL) for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find flaws in a system implementation that pays them more money than it should. + +Once such flaw was [revealed](https://forum.ripple.com/viewtopic.php?f=1&t=18210) _(dead link)_ recently, related to setting [trust line quality](https://web.archive.org/web/20150422102043/https://wiki.ripple.com/Trust_line_quality), which affects gateways that use a `SendMax` value greater than the amount they deliver. This setup could result in a destination account receiving slightly higher (typically less than 1% higher) than the expected amount from the gateway's account. + +Note: This system implementation flaw does not affect XRP balances. + +## Action Recommended + +The [recommended setup](https://xrpl.org/become-an-xrp-ledger-gateway.html#sending-payments-to-customers) is to use either of the following rules: + +* Setting the `SendMax` value equal to the Amount * (1 + transfer rate); or +* Setting the `SendMax` value as low as possible and only leaving space for slippage to buffer the transaction from failing + +A malicious user can make trust line quality changes in the ledger between when you prepare a transaction and when it is validated in the ledger. To ensure that these changes cannot cause a transaction to cost you more than you expected, it is vital to set the `SendMax` no higher than the maximum amount you are willing to send. + +To reduce the chance of sending a transaction that fails, add the following checks to any transaction that delivers issued currency on a trust line: + +* Does the trust line exist? +* Is the trust line’s limit sufficient? +* Are optional incoming balances on this trust line valued at the appropriate ratio? +* Did the user freeze the trust line? + +## Learn, Ask Questions, and Discuss + +To experiment with the Ripple Consensus Ledger technology without using real money, try out the [Ripple Test Net](https://xrpl.org/xrp-testnet-faucet.html). + +### Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: +* XRP Chat: diff --git a/content/blog/2018/data-api-validations-changes.md b/content/blog/2018/data-api-validations-changes.md new file mode 100644 index 0000000000..b2bd3fe5f5 --- /dev/null +++ b/content/blog/2018/data-api-validations-changes.md @@ -0,0 +1,36 @@ +# Updates Coming to Data API + +The [Data API](https://developers.ripple.com/data-api.html), which provides data to [XRP Charts](https://xrpcharts.ripple.com/) and third-party tools, is scheduled to update to **version 2.4.0** in approximately two weeks, on **2018-11-07**. This version improves the way the Data API imports and summarizes data on XRP Ledger validators. + + +## Improvements + +The Data API v2.4.0 changes provide the following benefits: + +- Adds real-time tracking of validator agreement. +- Indicates when a validator is included in the network's recommended UNL. +- Reports validator agreement in 1-hour and 24-hour rolling windows, plus (non-rolling) daily summaries. +- Tracks whether validators follow the production network, the TestNet, or other ledger history chains. + +See the "Action Required" section below for a summary of which methods these changes apply to. + +## Action Required + +This release contains the following breaking changes: + +- **Removed methods.** The following methods are removed in v2.4.0 and will no longer be available after the release on **2018-11-07**: + - **Get Validations** (`/v2/network/validations`) + - **Get Validator Validations** (`/v2/network/validators/{pubkey}/validations`) +- **Format Changes.** The request and response formats of the following methods have changed. + - **[Get Validator](https://developers.ripple.com/data-api.html#get-validator)** (`/v2/network/validators/{pubkey}`) + - **[Get Validators](https://developers.ripple.com/data-api.html#get-validators)** (`/v2/network/validators`) + - **[Get Daily Validator Reports](https://developers.ripple.com/data-api.html#get-daily-validator-reports)** (`/v2/network/validator_reports`) + - **[Get Single Validator Daily Reports](https://developers.ripple.com/data-api.html#get-single-validator-reports)** (`/v2/network/validators/{pubkey}/validator_reports`) + +If you use any of the above API methods, you may need to make changes to use the updated API. + +### Preview on Staging + +You can try out the new methods by using `http://data-staging.ripple.com` as your base URL. + +The [API Reference documentation](https://developers.ripple.com/data-api.html) will be updated with the new formats soon. diff --git a/content/blog/2018/depositauth-fix1513-available.md b/content/blog/2018/depositauth-fix1513-available.md new file mode 100644 index 0000000000..183357e5d8 --- /dev/null +++ b/content/blog/2018/depositauth-fix1513-available.md @@ -0,0 +1,43 @@ +# The DepositAuth & fix1513 Amendments are Now Available + +The [DepositAuth](https://ripple.com/build/deposit-authorization/) & fix1513 Amendments became available on the XRP Ledger in ledger sequence number 37,753,345 [(2018-04-06T01:44:42Z)](https://xrpcharts.ripple.com/#/transactions/902C51270B918B40CD23A622E18D48B4ABB86F0FF4E84D72D9E1907BF3BD4B25). + +* The DepositAuth Amendment lets an account strictly reject any incoming money from transactions sent by other accounts. +* The fix1513 Amendment fixes an issue where calculation switchovers were not implemented in the fee escalation queue. + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to `rippled` version 0.90.1 immediately for service continuity. + +## Impact of Not Upgrading + +**If you operate a `rippled` server older than version 0.90.0**, your server is amendment blocked. A server that is amendment blocked: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If you are using `rippled` version 0.90.0, your server is not amendment blocked but you should upgrade to [`rippled` version **0.90.1**](https://developers.ripple.com/blog/2018/rippled-0.90.1.html) or higher to get important security fixes. `rippled` version 0.90.0 may stop or restart unexpectedly. + +For instructions on updating rippled on supported platforms, see [Updating rippled on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +For other platforms, please compile version 0.90.1 from source. See [the `rippled` GitHub repo](https://github.com/ripple/rippled/tree/develop/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Build and Run `rippled` on Ubuntu](https://ripple.com/build/build-run-rippled-ubuntu/). + +## Upcoming Features + +The [previously announced](https://developers.ripple.com/blog/2018/rippled-0.90.0.html) Checks amendment has lost the support of a majority of trusted validators and is not expected to become enabled in the immediate future. + +## Learn, ask questions, and discuss + +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +To continue receiving updates about the `rippled` server, please subscribe to the Ripple Server Google Group: + +Other resources: + +- The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +- [The Ripple Dev Blog](https://developers.ripple.com/blog/) +- Ripple Technical Services: +- [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2018/depositpreauth-fix1515-enabled.md b/content/blog/2018/depositpreauth-fix1515-enabled.md new file mode 100644 index 0000000000..cb6bcdfa5d --- /dev/null +++ b/content/blog/2018/depositpreauth-fix1515-enabled.md @@ -0,0 +1,53 @@ +# DepositPreauth is Now Available + +The [DepositPreauth](https://xrpcharts.ripple.com/#/transactions/AD27403CB840AE67CADDB084BC54249D7BD1B403885819B39CCF723DC671F927) and [fix1515](https://xrpcharts.ripple.com/#/transactions/6DF60D9EC8AF3C39B173840F4D1C57F8A8AB51E7C6571483B4A5F1AA0A9AAEBF) amendments, [added in `rippled` v1.1.0](https://developers.ripple.com/blog/2018/rippled-1.1.0.html), became enabled on the XRP Ledger today, 2018-10-09. + +## Action Required + +- If you operate a `rippled` server, you should upgrade to version 1.1.0 (or higher) immediately. + +For instructions on upgrading `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://developers.ripple.com/update-rippled.html). + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.1.0, then your server is now amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +## DepositPreauth Summary + +The DepositPreauth amendment provides users of [deposit authorization](https://developers.ripple.com/depositauth.html) with a way to preauthorize specific senders so those senders are allowed to send payments directly. + +The amendment adds: + +- A new transaction type, DepositPreauth, for adding or removing preauthorization. +- A DepositPreauth ledger object type for tracking preauthorizations from one account to another. +- A JSON-RPC command, `deposit_authorized`, to query whether an account is authorized to send payments directly to another. + +This amendment also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code tecNO_PERMISSION. With this amendment, those payments succeed as they would with Deposit Authorization disabled. + + +## fix1515 Summary + +The fix1515 amendment changes how Payment transactions consume offers to remove a minor difference in how payment processing and offer processing consume liquidity. + +Without the amendment, payment processing gives up on using a particular path if the transaction would consume over 2000 offers from the same order book at the same exchange rate. In this case, the payment does not use the liquidity from those offers, and does not consider that order book's remaining liquidity when attempting to complete the payment. + +With this amendment, if any transaction processes over 1000 offers at the same exchange rate, the transaction consumes the liquidity from the first 1000 offers, then does not consider that order book's remaining liquidity when attempting to complete the payment. + +In both cases, transaction processing can still complete by using liquidity from other paths or exchange rates. + + +## Learn More +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2018/fix1543-fix1571-fix1623-voting.md b/content/blog/2018/fix1543-fix1571-fix1623-voting.md new file mode 100644 index 0000000000..91a7748087 --- /dev/null +++ b/content/blog/2018/fix1543-fix1571-fix1623-voting.md @@ -0,0 +1,35 @@ +# fix1543, fix1571 & fix1623 Amendments Open for Voting + +Previously [introduced in `rippled` version 1.0.0](https://developers.ripple.com/blog/2018/rippled-1.0.0.html), the [fix1543](https://developers.ripple.com/known-amendments.html#fix1543), [fix1571](https://developers.ripple.com/known-amendments.html#fix1571) and [fix1623](https://developers.ripple.com/known-amendments.html#fix1623) amendments are now open for voting. + +* The `fix1543` amendment enforces reserved flag ranges on escrow, payment channel, and ticket transactions. +* The `fix1571` amendment changes the EscrowCreate transaction to require the Condition or FinishAfter field (or both) and also fixes a flaw that incorrectly prevents time-based Escrows from being finished in some circumstances. +* The `fix1623` amendment adds delivered amount metadata to CheckCash transactions that cash a check for a flexible amount. + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to version 1.0.0 by Tuesday, 2018-06-19 00:00:00 UTC, for service continuity. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.0.0 by Tuesday, 2018-06-19, when the [fix1543](https://developers.ripple.com/known-amendments.html#fix1543), [fix1571](https://developers.ripple.com/known-amendments.html#fix1571) and [fix1623](https://developers.ripple.com/known-amendments.html#fix1623) amendments are expected to become enabled on the network, then your server will become [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the [fix1543](https://developers.ripple.com/known-amendments.html#fix1543), [fix1571](https://developers.ripple.com/known-amendments.html#fix1571) and [fix1623](https://developers.ripple.com/known-amendments.html#fix1623) amendments do not become enabled, then your server will not become amendment blocked and should continue to operate. + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +To continue receiving updates about the `rippled` server, please subscribe to the Ripple Server Google Group: diff --git a/content/blog/2018/fix1571-enabled.md b/content/blog/2018/fix1571-enabled.md new file mode 100644 index 0000000000..0a07d476a3 --- /dev/null +++ b/content/blog/2018/fix1571-enabled.md @@ -0,0 +1,36 @@ +# fix1571 is Now Available + +As previously announced, the fix1571 amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/920AA493E57D991414B614FB3C1D1E2F863211B48129D09BC8CB74C9813C38FC) on 2018-06-19. Furthermore, the fix1623 amendment is expected to become enabled on 2018-06-20, followed by the fix1543 amendment on 2018-06-21. + +## Action Required + +- If you operate a `rippled` server, you should upgrade to [version 1.0.1](https://developers.ripple.com/blog/2018/rippled-1.0.1.html) (or higher) immediately. + +For instructions on upgrading `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://developers.ripple.com/update-rippled.html). + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.0.0, then your server is now amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +## fix1571 Summary + +Changes Escrow to fix the following issues: + +- Changes the [EscrowCreate transaction](https://developers.ripple.com/escrowcreate.html) to require the `Condition` or `FinishAfter` field (or both). Escrows with neither `Condition` nor `FinishAfter` that were created before this amendment can be finished by anyone at any time before their `CancelAfter` time. +- Fixes a flaw that incorrectly prevents time-based Escrows from being finished in some circumstances. + +## Learn More +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2018/introducing-history-sharding.md b/content/blog/2018/introducing-history-sharding.md new file mode 100644 index 0000000000..b9aa67e559 --- /dev/null +++ b/content/blog/2018/introducing-history-sharding.md @@ -0,0 +1,51 @@ +# Introducing History Sharding + +As `rippled` servers operate, they continually witness data appended onto an ever-growing blockchain. This data becomes the history that the network agrees upon and that constitutes everything about the XRP Ledger. + +As with most blockchains, it is imperative that XRP Ledger historical data remain readily available to participating servers. Therefore, every `rippled` server shares the responsibility of storing some history. But what if keeping the full history of the XRP Ledger starts to exceed the storage facility of most participants? For example, as of this writing, the space required to store full history of the XRP Ledger is over 8 terabytes, a hefty flash sum. + +The [history sharding](https://developers.ripple.com/history-sharding.html) feature, enabled in `rippled` version 0.90.0, addresses this issue by distributing history into segments called shards. A shard contains all of the data for a range of ledgers. Using the history sharding feature, individual `rippled` servers can contribute to storing historical data without needing to store the entire history. + + + +A shard store does not replace a ledger store, but implements a reliable path toward distributed ledger history across the XRP Ledger Network. The history of all ledgers is shared by servers agreeing to keep shards. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce proof trees or ledger deltas. + +Because servers that are configured with history sharding randomly select the shards that they store, the full history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history. + +## Shard Store Validation + +Beginning with `rippled` version 0.90.0, you can use the [`--validateShards`](https://developers.ripple.com/commandline-usage.html#daemon-mode-options) command to check that shard store data is valid and consistent with network history. For example: + + ./rippled --validateShards + +This operation verifies that all objects stored for every ledger stored in each shard are valid and consistent with the network. Run this command only when you start the server and note that it may take a while to complete. + + +## Node Store to Shard Store + +Beginning with `rippled` version 1.0.0, you can use the [`--nodetoshard'](https://developers.ripple.com/commandline-usage.html#daemon-mode-options) command to import the data from an existing ledger store into a shard store. For example: + + ./rippled --nodetoshard + +This command enables you to create shards based on the history you already have. The command creates shards from complete ledger ranges in the ledger store. + +The command creates a copy of the data, so your server must have the additional disk space required by the shard maximum disk space setting ([`max_size_gb`](https://developers.ripple.com/history-sharding.html#shard-store-configuration)) in the `rippled.cfg` configuration file. + + +## Downloadable Shard Archives + +Beginning with `rippled` version 1.1.0, you can use the `download_shard` API method to download and import shard archives from an HTTPS web server. For example: + + { + "command":"download_shard", + "shards":[ + { + "index":1, + "url":"https://www.domain.com/1.tar.lz4" + } + ] + } + +A shard archive is a [tar](https://en.wikipedia.org/wiki/Tar_(computing)) of a complete shard directory compressed with LZ4. Downloaded archives are checked to be valid and consistent with network history before being imported. + +For more information, see [History Sharding](https://developers.ripple.com/history-sharding.html). diff --git a/content/blog/2018/ripple-lib-1.0.0.md b/content/blog/2018/ripple-lib-1.0.0.md new file mode 100644 index 0000000000..d0133325ce --- /dev/null +++ b/content/blog/2018/ripple-lib-1.0.0.md @@ -0,0 +1,74 @@ +# ripple-lib version 1.0.0 + +We are pleased to announce the release of **[ripple-lib version 1.0.0](https://github.com/ripple/ripple-lib/releases/tag/1.0.0)**! + +ripple-lib is a high-level JavaScript interface to the XRP Ledger. This version features a range of changes and improvements that make the library more capable and flexible. It includes new methods for accessing `rippled` APIs, including subscriptions. + +When using this version with `rippled` for online functionality, we recommend using `rippled` version 1.0.1 or later. + +Below is a summary of the changes since ripple-lib version 0.22.0 (the previous non-beta version). + + +## Release Notes + +### New Features + +* [Add `request()`, `hasNextPage()`, and `requestNextPage()` for accessing `rippled` APIs](https://github.com/ripple/ripple-lib/blob/09541dae86bc859bf5928ac65b2645dfaaf7f8b1/docs/index.md#rippled-apis). +* Add `prepareTransaction()` for preparing raw `txJSON`. +* XRP amounts can be specified in drops. Also, `xrpToDrops()` and `dropsToXrp()` are available to make conversions. +* `getTransaction()` responses can include a new `channelChanges` property that describes the details of a payment channel. + +### Data Validation and Errors + +* [Amounts in drops and XRP are checked for validity](https://github.com/ripple/ripple-lib/blob/develop/HISTORY.md#100-beta1-2018-05-24). +* [A maximum fee is now imposed](https://github.com/ripple/ripple-lib/blob/develop/HISTORY.md#100-beta2-2018-06-08). Exceeding it causes a `ValidationError` to be thrown. +* Errors are improved and more data validation was added. +* Bug fix: `getPaths` now filters paths correctly and works correctly when the destination currency is XRP. + + +### Breaking Changes + +The following changes were introduced in 1.0.0. + +* `getTransaction()` and `getTransactions()` + * The `specification.destination.amount` field has been removed from the parsed transaction response. + * To determine the amount that a transaction delivered, use `outcome.deliveredAmount`. + * If you require the provisional requested `Amount` from the original transaction: + * Use `getTransaction()`'s `includeRawTransaction` option, or + * Use `getTransactions()`'s `includeRawTransactions` option, or + * Use the `rippled` APIs directly with `request()`. For example, call the API methods `tx`, `account_tx`, etc. +* `getLedger()` response object + * The `rawTransactions` field has been removed (for consistency with `getTransaction()` and `getTransactions()`). + * Instead, within each transaction, use the new `rawTransaction` JSON string. + * The `metaData` field has been renamed to `meta` for consistency with `rippled`'s `tx` method. + * `ledger_index` has been added to each raw transaction. + + +## Learn, ask questions, and discuss + +[ripple-lib Documentation](https://developers.ripple.com/rippleapi-reference.html) is available in the XRP Ledger Dev Portal. + +Other resources: + +* [Full Release History](https://github.com/ripple/ripple-lib/blob/develop/HISTORY.md) +* [GitHub Issues](https://github.com/ripple/ripple-lib/issues) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +We welcome reviews of the codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Acknowledgements + +On behalf of the XRP Community, we would like the thank those who have contributed to the development of the ripple-lib open source code, whether they did so by writing code, using the library, reporting issues, discovering bugs or offering suggestions for improvements. + +### Contributors + +The following is the list of people who made code contributions, large and small, to ripple-lib prior to the release of 1.0.0: + +Abraham Tom, Adrian Hope-Bailie, Alan Cohen, Alex Choi, amougel, Andreas Brekken, Andrey Fedorov, Arthur Britto, Ben Sharafian, Bo Chen, Brad Chase, Brandon Wilson, Brian Clifton, Cheng Wei, Chris Clark, Chris Yuen, cryptcoin-junkey, Daniel Davis, Dan Quirk, Daren Tuzi, darkmemo, David Schwartz, Edward Hennis, Elliot Lee, Evan Schwartz, Ewald Moitzi, Filip Andersson, Franziska Hinkelmann, Fred K. Schott, FrRichard, Geert Weening, Hovhannes Kuloghlyan, Ivan Tivonenko, jatchili, Jed McCaleb, Jks Liu, Justin Lynn, lid, Liucw, Luke Burns, Madeline Shortt, Manish Jethani, Matthew Fettig, Mehul Kar, Michael Elsdörfer, Moe Adham, Mo Morsi, Nicholas Dudfield, Nicolás López Jullian, Niraj Pant, professorhantzen, Reed Rosenbluth, ripplerm, Rome Reginelli, Ryan Young, sentientwaffle, Stefan Thomas, Steven Zeiler, Vahe Hovhannisyan, Vinnie Falco, Waldir Pimenta, wltsmrz and Yeechan Lu. + +We look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2018/rippled-0.81.0.md b/content/blog/2018/rippled-0.81.0.md new file mode 100644 index 0000000000..66ad941f1e --- /dev/null +++ b/content/blog/2018/rippled-0.81.0.md @@ -0,0 +1,82 @@ +# rippled Version 0.81.0 + +Ripple has released `rippled` version 0.81.0, which introduces changes that improve the scalability of the XRP Ledger and transitions the recommended validator configuration to a new hosted site, as described in [Ripple's Decentralization Strategy Update](https://developers.ripple.com/blog/2017/decent-strategy-update.html) post. + +Ripple strongly recommends upgrading to `rippled` version 0.81.0 immediately. + +## Action Required + +If you operate a `rippled` server, then you should upgrade to `rippled` version 0.81.0 immediately. + +Ripple recommends that you: + +* Edit your `rippled.cfg` to remove the `[validators]` section, if one is present. +* Replace the contents of any existing `validators.txt` file with the [version included with this release](https://github.com/ripple/rippled/blob/4e8c8deeaac83d18eb62c95b7425d96e11847a41/doc/validators-example.txt#L51-L55). If you are upgrading to `rippled` version 0.81.0 [using the rippled RPM package](https://ripple.com/build/rippled-setup/#updating-rippled), then your default `validators.txt` file may automatically be updated, in which case you will not need to modify the file. The `validators.txt` file is usually in the same directory as your `rippled.cfg` file. +* After starting your `rippled` server, confirm that it is configured to use the new defaults by executing: + +`/opt/ripple/bin/rippled validators` + +The result should include the following: + + "local_static_keys" : [], + "publisher_lists" : [ + { + "available" : true, + "expiration" : "2018-Jan-23 00:00:00", + "list" : [ + "nHB1FqfBpNg7UTpiqEUkKcAiWqC2PFuoGY7FPWtCcXAxSkhpqDkm", + "nHUpwrafS45zmi6eT72XS5ijpkW5JwfL5mLdPhEibrqUvtRcMAjU", + "nHUBGitjsiaiMJBWKYsJBHU2shmYt9m29hRqoh8AS5bSAjXoHmdd", + "nHUXh1ELizQ5QLLqtNaVEbbbfMdq3wMkh14aJo5xi83xzzaatWWP", + "nHUgoJvpqXZMZwxh8ZoFseFJEVF8ryup9r2mFYchX7ftMdNn3jLT" + ], + "pubkey_publisher" : "ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734", + "seq" : 2, + "version" : 1 + } + ], + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to `rippled` version 0.81.0, then your `rippled` server may periodically drop transactions and fall out of sync with the network. + +* On Tuesday January 16, 2018, the current validator keys on all five Ripple-operated `rippled` validator servers will be replaced. **If you have been using the recommended default configuration** and do not reconfigure your `rippled` server before that time, then your `rippled` server will stop seeing validated ledgers. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the rpm is: 75acdf54e472875bff609fa2d1cc59524e4d8f8e885751b50aaeb85938ab3609 + +The sha256 for the source rpm is: fbc95f6168d015190b93b81f97c20979886fa2f6663e4dd15157409075db46e9 + +For other platforms, please [compile version 0.81.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + commit 4e8c8deeaac83d18eb62c95b7425d96e11847a41 + Author: Nikolaos D. Bougalis + Date: Wed Jan 3 14:43:42 2018 -0800 + + Set version to 0.81.0 + + +## Network Update +The Ripple technical operations team will deploy `rippled` version 0.81.0 to all `rippled` servers under its operational control, Tuesday, 01/09/2018. + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + + +## 0.81.0 Change Log + +* New hosted validator configuration + +## Bug Fixes + +* Filter SQL results in lieu of a search clause [(#2312)](https://github.com/ripple/rippled/pull/2312) diff --git a/content/blog/2018/rippled-0.90.0.md b/content/blog/2018/rippled-0.90.0.md new file mode 100644 index 0000000000..db6f993ec2 --- /dev/null +++ b/content/blog/2018/rippled-0.90.0.md @@ -0,0 +1,160 @@ +# rippled Version 0.90.0 + +Ripple has released `rippled` version 0.90.0, which introduces several enhancements that improve the reliability, scalability and security of the XRP Ledger. Ripple recommends that all server operators upgrade to version 0.90.0 by Thursday, 2018-03-15, for service continuity. + +Highlights of this release include: + +- The **DepositAuth** Amendment, which lets an account strictly reject any incoming money from transactions sent by other accounts. +- The **Checks** Amendment, which allows users to create a deferred payment that can be canceled or cashed by its intended recipient. +- **History Sharding**, which allows `rippled` servers to distribute historical ledger data if they agree to dedicate storage for segments of ledger history. +- **Preferred Ledger by Branch**, which improves how a `rippled` server decides which ledger it should base future ledgers on when there are multiple candidates. + +Ripple expects the `DepositAuth` and `Checks` amendments to be enabled on Thursday, 2018-03-15. + +## Action Required + +If you operate a `rippled` server, you should upgrade to `rippled` version 0.90.0 by Thursday, 2018-03-15, for service continuity. + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to `rippled` version 0.90.0 by **Thursday, 2018-03-15**, when DepositAuth and Checks are expected to be enabled via Amendment, then your rippled server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the **DepositAuth** and **Checks** Amendments do not get approved, then your `rippled` server will not become Amendment blocked and should continue to operate. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The SHA-256 for the RPM is: `7d6c6d9908289edbf38660f0ab2a233b159ac7abfe502ae774bf9af579270613` + +The SHA-256 for the source RPM is: `faf0d669a38b7f97acd2d4b95b48a8c50a9859a6235be2ed289d10c6c5f96a1f` + +For other platforms, please compile version 0.90.0 from source. See the [`rippled` source tree](https://github.com/ripple/rippled/tree/develop/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Build and Run `rippled` on Ubuntu](https://ripple.com/build/build-run-rippled-ubuntu/). + +The first log entry should be the change setting the version: + + commit 6230204e425f6aef6ec1c0def0bdd1257e1c4c7f + Author: Nikolaos D. Bougalis + Date: Tue Feb 20 14:12:03 2018 -0800 + + Set version to 0.90.0 + +## Action Recommended: Configure History Shards + +If you operate a `rippled` server and want to start storing history shards, you must add a `[shard_db]` stanza to your `rippled` configuration file. The following settings are required to configure your server. The **type** field determines the database backend for the shard store. Ripple recommends using NuDB because it uses less memory and fewer file descriptors than RocksDB. The **path** field determines the location to store the database and the **max_size_gb** field limits the maximum disk space the shard store can occupy. + +Example snippet: + + [shard_db] + type=NuDB + path=/var/lib/rippled/db/shards/nudb + max_size_gb=100 + +Ripple recommends storing history shards only on non-validator servers to reduce overhead for validators. + +## Network Update +The Ripple operations team plans to deploy version 0.90.0 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PST on Wednesday, **2018-02-21**. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Other Information + +### Acknowledgements + +Ripple thanks Guido Vranken for responsibly disclosing a potential vulnerability in the parsing code handling nested JSON objects. The issue could be exploited under some circumstances to mount a denial of service attack. It was addressed with pull request [#2326](https://github.com/ripple/rippled/pull/2326). + +### Bug Bounties and Responsible Disclosures +We welcome reviews of the `rippled` codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility +When compiling `rippled` from source, you must use a compatible version of the Boost library. Ripple recommends Boost 1.64.0 for all platforms. + +Other compatible versions differ by platform. Boost 1.58.0 is compatible on Linux but not on Windows. On macOS, Boost 1.58.0 is not compatible with the Clang compiler version 4.0+. On all platforms, Boost 1.66.0 compatibility in rippled 0.90.0 is experimental. + + +## Learn, ask questions, and discuss +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +## Full Release Notes + +### DepositAuth + +The DepositAuth Amendment allows enterprise account holders to comply with strict regulations that require due diligence before receiving money from any source. When an account enables this flag, payment transactions fail if the account is the destination, regardless of whether the payment would have delivered XRP or an issued currency. + +If an Escrow has a Destination with the DepositAuth flag set, then the corresponding EscrowFinish transaction can succeed only if that transaction is signed by the Destination. Similar rules apply to Payment Channels. + +As an exception, accounts with DepositAuth enabled can receive XRP payment transactions for small amounts of XRP (equal or less than the minimum account reserve) if their current XRP balance is below the account reserve. + +For more information, see + +### Checks + +The Checks Amendment works similarly to personal paper checks and introduces a new ledger object type ([Check](https://ripple.com/build/ledger-format/#check)), a new transaction result code ([tecEXPIRED](https://ripple.com/build/transactions/#tec-codes)) and three new transaction types ([CheckCreate](https://ripple.com/build/transactions/#checkcreate), [CheckCash](https://ripple.com/build/transactions/#checkcash), [CheckCancel](https://ripple.com/build/transactions/#checkcancel)) to the XRP Ledger. + +The sender signs a CheckCreate transaction to create a Check for a specific maximum amount and specifies a destination account to receive the funds. Later, the destination account can sign a CheckCash transaction to cash the Check and receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. An account with the DepositAuth flag set can receive funds using a CheckCash transaction. + +If cashing the Check fails, the Check object remains in the ledger so it may be successfully cashed later. The sender or the receiver can sign a CheckCancel transaction to cancel a Check at any time before it is cashed. A Check can also have an expiration time, after which it cannot be cashed, and anyone can cancel it. tecEXPIRED occurs when trying to create a Check whose expiration time is in the past. + +### History Sharding + +History Sharding allows `rippled` servers to distribute historical ledger data if they agree to keep particular ranges of historical ledgers. This makes it very easy for servers to confirm that they have all the data that they're supposed to have. Further, History Sharding makes it simpler to produce proof trees or ledger deltas and challenge servers to demonstrate they actually hold the data they claim to have. + +For more information, see + +### Preferred Ledger by Branch + +Preferred Ledger by Branch improves how a `rippled` server decides which ledger it should be working on during consensus. In previous versions, a `rippled` server always checks that it is working on what it believes is the most supported ledger, but does not using the common ancestry of validated ledgers as part of that decision. Determining the best working ledger is important during rare cases of network or server instability and improves a `rippled` server's ability to re-converge with the rest of the network. + +Preferred Ledger by Branch leverages the ancestry information of branches to account for common support across validated ledgers and their ancestors, since a validation for some ledger is also a validation for all its ancestors. To find the preferred ledger, a `rippled` server starts at the most recent validated ledger and selects the child ledger with most support based on recent validations, but only selects it if an alternate sibling ledger does not possibly have more support. This process is then repeated starting from the newly chosen ledger until no better ledger exists. Preferred Ledger by Branch is designed to be conservative, only switching when the server sees enough peer validations to know another branch won't become preferred. + +## Upcoming Features +The [previously announced](https://developers.ripple.com/blog/2017/rippled-0.70.0.html) **FlowCross** Amendment will be enabled on a future date (TBA). + +Compiling `rippled` with scons is deprecated. Starting in rippled version 1.0, the only supported build will be using CMake. + +An upcoming version of `rippled` will switch to using the Boost.Beast library instead of the Beast library from the `rippled` source code. As part of this change, the minimum supported version of Boost will change to be a version incorporating Boost.Beast. + +Ripple does not expect to enable the **SHAMapV2**, **Tickets**, or **OwnerPaysFee** amendments before the next release of `rippled`. These amendments have been disabled in the source code so `rippled` 0.90.0 will not show them as available. Ripple plans to re-introduce some or all of these amendments in a future version of `rippled`. + +## 0.90.0 Change Log + +- Add support for Deposit Authorization account root flag ([#2239](https://github.com/ripple/rippled/pull/2239)) +- Implement history shards ([#2258](https://github.com/ripple/rippled/pull/2258)) +- Preferred ledger by branch ([#2300](https://github.com/ripple/rippled/pull/2300)) +- Tune for higher transaction processing ([#2294](https://github.com/ripple/rippled/pull/2294)) +- Redesign Consensus Simulation Framework ([#2209](https://github.com/ripple/rippled/pull/2209)) +- Optimize queries for account_tx to work around SQLite query planner ([#2312](https://github.com/ripple/rippled/pull/2312)) +- Allow Journal to be copied/moved ([#2292](https://github.com/ripple/rippled/pull/2292)) +- Cleanly report invalid [server] settings ([#2305](https://github.com/ripple/rippled/pull/2305)) +- Improve log scrubbing ([#2358](https://github.com/ripple/rippled/pull/2358)) +- Update rippled-example.cfg ([#2307](https://github.com/ripple/rippled/pull/2307)) +- Force json commands to be objects ([#2319](https://github.com/ripple/rippled/pull/2319)) +- Fix cmake clang build for sanitizers ([#2325](https://github.com/ripple/rippled/pull/2325)) +- Allow account_objects RPC to filter by “check” ([#2356](https://github.com/ripple/rippled/pull/2356)) +- Limit nesting of json commands ([#2326](https://github.com/ripple/rippled/pull/2326)) +- Update Visual Studio build instructions ([#2355](https://github.com/ripple/rippled/pull/2355)) +- Unit test that sign_for returns a correct hash ([#2333](https://github.com/ripple/rippled/pull/2333)) +- Force boost static linking for MacOS builds ([#2334](https://github.com/ripple/rippled/pull/2334)) +- Update MacOS build instructions ([#2342](https://github.com/ripple/rippled/pull/2342)) +- Add dev docs generation to Jenkins ([#2343](https://github.com/ripple/rippled/pull/2343)) +- Poll if process is still alive in Test.py ([#2290](https://github.com/ripple/rippled/pull/2290)) +- Remove unused beast::currentTimeMillis() ([#2345](https://github.com/ripple/rippled/pull/2345)) + +### Bug Fixes + +- Improve error message on mistyped command ([#2283](https://github.com/ripple/rippled/pull/2283)) +- Add missing includes ([#2368](https://github.com/ripple/rippled/pull/2368)) +- Link boost statically only when requested ([#2291](https://github.com/ripple/rippled/pull/2291)) +- Unit test logging fixes ([#2293](https://github.com/ripple/rippled/pull/2293)) +- Fix Jenkins pipeline for branches ([#2289](https://github.com/ripple/rippled/pull/2289)) +- Avoid AppVeyor stack overflow ([#2344](https://github.com/ripple/rippled/pull/2344)) +- Reduce noise in log ([#2352](https://github.com/ripple/rippled/pull/2352)) diff --git a/content/blog/2018/rippled-0.90.1.md b/content/blog/2018/rippled-0.90.1.md new file mode 100644 index 0000000000..c8653f2681 --- /dev/null +++ b/content/blog/2018/rippled-0.90.1.md @@ -0,0 +1,92 @@ +# rippled version 0.90.1 + +Ripple has released `rippled` version 0.90.1, which includes fixes for issues reported by external security researchers. These issues, when exploited, could cause a `rippled` instance to restart or, in some circumstances, stop executing. + +While these issues can result in a denial of service attack, none affect the integrity of the XRP Ledger and no user funds, including XRP, are at risk. + +## Action Required + +**If you operate a `rippled` server, then you should upgrade to `rippled` version 0.90.1 as soon as possible.** + +### Impact of Not Upgrading + +If you operate a `rippled` server but do not upgrade to version 0.90.1, your server may experience restarts or outages. + +### Upgrading + +For instructions on updating `rippled` on supported platforms, see here: [Updating rippled](https://ripple.com/build/rippled-setup/#updating-rippled) + +The SHA-256 for the rpm is: a22aff93d3de98ac3e1d775612e75e0e81aa7e6c18187db01efed485f854bab0 + +The SHA-256 for the source rpm is: abaaaba2039c8cd93218fd6a23c79b32bfb6eba92a465b7f9c0716b37fb45795 + +For other platforms, please compile version 0.90.1 from source. See [rippled Builds](https://github.com/ripple/rippled/tree/master/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Build and Run `rippled` on Ubuntu](https://ripple.com/build/build-run-rippled-ubuntu/). + +The first log entry should be the change setting the version: + + commit 067dbf299c297a8361e83e2ceaf7b0822ff9a3f5 + Author: Nikolaos D. Bougalis + Date: Tue Mar 6 16:38:02 2018 -0800 + Set version to 0.90.1 + +## Network Update + +The Ripple operations team plans to deploy version 0.90.1 to all `rippled` servers under its operational control, including private clusters, starting at 5:00 PM PST on Thursday, 2018-03-22. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Other Information + +### Acknowledgements + +Ripple thanks Guido Vranken for responsibly disclosing a potential out-of-bounds memory access in the base58 encoder/decoder, a vulnerability in the parsing code handling nested serialized objects and a codepath where untrusted public input involving public keys was used without first being properly validated. These issues could be exploited to mount a denial of service attack. + +### Bug Bounties and Responsible Disclosures + +We welcome reviews of the `rippled` codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility + +When compiling `rippled` from source, you must use a compatible version of the Boost library. Ripple recommends Boost 1.64.0 for all platforms. + +Other compatible versions differ by platform. Boost 1.58.0 is compatible on Linux but not on Windows. On macOS, Boost 1.58.0 is not compatible with the Clang compiler version 4.0+. On all platforms, Boost 1.66.0 compatibility in `rippled` 0.90.1 is experimental. + +## Learn, ask questions, and discuss + +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* The Ripple Dev Blog: + +* Ripple Technical Services: + +* XRP Chat: + +### Upcoming Features + +The previously announced DepositAuth, Checks and fix1513 amendments are now open for voting on the XRP Ledger. The DepositAuth Amendment lets an account strictly reject any incoming money from transactions sent by other accounts. The Checks Amendment allows users to create a deferred payment that can be cancelled or cashed by its intended recipient. The fix1513 amendment fixes a minor bug in rounding calculations. Ripple expects the **DepositAuth**, **Checks**, and **fix1513** amendments to be enabled on Thursday, 2018-04-05. + +The [previously announced](https://developers.ripple.com/blog/2017/rippled-0.70.0.html) **FlowCross** Amendment will be enabled on a future date (TBA). + +Compiling `rippled` with scons is deprecated. Starting in `rippled` version 1.0, the only supported build will be using CMake. + +An upcoming version of `rippled` will switch to using the Boost.Beast library instead of the Beast library from the `rippled` source code. As part of this change, the minimum supported version of Boost will change to be a version incorporating Boost.Beast. + +Ripple does not expect to enable the **SHAMapV2**, **Tickets**, or **OwnerPaysFee** amendments before the next release of rippled. These amendments have been disabled in the source code so `rippled` 0.90.1 will not show them as available. Ripple plans to re-introduce some or all of these amendments in a future version of rippled. + +## 0.90.1 Change Log + +### Bug Fixes + +* Address issues identified by external review + + * Verify serialized public keys more strictly before using them (RIPD-1617, RIPD-1619, RIPD-1621) + + * Eliminate a potential out-of-bounds memory access in the base58 encoding/decoder logic. (RIPD-1618) + + * Avoid invoking undefined behavior in memcpy (RIPD-1616) + +* Limit STVar recursion during deserialization (RIPD-1603) + +* Use lock when creating a peer shard rangeset diff --git a/content/blog/2018/rippled-1.0.0.md b/content/blog/2018/rippled-1.0.0.md new file mode 100644 index 0000000000..7257876db1 --- /dev/null +++ b/content/blog/2018/rippled-1.0.0.md @@ -0,0 +1,164 @@ +# rippled Version 1.0.0 + +Today, after almost 6 years of hard work, Ripple is very pleased to announce the release of `rippled` version 1.0.0. + +The `rippled` v1.0.0 release includes incremental improvements to several previously released features. v1.0.0 also symbolizes the growing maturity of the software and the increased stability of the decentralized, growing network of nodes that are running the software all around the world. Moving forward, `rippled` will continue to use [semantic versioning](https://semver.org/) (MAJOR.MINOR.PATCH), to help organize and track future releases. + +Ripple recommends that all server operators upgrade to `rippled` v1.0.0 by Thursday, 2018-06-14, for service continuity. + +## Action Required + +**If you operate a `rippled` server**, you should upgrade to `rippled` version 1.0.0 by Thursday, 2018-06-14, for service continuity. + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to version 1.0.0 by Thursday, 2018-06-14--when **[fix1543](https://developers.ripple.com/known-amendments.html#fix1543)**, **[fix1571](https://developers.ripple.com/known-amendments.html#fix1571)** and **[fix1623](https://developers.ripple.com/known-amendments.html#fix1623)** are expected to be enabled via Amendment——then your `rippled` server will become amendment blocked. A server that is amendment blocked: + + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Cannot rely on potentially invalid data + +If the **fix1543**, **fix1571** and **fix1623** Amendments are not enabled, then your `rippled` server will not become amendment blocked and should continue to operate. + +## Upgrading + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled`](https://developers.ripple.com/update-rippled.html). + +The SHA-256 for the RPM is: `100376fbbfdf540264097c333a76b562c742fa5800c65f3c555d16347e23cda3` + +The SHA-256 for the source RPM is: `10f472979785db537c4d28bc5a9c71c642cfeac306557368e588d72797439eda` + +For other platforms, please compile v1.0.0 from source. See the [`rippled` source tree](https://github.com/ripple/rippled/tree/develop/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Install `rippled` on Ubuntu](https://developers.ripple.com/install-rippled.html#installation-on-ubuntu-with-alien). + +The first log entry should be the change setting the version: + + commit f31ca2860fb5f045b618aa05d1e76c7e2e9494ec + Author: Nikolaos D. Bougalis + Date: Fri May 11 10:29:41 2018 -0700 + Set version to 1.0.0 + + +## Network Update + +The Ripple technical operations team has deployed version 1.0.0 to all `rippled` servers under its operational control, including private clusters. + + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Developer Portal](https://developers.ripple.com/index.html), including detailed reference information, tutorials, and web tools. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + +## Other Information + +**Bug Bounties and Responsible Disclosures** + +Ripple welcomes reviews of the `rippled` codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +**Boost Compatibility** + +When compiling `rippled` from source, you must use a compatible version of the Boost library. Ripple recommends Boost v1.64.0 for all platforms. + +For compatibility with other Boost versions, see the following table. + + +| Boost Version | Compatible Platforms | Incompatible Platforms | +|:-------------:|:--------:|:----------:| +| 1.67.0 | Experimental on all platforms | None | +| 1.64.0 | All platforms | None | +| 1.58.0. | Linux, macOS (with Clang compiler version 4.0+) | Windows | + + + + +## 1.0.0 Change Log + +* Improve history sharding to now use the shard store to satisfy ledger requests + +* Change permessage-deflate and compress defaults [(#2372)](https://github.com/ripple/rippled/pull/2372) + +* Update validations on UNL change [(#2393)](https://github.com/ripple/rippled/pull/2393) + +### Bug Fixes + +* Clarify Escrow Semantics [(#2419)](https://github.com/ripple/rippled/pull/2419) + +* Add check, escrow, and pay_chan to ledger_entry [(#2455)](https://github.com/ripple/rippled/pull/2455) + + +### `rippled` Retrospective + +#### What is `rippled`? + +`rippled` is the C++ reference implementation of the decentralized XRP Ledger. It is open source and permissively licensed under the ISC. + +#### What is the XRP Ledger? + + +The **XRP Ledger** is a public decentralized cryptographic ledger powered by a global network of peer-to-peer servers. The XRP Ledger is the root ledger of XRP, a digital asset designed to bridge global currencies for payments. As a software company, Ripple contributes to the open source development of the XRP Ledger, in support of the Internet of Value: a world in which money moves the way information does today. + +For more information, see [XRP Ledger Overview](https://developers.ripple.com/xrp-ledger-overview.html). + +#### Consensus + +Among the key benefits of the XRP Ledger is a fast and efficient consensus algorithm, which can settle transactions in 4 to 5 seconds, while processing at a throughput of up to 1,500 transactions per second. + +The consensus algorithm is [censorship-resistant](https://developers.ripple.com/xrp-ledger-overview.html#censorship-resistant-transaction-processing). Because no single party decides which transactions succeed or fail, no one can "roll back" a transaction after it completes and no one has control over the consensus algorithm. Instead, individual server operators can select a list of validators that they choose to trust not to collude in an attempt to defraud the rest of the network. + +For more information on how the XRP Ledger's consensus algorithm works, see [Consensus](https://developers.ripple.com/consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Consensus Principles and Rules](https://developers.ripple.com/consensus-principles-and-rules.html). + +#### Protocol Amendments + +The XRP Ledger has integrated support for [amendments](https://developers.ripple.com/amendments.html), which allow for the introduction of new features to the decentralized XRP Ledger network without causing disruptions. Amendments work by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. + +#### Cryptography + +The XRP Ledger relies on industry-standard digital signature systems like ECDSA using the [secp256k1 standard curve](http://www.secg.org/sec2-v2.pdf) (which is also used by Bitcoin). The XRP Ledger also supports modern, efficient algorithms like [Ed25519](https://ed25519.cr.yp.to/). The extensible nature of the XRP Ledger's software makes it possible to add and disable algorithms as the state of the art in cryptography advances. + +For more information, see: + +* [Cryptographic Keys](https://developers.ripple.com/cryptographic-keys.html) +* [Multi-signing](https://developers.ripple.com/multi-signing.html) + +#### Advanced Features + +In addition to multi-signing, the XRP Ledger supports other advanced features, such as: + +* [Escrow](https://developers.ripple.com/escrow.html) +* [Checks](https://developers.ripple.com/checks.html) +* [Deposit Authorization](https://developers.ripple.com/depositauth.html) +* [Payment Channels](https://developers.ripple.com/payment-channels.html) +* [Crypto-Conditions](https://tools.ietf.org/html/draft-thomas-crypto-conditions-04) + +These features make it possible to implement cutting-edge financial applications or interact with the [Interledger Protocol](https://interledger.org/). This toolbox of advanced features comes with a wide range safety checks that validate all transactions against a list of invariant constraints. + +#### Decentralized Exchange + +The XRP Ledger also has a fully-functional accounting system for publicly tracking and trading obligations denominated in any way users want, along with a decentralized exchange built into the ledger. The XRP Ledger can settle long, cross-currency [payment paths](https://developers.ripple.com/paths.html) and [exchanges](https://developers.ripple.com/decentralized-exchange.html) of multiple currencies in atomic transactions, bridging gaps of trust with XRP. + +For more information on how the decentralized exchange works, see: + +* [On-Ledger Decentralized Exchange](https://developers.ripple.com/xrp-ledger-overview.html#on-ledger-decentralized-exchange) +* [Decentralized Exchange](https://developers.ripple.com/decentralized-exchange.html) +* [Offers](https://developers.ripple.com/offers.html) +* [Become an XRP Ledger Gateway](https://developers.ripple.com/become-an-xrp-ledger-gateway.html) + +#### Acknowledgements + +On behalf of the XRP Community, Ripple would like the thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +#### Contributors + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.0.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jennifer Hasegawa, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As `rippled` moves to the 1.x series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2018/rippled-1.0.1.md b/content/blog/2018/rippled-1.0.1.md new file mode 100644 index 0000000000..4262d2d829 --- /dev/null +++ b/content/blog/2018/rippled-1.0.1.md @@ -0,0 +1,80 @@ +# rippled Version 1.0.1 + +Ripple has released `rippled` version 1.0.1, which includes fixes for issues identified by Ripple engineers and reported by external security researchers. These issues, when exploited, could cause a `rippled` instance to restart or, in some circumstances, stop executing. + +While these issues can result in a denial of service attack, none affect the integrity of the XRP Ledger and no user funds, including XRP, are at risk. + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to `rippled` version 1.0.1 as soon as possible. + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to version 1.0.1 as soon as possible, then your server may experience restarts or outages. + +## Upgrading + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled`](https://developers.ripple.com/update-rippled.html). + +The SHA-256 for the RPM is: `4bfa27b0e1e1979f2bc042edb9dd11ae4119dac6be087813dadcc67572877189` + +The SHA-256 for the source RPM is: `60279abc65476b0a96ddedcd23338ce1c6fb5481ab94fe8b8c856448044e3ebe` + +For other platforms, please compile v1.0.1 from source. See the [`rippled` source tree](https://github.com/ripple/rippled/tree/develop/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Install `rippled` on Ubuntu](https://developers.ripple.com/install-rippled.html#installation-on-ubuntu-with-alien). + +The first log entry should be the change setting the version: + + commit 8429dd67e60ba360da591bfa905b58a35638fda1 + Author: Nik Bougalis + Date: Mon Jun 4 16:36:22 2018 -0700 + + Set version to 1.0.1 + +## Network Update + +The Ripple operations team plans to deploy version 1.0.1 to all `rippled` servers under its operational control, including private clusters, starting at 3:00 PM PST on Thursday, 2018-06-14. The deployment is expected to complete within 5 hours. The network should continue to operate during deployment and no outage is expected. + +## Other Information + +**Acknowledgements** + +Ripple thanks Guido Vranken for discovering and responsibly disclosing an off-by-one error in the base64 decoder logic when handling malformed input. + +**Bug Bounties and Responsible Disclosures** + +Ripple welcomes reviews of the `rippled` codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +**Boost Compatibility** + +When compiling `rippled` from source, you must use a compatible version of the Boost library. Ripple recommends Boost 1.64.0 for all platforms. + +Other compatible versions differ by platform. Boost 1.58.0 is compatible on Linux but not on Windows. On macOS, Boost 1.58.0 is not compatible with the Clang compiler version 4.0+. + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Developer Portal](https://developers.ripple.com/index.html), including detailed reference information, tutorials, and web tools. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + + +## Upcoming Features + +The previously [introduced](https://developers.ripple.com/blog/2018/rippled-1.0.0.html) [fix1543](https://developers.ripple.com/known-amendments.html#fix1543), [fix1571](https://developers.ripple.com/known-amendments.html#fix1571) and [fix1623](https://developers.ripple.com/known-amendments.html#fix1623) Amendments in XRP Ledger version 1.0.0 are now open for voting. Ripple expects these amendments to become enabled on Tuesday, 2018-06-19. + +An upcoming version of `rippled` will switch to using the **Boost.Beast** library instead of the **Beast** library from the `rippled` source code. As part of this change, the minimum supported version of Boost will change to be a version incorporating Boost.Beast. + +Ripple does not expect to enable the **SHAMapV2**, **Tickets**, or **OwnerPaysFee** Amendments before the next release of `rippled`. These Amendments have been disabled in the source code so `rippled` version 1.0.1 will not show them as available. Ripple plans to re-introduce some or all of these amendments in a future version of `rippled`. + + +## 1.0.1 Change Log + +### Bug Fixes + +* Improve JSON exception handling + +* Fix a corner case when decoding base64: Under some corner cases, the base64 decoder would not allocate enough memory, which could result in spurious errors. diff --git a/content/blog/2018/rippled-1.1.0.md b/content/blog/2018/rippled-1.1.0.md new file mode 100644 index 0000000000..05eef0ed58 --- /dev/null +++ b/content/blog/2018/rippled-1.1.0.md @@ -0,0 +1,136 @@ +# Introducing XRP Ledger (rippled) version 1.1.0 + +Ripple is pleased to announce the release of **XRP Ledger (`rippled`) version 1.1.0.** + +The XRP Ledger version 1.1.0 release includes the [DepositPreAuth](https://developers.ripple.com/known-amendments.html#depositpreauth) Amendment, which, combined with the previously released [DepositAuth](https://developers.ripple.com/known-amendments.html#depositauth) Amendment, allows users to pre-authorize incoming transactions to accounts, by whitelisting sender addresses. XRP Ledger version 1.1.0 release also includes incremental improvements to several previously released features ([fix1515](https://developers.ripple.com/known-amendments.html#fix1515) Amendment), deprecates support for the sign and sign_for commands from the rippled API and improves invariant checking for enhanced security. + +Ripple recommends that all server operators upgrade to XRP Ledger version 1.1.0 by Thursday, 2018-09-27, to ensure service continuity. + +## Action Required + +**If you operate a XRP Ledger server, you should upgrade to XRP Ledger version 1.1.0 by Thursday, 2018-09-27, to ensure service continuity.** + +### Impact of Not Upgrading + +Ripple expects the **DepositPreAuth** or **fix1515** amendments to become enabled on or after Thursday, 2018-09-27. When this happens, if you are not running release 1.1.0 or greater, your server will become [amendment blocked](https://ripple.com/build/amendments/#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot be able to submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +If the **DepositPreAuth** and **fix1515** Amendments do not become enabled, then your XRP Ledger server will not become Amendment blocked and should continue to operate. + +### Upgrading + +For instructions on updating the XRP Ledger server on supported platforms, see here: [Updating `rippled` on Supported Platforms](https://developers.ripple.com/update-rippled.html). + +- The SHA-256 for the RPM is: `ec50f3cec7dcbea8aaa2eb9d97c3c1fc02d44ce62203557b4cd213cf1b0fe4b5` + +- The SHA-256 for the source RPM is: `936844990e70615183681c41884ea96804ee4130d6f9ec32242fb3a16120824f` + +For other platforms, please compile version 1.1.0 from source. See [`rippled` build instructions by platform](https://github.com/ripple/rippled/tree/master/Builds), or [Build and Run `rippled` on Ubuntu Linux](https://ripple.com/build/build-run-rippled-ubuntu/) for further instructions. + +The first log entry should be the change setting the version: + + commit 3e22a1e9e8f2de450eded6ca4c2db6411e329b2a + Author: Nik Bougalis + Date: Wed Sep 5 18:34:43 2018 -0700 + + Set version to 1.1.0 + +## Network Update + +The Ripple technical operations has deployed version 1.1.0 to all XRP Ledger servers under its operational control, including private clusters, as of Thursday, 2018-09-13. + +## Learn, ask questions, and discuss + +Related documentation is available in the XRP Ledger Dev Portal, including detailed example API calls and web tools for API testing: [https://developers.ripple.com/](https://developers.ripple.com/) + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* The Ripple Dev Blog: +* Ripple Technical Services: +* XRP Chat: + +## Other Information + +### Bug Bounties and Responsible Disclosures + +On behalf of the XRP Community, Ripple would like to thank Guido Vranken, for responsibly disclosing several issues related to some of the encoder / decoder logic in rippled. As always, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit[ https://ripple.com/](https://ripple.com/bug-bounty/)[bug-bounty](https://ripple.com/bug-bounty/)[/](https://ripple.com/bug-bounty/). + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **As of XRP Ledger version 1.1.0, Boost 1.67.0 is required for all platforms.** + +## 1.1.0 Change Log + +* Add DepositPreAuth ledger type and transaction ([#2513](https://github.com/ripple/rippled/pull/2513)) + +* Increase fault tolerance and raise validation quorum to 80%, which fixes issue [2604](https://github.com/ripple/rippled/issues/2604) ([#2613](https://github.com/ripple/rippled/pull/2613)) + +* Support ipv6 for peer and RPC comms ([#2321](https://github.com/ripple/rippled/pull/2321)) + +* Refactor ledger replay logic ([#2477](https://github.com/ripple/rippled/pull/2477)) + +* Improve Invariant Checking ([#2532](https://github.com/ripple/rippled/pull/2532/commits/2ac1c2b433b8825b9a6f203f1ee65a126e20620c)) + +* Expand SQLite potential storage capacity ([#2650](https://github.com/ripple/rippled/pull/2650/commits/04745b11a888cea412f410d0036a0db23574d61c)) + +* Replace UptimeTimer with UptimeClock ([#2532](https://github.com/ripple/rippled/pull/2532/commits/7d163a45dcd2c5cca0fc45eb8775f169575995c1)) + +* Don’t read Amount field if it is not present ([#2566](https://github.com/ripple/rippled/pull/2566/commits/34d3f93868b87f33fdf76a5b6c8b376956346a16)) + +* Remove Transactor:: mFeeDue member variable ([#2586](https://github.com/ripple/rippled/pull/2586/commits/5b733fb4857ff1076d2e106afeb9931fca198d51)) + +* Remove conditional check for using Boost.Process ([#2586](https://github.com/ripple/rippled/pull/2586/commits/06d0ff6e5281ca237d358e953fe8069d16a6926a)) + +* Improve charge handling in NoRippleCheckLimits test ([#2629](https://github.com/ripple/rippled/pull/2629/commits/49bcdda41881f6cac140879a236be6ac1a7a734d)) + +* Migrate more code into the chrono type system ([#2629](https://github.com/ripple/rippled/pull/2629/commits/d257d1b2c9e0a50f6cef2d1fc977573944408723)) + +* Supply ConsensusTimer with milliseconds for finer precision ([#2629](https://github.com/ripple/rippled/pull/2629/commits/d98c4992dd82090bb6d4f7593768624f6e109b32)) + +* Refactor / modernize Cmake ([#2629](https://github.com/ripple/rippled/pull/2629/commits/37d9544ef722730d34899754654b71e84d9f7851)) + +* Add delimiter when appending to cmake_cxx_flags ([#2650](https://github.com/ripple/rippled/pull/2650/commits/4aa0bc37c0fdfb871f5929e7bd544f787db412af)) + +* Remove using namespace declarations at namespace scope in headers ([#2650](https://github.com/ripple/rippled/pull/2650/commits/2901577be73fc2e6f2fd71d693258660c2f5f724)) + +### Bug Fixes + +* Deprecate the ‘sign’ and ‘sign_for’ APIs ([#2657](https://github.com/ripple/rippled/pull/2657)) + +* Use liquidity from strands that consume too many offers, which will be enabled on [fix1515](https://developers.ripple.com/known-amendments.html#fix1515) Amendment ([#2546](https://github.com/ripple/rippled/pull/2546)) + +* Fix a corner case when decoding base64 ([#2605](https://github.com/ripple/rippled/pull/2605/commits/0439dcfa7a5215cc74a8e254a28eadace6a524b7)) + +* Trim space in Endpoint::from_string ([#2593](https://github.com/ripple/rippled/pull/2593)) + +* Correctly suppress sent messages ([#2564](https://github.com/ripple/rippled/pull/2564)) + +* Detect when a unit test child process crashes ([#2415](https://github.com/ripple/rippled/pull/2415)) + +* Add missing virtual destructors ([#2532](https://github.com/ripple/rippled/pull/2532/commits/717f874767f2a431294244c0b532b00e508705ca)) + +* Improve JSON exception handling ([#2605](https://github.com/ripple/rippled/pull/2605/commits/00df097e5f2f533b81038b2c350bb2d896febd2e)) + +* Handle WebSocket construction exceptions ([#2629](https://github.com/ripple/rippled/pull/2629/commits/d89ff1b63d6792a25af872746013387001ebb72b)) + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at [https://github.com/ripple/rippled](https://github.com/ripple/rippled). + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.1.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger moves to the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2018/rippled-1.1.1.md b/content/blog/2018/rippled-1.1.1.md new file mode 100644 index 0000000000..a394966dde --- /dev/null +++ b/content/blog/2018/rippled-1.1.1.md @@ -0,0 +1,65 @@ +# rippled Version 1.1.1 + +Ripple has released `rippled` version 1.1.1, which improves handling of validator list sites. These changes improve retrieval of Ripple's recommended UNL for servers in restrictive network environments, and prevent incorrect behavior in cases where a server is unable to fetch a validator list update before the previous list expires. + +## Action Required + +**If you operate a `rippled` server**, then you should upgrade to `rippled` version 1.1.1 as soon as possible. + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to version 1.1.1, then your server may behave incorrectly if it is unable to fetch a new validator list before its current list expires. (If your network configuration causes `rippled` to encounter HTTP redirects when fetching the validator list, this can prevent `rippled` 1.1.0 and lower from correctly downloading the updated list in a timely manner.) + +## Upgrading + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled`](https://developers.ripple.com/update-rippled.html). + +The SHA-256 for the RPM is: `a833fbaf988d85c985f80ad4dfd46a391cce7e884fba62b2f9b1b87aa41c3cfa` + +The SHA-256 for the source RPM is: `a88b538fc3ee0bb5cefe3e96622faebecebcc91e5c530f74283d49c9cfff41d4` + +For other platforms, please compile v1.1.1 from source. See the [`rippled` source tree](https://github.com/ripple/rippled/tree/develop/Builds) for instructions by platform. For instructions building `rippled` from source on Ubuntu Linux, see [Install `rippled` on Ubuntu](https://developers.ripple.com/install-rippled.html#installation-on-ubuntu-with-alien). + +The first log entry should be the change setting the version: + + commit 72e6005f562a8f0818bc94803d222ac9345e1e40 + Author: seelabs + Date: Fri Oct 19 13:12:40 2018 -0400 + + Set version to 1.1.1 + +## Network Update + +The Ripple operations team plans to deploy version 1.1.1 to all `rippled` servers under its operational control, including private clusters, starting at 2:00 PM PDT on Tuesday, 2018-10-23. The deployment is expected to complete within 5 hours. The network should continue to operate during deployment and no outage is expected. + +**Bug Bounties and Responsible Disclosures** + +Ripple welcomes reviews of the `rippled` codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +**Boost Compatibility** + +When compiling `rippled` from source, you must use a compatible version of the Boost library. **For version 1.1.1, Boost 1.67.0 is required for all platforms.** + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Developer Portal](https://developers.ripple.com/), including detailed reference information, tutorials, and web tools. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat](http://www.xrpchat.com/) + + + +## 1.1.1 Change Log + +### Bug Fixes + +- Follow the `Location:` HTTP header when fetching a validator list results in a redirect status code such as **301 Moved Permanently**, **302 Found**, **307 Temporary Redirect**, or **308 Permanent Redirect**. (RIPD-1669) + +- Improve behavior of `rippled` servers when their latest available validator list is past its expiration (RIPD-1661): + - Report the problem with an ERROR-level log message. + - Stop sending validation messages for new ledgers until a non-expired validator list is available. + - Report the validator list as `expired` in the [server_info method](https://developers.ripple.com/server_info.html) and [server_state method](https://developers.ripple.com/server_state.html). diff --git a/content/blog/2018/rippled-1.1.2.md b/content/blog/2018/rippled-1.1.2.md new file mode 100644 index 0000000000..071712d594 --- /dev/null +++ b/content/blog/2018/rippled-1.1.2.md @@ -0,0 +1,84 @@ +# Introducing XRP Ledger (rippled) version 1.1.2 + +Ripple is proud to announce the release of **XRP Ledger** (`rippled`) version 1.1.2. + +The XRP Ledger version 1.1.2 release includes a fix for a technical issue in the consensus "preferred ledger by branch" code, which could cause a validator to fail to settle on a single preferred branch of unconfirmed ledger history. While this is not entirely unexpected and the code is designed to handle it, this issue exposed a corner case where the stringent safety guarantees of the consensus algorithm, as outlined in the recent [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) paper, make it difficult for the entire network to efficiently recover from this condition. + + + +## Action Required + +**If you operate a XRP Ledger validator server,** then you should upgrade to XRP Ledger version 1.1.2 as soon as possible. + +### Impact of Not Upgrading + +If you are not running release 1.1.2 or greater, then your validator server can potentially fail to settle on a single preferred ledger branch during consensus and resort to issuing partial validations, until it can resync with the network. + +### Upgrading + +For instructions on updating `rippled` on supported platforms, see [Installing rippled](https://developers.ripple.com/install-rippled.html). + +The SHA-256 for the RPM is: `989a679bef72e827f204b394abd3d385f1baae6ad7a94eaf9b759a032bcd0f7e` + +The SHA-256 for the source RPM is: `091b60dcf38aea4f9ec252d7b1b72d95ca4f45b3a831fbe97ce8f806f2907cae` + +For other platforms, please compile version 1.1.2 from source. + +- [Build and Run `rippled` on Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) +- [Build and run `rippled` on macOS](https://developers.ripple.com/build-run-rippled-macos.html) +- See for instructions by platform. + +The first log entry should be the change setting the version: + +```text +commit 4f3a76dec00c0c7ea28e78e625c68499debbbbf3 +Author: Nik Bougalis +Date: Thu Nov 29 21:49:10 2018 -0800 + Set version to 1.1.2 +``` + +## Network Update + +Ripple plans to deploy version 1.1.2 to all XRP Ledger servers under its operational control, including private clusters, on Tuesday, 2018-12-11 at 22:00:00 UTC. + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing: + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +On behalf of the XRP Community, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **As of XRP Ledger version 1.1.2, Boost 1.67.0 is required for all platforms.** + +## 1.1.2 Change Log + +### Bug Fixes + +* Improve preferred ledger calculation ([#2797](https://github.com/ripple/rippled/pull/2797/commits/bd2a38f5844ce824c02cce1ed97e9cf0cd04c019)) + +* Properly bypass connection limits for cluster peers ([#2795](https://github.com/ripple/rippled/pull/2797/commits/61f443e3bbf3bf1f6e13f3ef25bb5fc60fe85078)) + +## Contributions + +**We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at .** + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (`rippled`) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to rippled prior to the release of 1.1.2: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Iroskam, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger progresses through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2018/rippled-boost166-warning.md b/content/blog/2018/rippled-boost166-warning.md new file mode 100644 index 0000000000..95d0ac4e2a --- /dev/null +++ b/content/blog/2018/rippled-boost166-warning.md @@ -0,0 +1,33 @@ +# Boost 1.66 Not Supported for rippled 0.81.0 + +A warning to developers: `rippled` versions 0.81.0 and earlier do not compile with the recently-released Boost library version 1.66.0. To compile `rippled` yourself, Ripple recommends using **Boost version 1.65.1**. The minimum supported version of Boost is 1.58.0, which is included in the official repositories of Ubuntu 16.04 Xenial. + +## Compiler Errors + +If you try to compile `rippled` version 0.81.0 with Boost version 1.66.0 or higher, you get compiler errors such as the following: + +``` +In file included from src/beast/include/beast/core/detail/type_traits.hpp:13:0, + from src/beast/include/beast/core/impl/static_string.ipp:12, + from src/beast/include/beast/core/static_string.hpp:1106, + from src/beast/include/beast/core/string_param.hpp:13, + from src/beast/include/beast/http/fields.hpp:12, + from src/beast/include/beast/http/message.hpp:12, + from src/ripple/server/Handoff.h:24, + from src/ripple/overlay/Overlay.h:26, + from src/ripple/app/consensus/RCLConsensus.cpp:39, + from src/ripple/unity/app_consensus.cpp:21: +/usr/include/boost/asio/io_service.hpp:27:20: error: conflicting declaration + ‘typedef class boost::asio::io_context boost::asio::io_service’ + typedef io_context io_service; +``` + +If you encounter this issue, please downgrade to Boost version 1.65.1. + +## Background + +Boost 1.66.0 [introduces the `Boost.Beast` library for HTTP and WebSocket connections](http://www.boost.org/doc/libs/1_66_0/libs/beast/doc/html/beast/introduction.html). The Beast library was built by [prolific coder and Ripple alum Vinnie Falco](https://github.com/vinniefalco) as an add-on to the `Boost.Asio` library, for use in `rippled` and other C++ software. Because Beast made its start in the `rippled` code base, the version already included in `rippled` conflicts with the version included as part of the Boost library in versions 1.66.0 and higher. + +## Future Work + +Ripple expects to make `rippled` compatible with Boost 1.66.0 and higher in a future release. At that time, `rippled` will no longer be compatible with Boost version 1.65.x and lower. Stay tuned to `rippled` release announcements for updates on this transition. diff --git a/content/blog/2018/rippled-validator-key-replacement.md b/content/blog/2018/rippled-validator-key-replacement.md new file mode 100644 index 0000000000..95f83140bd --- /dev/null +++ b/content/blog/2018/rippled-validator-key-replacement.md @@ -0,0 +1,94 @@ +# rippled Validator Key Replacement + + +On Wednesday, January 18, 2018, as described in the [0.81.0 release notes](https://github.com/ripple/rippled/blob/develop/RELEASENOTES.md), the current validator keys on all five Ripple-operated `rippled` validator servers will be replaced. **If you have been using the previous recommended default configuration** and do not reconfigure your `rippled` server to the new recommended default configuration before that time, then your `rippled` server will stop seeing validated ledgers. + +Ripple strongly recommends upgrading to `rippled` version 0.81.0 immediately. + +## Action Required + +If you operate a `rippled` server, then you should upgrade to 0.81.0 immediately. + +Ripple recommends that you: + +* Edit your `rippled.cfg` to remove the `[validators]` section, if one is present + +* Add a `[validators_file]` section if one is not present, and add the name of your `validators.txt` file. + +* Replace the contents of any existing `validators.txt` file with the [version included with this release](https://github.com/ripple/rippled/blob/4e8c8deeaac83d18eb62c95b7425d96e11847a41/doc/validators-example.txt#L51-L55). If you are upgrading to `rippled` version 0.81.0 [using the `rippled` RPM package](https://ripple.com/build/rippled-setup/#updating-rippled), then your default `validators.txt` file may automatically be updated, in which case you will not need to modify the file. The `validators.txt` file is usually in the same directory as your `rippled.cfg` file. + +* After starting your `rippled` server, confirm that it is configured to use the new defaults by executing: + + /opt/ripple/bin/rippled validators + +The result should include the following: + + "local_static_keys" : [], + "publisher_lists" : [ + { + "available" : true, + "expiration" : "2018-Jan-23 00:00:00", + "list" : [ + "nHB1FqfBpNg7UTpiqEUkKcAiWqC2PFuoGY7FPWtCcXAxSkhpqDkm", + "nHUpwrafS45zmi6eT72XS5ijpkW5JwfL5mLdPhEibrqUvtRcMAjU", + "nHUBGitjsiaiMJBWKYsJBHU2shmYt9m29hRqoh8AS5bSAjXoHmdd", + "nHUXh1ELizQ5QLLqtNaVEbbbfMdq3wMkh14aJo5xi83xzzaatWWP", + "nHUgoJvpqXZMZwxh8ZoFseFJEVF8ryup9r2mFYchX7ftMdNn3jLT" + ], + "pubkey_publisher" : "ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734", + "seq" : 2, + "version" : 1 + } + ], + + +## Impact of Not Upgrading + +* **If you operate a `rippled` server**, but do not upgrade to `rippled` version 0.81.0, then your `rippled` server may periodically drop transactions and fall out of sync with the network. + +* On Wednesday, January 17, 2018, as described in the 0.81.0 release notes, the current validator keys on all five Ripple-operated `rippled` validator servers will be replaced. **If you have been using the recommended default configuration **and do not reconfigure your `rippled` server before that time, then your `rippled` server will stop seeing validated ledgers. + +For instructions on updating `rippled` on supported platforms, see [Updating `rippled` on supported platforms](https://ripple.com/build/rippled-setup/#updating-rippled). + +The sha256 for the RPM is: 75acdf54e472875bff609fa2d1cc59524e4d8f8e885751b50aaeb85938ab3609 + +The sha256 for the source RPM is: fbc95f6168d015190b93b81f97c20979886fa2f6663e4dd15157409075db46e9 + +For other platforms, please [compile version 0.81.0 from source](https://github.com/ripple/rippled/tree/master/Builds). + +The first log entry should be the change setting the version: + + +``` +commit 4e8c8deeaac83d18eb62c95b7425d96e11847a41 +Author: Nikolaos D. Bougalis +Date: Wed Jan 3 14:43:42 2018 -0800 + + Set version to 0.81.0 +``` + +## 0.81.0 Change Log + +* New hosted validator configuration + +## Bug Fixes + +* Optimize queries for `account_tx` to work around SQLite query planner ([#2312](https://github.com/ripple/rippled/pull/2312)) + +## Network Update + +The Ripple technical operations team deployed `rippled` version 0.81.0 to all `rippled` validator servers under its operational control, on Tuesday, 2018-01-09. + +## Learn, ask questions, and discuss + +Related documentation is available in the [Ripple Developer Portal](https://ripple.com/build/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) + +* Ripple Technical Services: + +* [XRP Chat](http://www.xrpchat.com/) diff --git a/content/blog/2019/biased-nonce-sense-flowchart-source.uxf b/content/blog/2019/biased-nonce-sense-flowchart-source.uxf new file mode 100644 index 0000000000..a4051f571f --- /dev/null +++ b/content/blog/2019/biased-nonce-sense-flowchart-source.uxf @@ -0,0 +1,318 @@ + + + 10 + + Relation + + 350 + 10 + 30 + 90 + + lt=<- + 10.0;70.0;10.0;10.0 + + + UMLSpecialState + + 350 + 0 + 20 + 20 + + type=initial + + + + Text + + 730 + 140 + 210 + 130 + + You are not affected. + +(With regards to the XRP Ledger. If you use other cryptocurrencies, consider your keys for each system you use.) +style=wordwrap + + + + Text + + 310 + 130 + 120 + 70 + + Do you have an XRP Ledger account? +style=wordwrap + + + + Relation + + 450 + 140 + 270 + 40 + + lt=<- +r2=No + 250.0;20.0;10.0;20.0 + + + UMLSpecialState + + 260 + 300 + 200 + 160 + + type=decision + + + + Relation + + 350 + 230 + 50 + 90 + + lt=<- +Yes + 10.0;70.0;10.0;10.0 + + + Text + + 300 + 340 + 140 + 70 + + Have you signed any transactions from the account in question? +style=wordwrap + + + + Relation + + 450 + 150 + 270 + 250 + + lt=<- +r2=No + 250.0;10.0;180.0;10.0;180.0;230.0;10.0;230.0 + + + UMLSpecialState + + 260 + 80 + 200 + 160 + + type=decision + + + + UMLSpecialState + + 260 + 520 + 200 + 160 + + type=decision + + + + Relation + + 350 + 450 + 50 + 90 + + lt=<- +Yes + 10.0;70.0;10.0;10.0 + + + Text + + 300 + 560 + 150 + 90 + + Do you know all of your signatures have used software that uses deterministic nonces? +style=wordwrap +fontsize=12 + + + + Relation + + 350 + 670 + 50 + 190 + + lt=<- +r2=Yes + 10.0;170.0;10.0;10.0 + + + UMLSpecialState + + 550 + 520 + 200 + 160 + + type=decision + + + + Text + + 590 + 560 + 140 + 80 + + Have you changed your key after any signatures that might have used weak nonces? +fontsize=12 +style=wordwrap + + + + UMLSpecialState + + 700 + 150 + 20 + 20 + + type=final + + + + Text + + 290 + 0 + 50 + 30 + + Start +style=wordwrap + + + + Relation + + 740 + 580 + 120 + 40 + + lt=<- +No + 100.0;20.0;10.0;20.0 + + + Text + + 870 + 570 + 220 + 110 + + *You may be affected.* + +Consider changing your account's key or even creating a new account and transferring funds into it. +style=wordwrap + + + + UMLSpecialState + + 840 + 590 + 20 + 20 + + type=flow_final + + + + UMLNote + + 10 + 550 + 220 + 100 + + Tip: "rippled" and "ripple-lib" versions from August 2015 and later always use deterministic nonces. +bg=#1db4ff +fg=white +style=wordwrap +transparency=0 + + + + Relation + + 450 + 580 + 120 + 40 + + lt=<- +r2=No + 100.0;20.0;10.0;20.0 + + + UMLSpecialState + + 350 + 840 + 20 + 20 + + type=final + + + + Text + + 380 + 830 + 210 + 130 + + You are not affected. + +(With regards to the XRP Ledger. If you use other cryptocurrencies, consider your keys for each system you use.) +style=wordwrap + + + + Relation + + 350 + 670 + 340 + 190 + + lt=<- +r2=Yes + 10.0;170.0;10.0;110.0;300.0;110.0;300.0;10.0 + + diff --git a/content/blog/2019/corrections-to-data-api-xrp-charts-metrics.md b/content/blog/2019/corrections-to-data-api-xrp-charts-metrics.md new file mode 100644 index 0000000000..d485f3466b --- /dev/null +++ b/content/blog/2019/corrections-to-data-api-xrp-charts-metrics.md @@ -0,0 +1,12 @@ +# Corrections to Data API / XRP Charts Metrics for 2019-03-23 + +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](https://xrpcharts.ripple.com/#/metrics), 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](https://developers.ripple.com/known-amendments.html#fix1578) on 2019-03-23. This necessitated changes to the [ripple-binary-codec library](https://github.com/ripple/ripple-binary-codec) used by the ingestion service, but [those changes](https://github.com/ripple/ripple-binary-codec/pull/27) were only partially deployed to the ingestion service. We have since reprocessed and corrected the metrics that were affected by this problem. + +[Data API]: https://developers.ripple.com/data-api.html +[XRP Charts]: https://xrpcharts.ripple.com/ + + + +The [Data API][] and [XRP Charts][] are public services that Ripple supports but they are not intended for large-scale production use. These services are also independent from the core XRP Ledger, which is a distributed system that is not operated by any one party. + +Although we will continue to improve our tools going forward, it is important to note that Ripple is one participant in the broader XRP Ledger ecosystem and we are excited to see the amazing tools and services that independent developers are building on the XRP Ledger. diff --git a/content/blog/2019/discover-xrp-ledger-explorer.md b/content/blog/2019/discover-xrp-ledger-explorer.md new file mode 100644 index 0000000000..22356b955c --- /dev/null +++ b/content/blog/2019/discover-xrp-ledger-explorer.md @@ -0,0 +1,28 @@ +# Discover the XRP Ledger with Explorer! + +Today, a new XRP Ledger explorer is available for both test net and production at [explorer.xrpl.org](https://explorer.xrpl.org/). + + + +At its core the XRP Ledger is a replicated state machine. The state, or historical information, is updated every 3-5 seconds through a process called [consensus](https://xrpl.org/consensus-network.html), across a global network of independent servers. + +Collectively, the XRP Ledger network can be referred to as a distributed ledger or more commonly, a blockchain. + +One of the benefits of a public blockchain is its transparency. Like any public blockchain, the XRP Ledger allows anyone with the right skills and tools to look up historical information that is immutably stored in it. + +At the time of this writing, the XRP Ledger has closed over 48 million ledgers, confirmed over 900 million transactions and opened over 1.5 million accounts in its first 7 years of operation. + +The new explorer serves as a tool to help people look up: historical transactions, accounts, ledgers, fees, exchange rates, timestamps, sequence numbers, node uptime, IP addresses, topology, versions and peers. + +Check out the new Explorer today: + +- [Production XRP Ledger Explorer](http://livenet.xrpl.org/) +- [Test Net XRP Ledger Explorer](https://testnet.xrpl.org/) + +Other similar tools that allow people to look up XRP Ledger historical information include: + +- + +- + +- diff --git a/content/blog/2019/fix1578-enabled.md b/content/blog/2019/fix1578-enabled.md new file mode 100644 index 0000000000..ba66cb867e --- /dev/null +++ b/content/blog/2019/fix1578-enabled.md @@ -0,0 +1,37 @@ +# fix1578 is Now Available + +[As previously announced](https://developers.ripple.com/blog/2019/fix1578-expected.html), the fix1578 amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/7A80C87F59BCE6973CBDCA91E4DBDB0FC5461D3599A8BC8EAD02FA590A50005D) on 2019-03-23. + +## Action Required + +- If you operate a `rippled` server, you should upgrade to version 1.2.0 (or higher) immediately. Version 1.2.2 is recommended. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://developers.ripple.com/install-rippled.html). + + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.2.0, then your server is now amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +## fix1578 Summary + +Changes the result codes returned by two transaction types: + +- Changes the [OfferCreate transaction](https://developers.ripple.com/offercreate.html) to return a new result code, `tecKILLED`, if the offer used the `tfFillOrKill` flag and was killed. Without this amendment, the offer is killed but the transaction result is `tesSUCCESS`. +- Changes the [TrustSet transaction](https://developers.ripple.com/trustset.html) to fail with `tecNO_PERMISSION` if it tries to enable the [NoRipple flag](https://developers.ripple.com/rippling.html#the-noripple-flag) but cannot because the trust line has a negative balance. Without this amendment, the transaction does not enable the NoRipple flag, but the transaction result is `tesSUCCESS` nonetheless. + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/fix1578-expected.md b/content/blog/2019/fix1578-expected.md new file mode 100644 index 0000000000..70023c3650 --- /dev/null +++ b/content/blog/2019/fix1578-expected.md @@ -0,0 +1,55 @@ +# The fix1578 and fixTakerDryOfferRemoval Amendments are Expected + +The fix1578 amendment to the XRP Ledger, introduced in [`rippled` v1.2.0](https://github.com/ripple/rippled/releases/tag/1.2.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/147C93F2D60CB7A3FEC16957B6BD64A6D5C4411DD00D82B51189B5DE9A6FC438). 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](https://xrpcharts.ripple.com/#/transactions/B6441A0F494112AD5931DB5A5E9E1F8B40B29A7FEE41CFCF8D5B11C5897A6920). 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. + + + +## fix1578 Summary + +Changes the result codes returned by two transaction types: + +- Changes the [OfferCreate transaction](https://developers.ripple.com/offercreate.html) to return a new result code, `tecKILLED`, if the offer used the `tfFillOrKill` flag and was killed. Without this amendment, the offer is killed but the transaction result is `tesSUCCESS`. +- Changes the [TrustSet transaction](https://developers.ripple.com/trustset.html) to fail with `tecNO_PERMISSION` if it tries to enable the [NoRipple flag](https://developers.ripple.com/rippling.html#the-noripple-flag) but cannot because the trust line has a negative balance. Without this amendment, the transaction does not enable the NoRipple flag, but the transaction result is `tesSUCCESS` nonetheless. + + +## fixTakerDryOfferRemoval Summary + +Fixes a bug in [auto-bridging](https://developers.ripple.com/autobridging.html) that can leave a dry offer in the XRP Ledger. A dry offer is an offer that, if crossed, cannot yield any funds. + +Without this fix, the dry offer remains on the ledger and counts toward its owner's [reserve requirement](https://developers.ripple.com/reserves.html#owner-reserves) without providing any benefit to the owner. Another offer crossing of the right type and quality can remove the dry offer. However, if the required offer crossing type and quality are rare, it may take a while for the dry offer to be removed. + +With this amendment enabled, the XRP Ledger removes these dry offers when they're matched in auto-bridging. + + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.2.0 (or higher) by 2019-03-23, for service continuity. The most recent version of `rippled`, version 1.2.2, is recommended. + +- If you use the XRP Ledger for your business, be sure you are ready to handle the new response codes that may be returned after the amendment becomes enabled. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.2.0 (or higher) by 2019-03-23, when the fix1578 amendment is expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the fix1578 amendment does not become enabled, then your server will not become amendment blocked until the fixTakerDryOfferRemoval amendment becomes enabled on 2019-04-02. If neither amendment becomes enabled, older server versions should continue to operate without becoming amendment blocked. However, it is still recommended that you update to [`rippled` version 1.2.2](https://github.com/ripple/rippled/releases/tag/1.2.2) or higher. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://developers.ripple.com/install-rippled.html). + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/fixmasterkeyasregularkey-1day.md b/content/blog/2019/fixmasterkeyasregularkey-1day.md new file mode 100644 index 0000000000..0719431a27 --- /dev/null +++ b/content/blog/2019/fixmasterkeyasregularkey-1day.md @@ -0,0 +1,42 @@ +# fixMasterKeyAsRegularKey is Expected Tomorrow + +The fixMasterKeyAsRegularKey amendment to the XRP Ledger, introduced in [`rippled` v1.3.1](https://github.com/ripple/rippled/releases/tag/1.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. + +## fixMasterKeyAsRegularKey Summary + +Fixes a bug where accounts can set their regular key pair to match their master key pair, but cannot send transactions signed by the key if the master key is disabled. + +Without this fix, a user can unintentionally "black hole" their account by setting the regular key to match the master key, then disabling the master key. The network rejects transactions signed with the both-master-and-regular key pair because the code interprets them as being signed with the disabled master key before it recognizes that they are signed by the currently-enabled regular key. + +With this amendment enabled, a SetRegularKey transaction cannot set the regular key to match the master key; such a transaction results in the transaction code `temBAD_REGKEY`. Additionally, this amendment changes the signature verification code so that accounts which _already_ have their regular key set to match their master key can send transactions successfully using the key pair. + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.3.1 (or higher) by 2019-10-02, for service continuity. + +- If you are one of the few individuals whose account was unable to submit transactions because of this bug, your account will be able to send transactions again after the amendment becomes enabled on 2019-10-02. + +- Otherwise, this amendment should have no impact on your usage of the XRP Ledger. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.3.1 (or higher) by 2019-10-02, when the fixMasterKeyAsRegularKey amendment is expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the fixMasterKeyAsRegularKey amendment does not become enabled, then your server will not become amendment blocked and should continue to operate. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The XRP Ledger Dev Blog](https://xrpl.org/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/fixmasterkeyasregularkey-enabled.md b/content/blog/2019/fixmasterkeyasregularkey-enabled.md new file mode 100644 index 0000000000..64ebc1b5d4 --- /dev/null +++ b/content/blog/2019/fixmasterkeyasregularkey-enabled.md @@ -0,0 +1,37 @@ +# fixMasterKeyAsRegularKey is Now Available + +[As previously announced](https://xrpl.org/blog/2019/fixmasterkeyasregularkey-expected.html), the fixMasterKeyAsRegularKey amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/61096F8B5AFDD8F5BAF7FC7221BA4D1849C4E21B1BA79733E44B12FC8DA6EA20) on 2019-10-02. + +## Action Required + +- If you operate a `rippled` server, you should upgrade to version 1.3.1 (or higher) immediately. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.3.1, then your server is now amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +## fixMasterKeyAsRegularKey Summary + +Fixes a bug where accounts can set their regular key pair to match their master key pair, but cannot send transactions signed by the key if the master key is disabled. + +Without this fix, a user can unintentionally "black hole" their account by setting the regular key to match the master key, then disabling the master key. The network rejects transactions signed with the both-master-and-regular key pair because the code interprets them as being signed with the disabled master key before it recognizes that they are signed by the currently-enabled regular key. + +With this amendment enabled, a SetRegularKey transaction cannot set the regular key to match the master key; such a transaction results in the transaction code `temBAD_REGKEY`. Additionally, this amendment changes the signature verification code so that accounts which _already_ have their regular key set to match their master key can send transactions successfully using the key pair. + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The XRP Ledger Dev Blog](https://xrpl.org/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) \ No newline at end of file diff --git a/content/blog/2019/fixmasterkeyasregularkey-expected.md b/content/blog/2019/fixmasterkeyasregularkey-expected.md new file mode 100644 index 0000000000..e110321929 --- /dev/null +++ b/content/blog/2019/fixmasterkeyasregularkey-expected.md @@ -0,0 +1,42 @@ +# The fixMasterKeyAsRegularKey Amendment is Expected 2019-10-02 + +The fixMasterKeyAsRegularKey amendment to the XRP Ledger, introduced in [`rippled` v1.3.1](https://github.com/ripple/rippled/releases/tag/1.3.1), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/EE38E5927605FAB1BD8CFE44C9BE5118B4FD558F846E3DA717C23DA2ADB65991). 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. + +## fixMasterKeyAsRegularKey Summary + +Fixes a bug where accounts can set their regular key pair to match their master key pair, but cannot send transactions signed by the key if the master key is disabled. + +Without this fix, a user can unintentionally "black hole" their account by setting the regular key to match the master key, then disabling the master key. The network rejects transactions signed with the both-master-and-regular key pair because the code interprets them as being signed with the disabled master key before it recognizes that they are signed by the currently-enabled regular key. + +With this amendment enabled, a SetRegularKey transaction cannot set the regular key to match the master key; such a transaction results in the transaction code `temBAD_REGKEY`. Additionally, this amendment changes the signature verification code so that accounts which _already_ have their regular key set to match their master key can send transactions successfully using the key pair. + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.3.1 (or higher) by 2019-10-02, for service continuity. + +- If you are one of the few individuals whose account was unable to submit transactions because of this bug, your account will be able to send transactions again after the amendment becomes enabled on 2019-10-02. + +- Otherwise, this amendment should have no impact on your usage of the XRP Ledger. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.3.1 (or higher) by 2019-10-02, when the fixMasterKeyAsRegularKey amendment is expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the fixMasterKeyAsRegularKey amendment does not become enabled, then your server will not become amendment blocked and should continue to operate. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The XRP Ledger Dev Blog](https://xrpl.org/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/fixtakerdryofferremoval-enabled.md b/content/blog/2019/fixtakerdryofferremoval-enabled.md new file mode 100644 index 0000000000..62e4c6353e --- /dev/null +++ b/content/blog/2019/fixtakerdryofferremoval-enabled.md @@ -0,0 +1,41 @@ +# fixTakerDryOfferRemoval is Now Available + +[As previously announced](https://developers.ripple.com/blog/2019/fix1578-expected.html), the fixTakerDryOfferRemoval amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/C42335E95F1BD2009A2C090EA57BD7FB026AD285B4B85BE15F669BA4F70D11AF) on 2019-04-02. + +## Action Required + +- If you operate a `rippled` server, you should upgrade to version 1.2.0 (or higher) immediately. [Version 1.2.3](https://developers.ripple.com/blog/2019/rippled-1.2.3.html) is recommended. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://developers.ripple.com/install-rippled.html). + + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.2.0, then your server has been [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked) since 2019-03-23, when the [fix1578 amendment became enabled](https://developers.ripple.com/blog/2019/fix1578-enabled.html). If your server is amendment blocked, that means it: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + + +## fixTakerDryOfferRemoval Summary + +Fixes a bug in [auto-bridging](http://developers.ripple.com/autobridging.html) that can leave a dry offer in the XRP Ledger. A dry offer is an offer that, if crossed, cannot yield any funds. + +Without this fix, the dry offer remains on the ledger and counts toward its owner's [reserve requirement](http://developers.ripple.com/reserves.html#owner-reserves) without providing any benefit to the owner. Another offer crossing of the right type and quality can remove the dry offer. However, if the required offer crossing type and quality are rare, it may take a while for the dry offer to be removed. + +With this amendment enabled, the XRP Ledger removes these dry offers when they're matched in auto-bridging. + + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/interledger-checkin.md b/content/blog/2019/interledger-checkin.md new file mode 100644 index 0000000000..24ed10fd94 --- /dev/null +++ b/content/blog/2019/interledger-checkin.md @@ -0,0 +1,59 @@ +# Interledger Check-in + +Here at Ripple, we've been eagerly following and contributing to the progress of [Interledger](https://interledger.org), 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. + + + +## Interledger is for Interoperability + +First, some review for those who aren't familiar with Interledger: it's a protocol suite for enabling the Internet of Value. There's no Interledger coin or token, no chain of blocks with a shared set of state and balances, and no company or country who decides what you can do with it. The Interledger project is about taking a step away from the technological race of building [the best ledger](https://developers.ripple.com/xrp-ledger-overview.html), and instead bringing all ledgers together into a single interconnected network—creating an "Interledger" the same way that the Internet connected a bunch of individual networks into one massive "Internet". + +Ripple's own Evan Schwartz provides [a great intro to Interledger's key features and design choices](https://medium.com/xpring/interledger-how-to-interconnect-all-blockchains-and-value-networks-74f432e64543), and a more detailed look at [why Interledger is structured as a layered protocol suite](https://medium.com/xpring/layer-3-is-for-interoperability-ca387fa5f7e2). + +## Developing on Interledger + +When you build a blockchain-connected application or service, you get access to payments and data from that one blockchain. If you want access to payments and data from another blockchain or centralized system, you have to repeat that work for the new system. Building on Interledger lets you abstract away the differences between the underlying technologies. If your app can send and receive Interledger payments, you get free access to more and more payments systems and currencies as the Interledger grows. + +### Production and Testnet + +Right now, Interledger is being used in production by a small number of finance tech pioneers, including [Coil][], [Kava](https://kava.io/), [Strata](https://www.stratalabs.io/), and the [XRPTipBot](https://www.xrptipbot.com/). Thanks to these developers and the XRP Ledger's robust [payment channel](http://developers.ripple.com/payment-channels.html) functionality, it's easy to get started sending and receiving XRP through Interledger today. + +If you're not ready to use real money yet, you can start by [building on the Interledger Testnet using the Moneyd server](https://medium.com/interledger-blog/using-moneyd-to-join-the-ilp-testnet-ba64bd42bb14). Moneyd provides a quick on-ramp as the "home router" of the Interledger, giving apps on your computer access to send and receive money. Although Moneyd can just as easily connect to the production Interledger, it is not currently designed for heavy production use, so it lacks features like budgeting that would let you give apps different spending limits and permissions levels. + +Production users can run the [ILP Connector reference implementation](https://github.com/interledgerjs/ilp-connector) directly using [Kubernetes](https://kubernetes.io/) or a similar system. The Coil team has also just recently introduced an [alternative ILP Connector implementation called Rafiki](https://medium.com/interledger-blog/introducing-rafiki-e3de4710d3de), which is well-positioned to become a major component of the Interledger ecosystem. + + +## Interledger Use Cases + +The Interledger ecosystem is still relatively small today; you can't yet pay your utility bills or buy a coffee through Interledger. Existing payment systems with strong network effects, like PayPal, Venmo, and Alipay, are already pretty effective at serving those use cases, especially within regions where they're in widespread use. One case that Interledger already serves much better than legacy payment systems is **micropayments**. + +Micropayments are payments that are too small to be worth thinking about individually. To date, businesses have had to work around the need for micropayments by using subscription models or advertisement revenue. The fact that Interledger can stream tiny payments provides an alternative, where systems can charge per-use fees, without needing to ask and prompt a person to decide about every individual purchase. Two examples of standards building upon this advantage today are **web content monetization** and **decentralized app hosting**. + +### Web Content Monetization + +[Web monetization](https://interledger.org/rfcs/0028-web-monetization/) is a standard designed as part of the Interledger Protocol Suite to allow micropayments to stream from a content consumer to a creator as payment for consuming content. [Coil][] users today automatically pay out to content creators—including websites, YouTube channels, and Twitch streams—if those creators enable web monetization. Receiving micropayments via web monetization is as simple as setting up a payment pointer, then adding a [single `` tag](https://interledger.org/rfcs/0028-web-monetization/#examples) to your website's HTML code. + +### Decentralized App Hosting + +Decentralized apps, or DApps, are an emerging trend in finance technology that have developed from the idea of smart contracts. One of the big challenges with decentralized apps is scaling: existing decentralized apps mostly run on a blockchain like Ethereum, and every node in the peer-to-peer network must be able to run all smart contracts. [Codius](https://codius.org/) represents a different approach: wrap your DApp in a secure container, and use Interledger to pay for hosting it. Other users, or even the app itself, can also pay for hosting the app. Those who have computing resources to spare can offer to host Codius apps, competing to provide the best reliability and service, without requiring the "all or none" level of commitment that it takes to run a blockchain node. + +### Other Use Cases + +A variety of other use cases for Interledger are possible, and the viability of some use cases will grow as the ecosystems and tools become more standardized. From [trust-minimized cryptocurrency trading](https://github.com/Kava-Labs/ilp-sdk), to [Quake deathmatches](https://medium.com/interledger-blog/ildeathmatch-monetize-your-quake-games-788b0a7c624c), to pay-for-use APIs, to [crowd-funded power outlets](https://medium.com/@WietseWind/raspberry-pi-interledger-enabled-power-switch-d6966662b04b), there are lots of crazy ideas out there of what you can do when you're [programming with money](https://medium.com/interledger-blog/program-with-money-on-codius-5bec60386c5c). + + +## You Are Not the Product + +An old saying goes, "if you're not paying for the product, you are the product," because advertisements and data collection can derive great profits without charging the apparent customer anything. Of course, these aren't truly free, because ads are manipulative, data collection sacrifices privacy, and the two combined can be even more manipulative. Blockchains, including the XRP Ledger, are the start of something different, but Interledger takes it a step further by providing a level of privacy that blockchains inherently can't. + +As a general rule, all data in a [blockchain](https://www.distributedagreement.com/2018/09/24/what-is-a-blockchain/) is public: for all members of a blockchain to reach agreement, they need to know the state of the data to verify its integrity and to progress to the next state. Pseudonyms and mixing of inputs can obscure some of the information, but they can't change the fundamental limitations of blockchain technology. + +Interledger is different. Since it's not one single system, there's no need for consensus between distant participants. Transactions between two directly-connected users can stay limited to just those users. With longer-chain payments, most details are encrypted with a key only the sender and receiver know. No one sees all Interledger traffic. Moneyd forwards packets to its "parent" connector but can't read their contents (just a numeric amount and the ILP address the packet is bound for). Moreover, the Moneyd server and all the Interledger reference implementations are provided free of charge and open-source with permissive licenses that grant you the freedom to modify and use them as you like. + +## Learn More + +The [Interledger Forum](https://forum.interledger.org/) is a great place to ask questions, learn more from the experts, float your ideas, and connect with like-minded individuals who are exploring the future of money. + +We're excited to see what you can [BUIDL](https://mashable.com/article/buidl-hodl/) next! + +[Coil]: https://coil.com/ diff --git a/content/blog/2019/labeling-the-internet-of-value.md b/content/blog/2019/labeling-the-internet-of-value.md new file mode 100644 index 0000000000..68faea6d9e --- /dev/null +++ b/content/blog/2019/labeling-the-internet-of-value.md @@ -0,0 +1,161 @@ +# Labeling the Internet of Value + +_By Rome Reginelli, Documentation Engineer at [Ripple](https://ripple.com/)_ + +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](/references/xrp-ledger-toml/) 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 `xrp-ledger.toml` files](/resources/dev-tools/xrp-ledger-toml-checker/). + + + + +## Why Identify Yourself? + +You may wonder, why share any information publicly at all? Certainly, in a network filled with malicious actors, voluntarily publishing your identity could attract unwanted attention. For the same reason, voluntarily presenting a face to the public can be an act of strength and goodwill. It sets the boundaries and expectations, effectively saying, "This is what I want you to know about me." + +This kind of thing forms the basis of _trusted_ interactions, because _trustless_ interactions with fellow humans are difficult, adversarial, and fraught. A truly trustless world is fundamentally _uncivilized_: a state of nature where might makes right. I've always thought a fascinating insight at the core of the XRP Ledger's design is that a little bit of trust goes a long way. The XRP Ledger's validation mechanism works because participants mutually agree to behave honestly in order to share the benefits of a global ledger, and the system makes it straightforward to verify that, yes, most participants really do behave honestly. By similar logic, technologies and social structures built on top of the XRP Ledger work better when you can verify that people are who they say they are. + +In my case, I'm a Ripple employee who interacts with the XRP community on a regular basis. Among other responsibilities, that means that what I say and do might have an outsized effect on how others view XRP. I want to claim responsibility for my own XRP holdings so that people can see for themselves that I follow my own advice: I own a relatively small amount of XRP directly, and I largely hold it for the long term or use it for testing and experiments. I also have some other motivations for listing my accounts: for a while, an example transaction in the dev portal showed setting the `Domain` field of an account to my personal domain, [mduo13.com](https://mduo13.com/), and people who copied the example did not always change the domain, so there are strange accounts out there with my domain on them. By explicitly claiming the accounts that _are_ mine, I can disclaim ownership of the ones that aren't. + +If you run a validator, that's a great reason to publish an `xrp-ledger.toml` file, too. Right now, [domain verification](/infrastructure/configuration/server-modes/run-rippled-as-a-validator/#6-provide-domain-verification) isn't a fully open, self-service process (an entity like Ripple has to collect and verify the signatures). Following the release of `rippled` 1.3.0, it should become possible for third parties to independently verify that a validator is associated with a particular domain name. Part of that process comes from using the [new domain field of a validator manifest](https://github.com/ripple/rippled/pull/2879/commits/88cb0e5928510d684a894ddf8a4ccc379c09d8fe) and the other part comes from the [`[[VALIDATORS]]` list in the `xrp-ledger.toml` file](/references/xrp-ledger-toml#validators). + + +## Creating the File + +The first step of creating the file is deciding what contents to provide. I decided to provide a little bit of metadata, some information about myself, the accounts I own, and the validator I operate. + +You can see the complete result at . + +### Metadata + +In the `[METADATA]` block, I decided to provide a `modified` field to indicate when I last updated the file, because I expect that I might not update this file often, so others who see it may be able to guess if it's outdated. To get the current time in ISO 8601 format, I opened up my web browser's JavaScript console and typed `(new Date()).toISOString()`. I could have typed the date by hand, but I didn't want to try and figure out the current hour in UTC, so this was easy. + +I chose not to provide an `expires` field because I don't want to force myself to update the document just to update the expiration, and I don't have any specific use case that would require others to get a fresh copy of my information. + +I did add a few comments to the top of the document to explain my unique situation. + +```toml +# mDuo13.com xrp-ledger.toml file +# I am a Ripple employee. I run a validator on my home PC for experimentation. +# For help understanding this file, see: +# https://xrpl.org/xrp-ledger-toml.html + +[METADATA] +modified = 2019-07-12T23:44:52.761Z + +# Q: Why do so many XRP Ledger addresses have "mduo13.com" as their domain? +# +# A: For a long time, the example "AccountSet" transaction in Ripple's +# documentation was a real transaction, me setting my own domain. Many +# users have copied the example and sent it without changing the "Domain" +# field. I don't have any control over those accounts. +``` + +### Principals + +I provided one `[[PRINCIPALS]]` entry, describing myself. I was a bit hesitant about including an email because I don't want to attract too much spam, but spam filtering has gotten better lately so I decided it was worth it in case someone wanted to contact me legitimately about something interesting. + +I decided I'd also like to provide a social media address of some kind. As a fan of decentralized networks, of course I listed my [Mastodon](https://joinmastodon.org/) account. This isn't a field that's defined by the standard, but the open-ended `xrp-ledger.toml` file standard lets you make up your own fields, so I picked a field name and format that seemed fairly informative and went with that. + +The Principals section: + +```toml +[[PRINCIPALS]] +name = "Rome Reginelli" +email = "rome@mduo13.com" +mastodon = "@mDuo13@icosahedron.website" +``` + +### Validators + +I have a `rippled` server that runs on my home computer. I don't keep this server online all the time, but it is configured to operate as a validator when it runs. I provided information on this server mostly as an example of how to provide validator information. Since I only run the one validator, I only have one `[[VALIDATORS]]` stanza. + +The master `public_key` is the most important part; I had it saved from when I initially set up my validator's keys. I added a description just in case someone sees my validator in a list so they can understand that it's not intended to be stable. It runs on my home PC in the United States, so I used the United States' [ISO-3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) code for both country fields. (The spec doesn't say whether it should be uppercase or lowercase, but I'm lazy with my shift key so I left it lowercase.) + +And since my validator follows Ripple's recommended UNL, I listed the URL of that in the `unl` field. Providing this information helps people analyze the topology of the validation network to find risks and improve decentralization. + +The validators section: + +```toml +[[VALIDATORS]] +public_key = "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST" +desc = "My dogfood rippled machine. Not a reliable validator." +network = "main" +owner_country = "us" +server_country = "us" +unl = "https://vl.ripple.com" +``` + +### Accounts + +Finally, the list of accounts. I added an `[[ACCOUNTS]]` entry for each of the XRP Ledger addresses whose keys I have saved. As a result of doing various tests and experiments, I have a few more accounts than a normal person needs, and I honestly don't even remember what some of these were for. I added a description `desc` field to the accounts where I remembered their purpose, most importantly for the "primary" address where I want to receive XRP if, for example, people want to send me tips. I also tagged that one explicitly as being on the main network just to be sure. (Some of my addresses are in use on both the test net and the production network; that's not a good practice to follow, but I'm stuck with it.) + +**Tip:** I love sending XRP tips to people who contribute to the XRP Ledger Dev Portal. If you open a PR to the dev portal, make your XRP Ledger address known and I might just send some XRP your way! You could even just provide your domain if you serve an `xrp-ledger.toml` file with your preferred address there. + +My accounts list: + +```toml +[[ACCOUNTS]] +address = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX" +network = "main" +desc = "Primary address (send XRP here if you want to tip or pay me)" + +[[ACCOUNTS]] +address = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn" +desc = "Testing address (appears in many documentation examples)" + +[[ACCOUNTS]] +address = "r9gyzAVmAtgP8kUYvDaraS65UzWhqSr1Ee" + +[[ACCOUNTS]] +address = "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW" + +[[ACCOUNTS]] +address = "rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH" + +[[ACCOUNTS]] +address = "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n" + +[[ACCOUNTS]] +address = "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v" + +[[ACCOUNTS]] +address = "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC" +``` + + +## Serving the File + +With the contents decided, I had to serve the file from my domain. I already have a working HTTPS configuration using [Let's Encrypt](https://letsencrypt.org/), and my top level site is a (rather old) PHP blog, so I could just create a `.well-known/` folder on the web server and transfer the file over. + +That left [CORS Setup](/references/xrp-ledger-toml#cors-setup) as the only remaining step. Since I'm using a shared webhost, I don't have access to the server-level config file, but I do have permission to add `.htaccess` files. I don't want my entire site (or even the entire `.well-known` folder) to be available for cross-origin requests, so I was able to add a specific rule for just the `xrp-ledger.toml` file using an `.htaccess` file with a `` stanza: + +```apache +AddType application/toml .toml + + Header set Access-Control-Allow-Origin "*" + +``` + +I also added a general purpose rule to serve files ending in the `.toml` extension using the content type "application/toml", which is the recommended MIME type for TOML files. This isn't a requirement for serving the file successfully, but it does stop Firefox from reporting an XML parsing error. + +I copied that same file to the `.well-known/` folder on my webserver. A quick test confirmed that I was able to fetch the contents with an AJAX call, so I knew CORS was set up correctly, but I wasn't sure that my file's contents were formatted just right... so I created a tool to handle that automatically. + + +## New Checker + +The [`xrp-ledger.toml` Checker](/resources/dev-tools/xrp-ledger-toml-checker/) is a new web tool that fetches a domain's `xrp-ledger.toml` file, parses it, and displays the contents of the standard fields found within. You can test it on your own domain when you set up your `xrp-ledger.toml` file. To see it in action, you can also enter my domain, `mduo13.com`, in the text box. + +The tool is not all-seeing when things go wrong; the browser, by design, does not make it easy for a script to know the difference between a cross-origin request that was blocked and a request that simply failed because it couldn't connect to the domain. Your browser's developer tools (accessible by pressing F12 in Chrome or Firefox on desktop) may provide more information about any failures. + + +## Afterword + +A few things the [`xrp-ledger.toml` Checker](/resources/dev-tools/xrp-ledger-toml-checker/) didn't pick up are no surprise: + +- Not all of my own addresses have the `Domain` field set. I could send [AccountSet transactions](/references/protocol/transactions/types/accountset/) for each of them to configure it, but I rarely use most of those addresses anyway, so I didn't bother. +- Since the checker only displays well-defined standard fields, my Mastodon contact information doesn't show up in the output. That's fine. Maybe if a client application catches on it can add support for displaying various modes of contact. + +In all, the process of setting up an `xrp-ledger.toml` file was more straightforward than I had expected. The syntax is a little more verbose than its predecessor, `ripple.txt`, but it's also great to have an explicit standard, so tools like the checker can pull in a ready-made library and provide an unambiguous reading of the file. It probably would have been more complex if I also had to set up HTTPS for the first time, but fortunately that was a problem I already had solved because it's a good thing to provide regardless. + +I look forward to exploring the other half of the Domain Verification process after `rippled` v1.3.0 is out. diff --git a/content/blog/2019/multisignreserve-enabled.md b/content/blog/2019/multisignreserve-enabled.md new file mode 100644 index 0000000000..6b3d861c83 --- /dev/null +++ b/content/blog/2019/multisignreserve-enabled.md @@ -0,0 +1,27 @@ +# MultiSignReserve is Now Available + +[As previously announced](https://developers.ripple.com/blog/2019/multisignreserve-expected.html), the MultiSignReserve amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/C421E1D08EFD78E6B8D06B085F52A34A681D0B51AE62A018527E1B8F54C108FB) on 2019-04-17. + +## Action Recommended + +If you are already using multi-signing, no changes are necessary to continue using it. Optionally, you can now benefit from the reduced reserve requirements by [replacing your existing SignerList](https://developers.ripple.com/set-up-multi-signing.html) with an identical or updated one. + +If you are not using multi-signing yet, feel free to take this opportunity to [Set Up Multi-Signing](https://developers.ripple.com/set-up-multi-signing.html) with the reduced reserve requirements. + + +## MultiSignReserve Summary + +Reduces the [owner reserve](https://developers.ripple.com/reserves.html#owner-reserves) to 5 XRP counted against your XRP Ledger account when it owns a [multi-signing](https://developers.ripple.com/multi-signing.html) SignerList, regardless of the number of signers. The reserve requirement for previously-created SignerList objects remains unchanged. To reduce the reserve requirement of SignerList objects created before this amendment was enabled, use a [SignerListSet transaction](https://developers.ripple.com/signerlistset.html) to replace the SignerList after this amendment has been enabled. (The replacement can be identical to the previous version.) + +Before this amendment, the owner reserve for a SignerList ranged from 15 to 50 XRP, depending on the number of signers in the list. + + +## Learn, ask questions, and discuss +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://ripple.com/dev-blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/multisignreserve-expected.md b/content/blog/2019/multisignreserve-expected.md new file mode 100644 index 0000000000..230ce778a7 --- /dev/null +++ b/content/blog/2019/multisignreserve-expected.md @@ -0,0 +1,28 @@ +# The MultiSignReserve Amendment is Expected 2019-04-17 + +The MultiSignReserve amendment to the XRP Ledger, introduced in [`rippled` v1.2.0](https://github.com/ripple/rippled/releases/tag/1.2.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/E394F1DA552936FD26E5BBE6BF57B27869CA897EB4AF082AD22FFE7A259FED2B). 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. + +## MultiSignReserve Summary + +Reduces the [owner reserve](https://developers.ripple.com/reserves.html#owner-reserves) counted against your XRP Ledger account when it owns a [multi-signing](https://developers.ripple.com/multi-signing.html) SignerList. + +Without this amendment, the owner reserve for a SignerList ranges from 15 to 50 XRP, depending on the number of signers in the list. + +With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, regardless of the number of signers. The reserve requirement for previously-created SignerList objects remains unchanged. To reduce the reserve requirement of SignerList objects created before this amendment was enabled, use a [SignerListSet transaction](https://developers.ripple.com/signerlistset.html) to replace the SignerList after this amendment has been enabled. (The replacement can be identical to the previous version.) + +## No Action Required + +The MultiSignReserve amendment is supported by `rippled` versions 1.2.0 and later, which have been required on the production XRP Ledger since [fix1578 became enabled](https://developers.ripple.com/blog/2019/fix1578-enabled.html) on 2019-03-23. [Version 1.2.3](https://developers.ripple.com/blog/2019/rippled-1.2.3.html) is recommended. + +If you are already using multi-signing in production, no changes are necessary to continue to use multi-signing after this amendment becomes enabled. If the amendment becomes enabled, you can benefit from the lowered reserve requirement for your account's SignerList by updating or replacing the SignerList. (The replacement can be identical to the previous version.) + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) +* [The Ripple Dev Blog](https://ripple.com/dev-blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2019/rippled-1.2.0.md b/content/blog/2019/rippled-1.2.0.md new file mode 100644 index 0000000000..aa350b6690 --- /dev/null +++ b/content/blog/2019/rippled-1.2.0.md @@ -0,0 +1,227 @@ +# Introducing XRP Ledger (rippled) version 1.2.0 + +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](https://developers.ripple.com/known-amendments.html#multisignreserve) Amendment, which reduces the reserve requirement associated with signer lists for [Multisign](https://developers.ripple.com/set-up-multi-signing.html). This release also includes incremental improvements to the code that handles offers in the decentralized exchange ([fixTakerDryOfferRemoval](https://developers.ripple.com/known-amendments.html#fixtakerdryofferremoval) and [fix1578](https://developers.ripple.com/known-amendments.html#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. + + + +## Action Required + +**If you operate an XRP Ledger server,** then you should upgrade to version 1.2.0 by Wednesday, 2019-02-27, to ensure service continuity. + +### Impact of Not Upgrading + +Ripple expects the **MultisignReserve**, **fixTakerDryOfferRemoval**, and **fix1578** amendments to become enabled no earlier than Wednesday, 2019-02-27. When this happens, if you are not running release 1.2.0 or greater, your server will become [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +If the **MultisignReserve**, **fixTakerDryOfferRemoval**, and **fix1578** amendments do not become enabled, then your XRP Ledger server will not become amendment blocked and should continue to operate. + +### Upgrading + +On supported platforms, see the [instructions on updating `rippled`](https://developers.ripple.com/install-rippled.html). + +- The SHA-256 for the RPM is: `a6982002a5e7c3abb0078e9c986e4c28c8310ca67defa5f74a1b3581cc9bc0a4` + +- The SHA-256 for the source RPM is: `1927e5411619cc66170730342f1a7c38f6eafae8c4246d68e24cc0ad4fd62b9e` + +For other platforms, please compile version 1.2.0 from source. + +* [Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) + +* [macOS](https://developers.ripple.com/build-run-rippled-macos.html) + +* [Other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + + commit 7779dcdda00ea61a976cf5f387bc1f3bb4ebbfdd + Author: Mike Ellery + Date: Tue Feb 12 16:41:03 2019 -0800 + + Set version to 1.2.0 + +## Network Update + +The Ripple technical operations team plans to deploy version 1.2.0 to all XRP Ledger servers under its operational control, including private clusters, starting at 2:00 PM PST on Wednesday, 2019-02-13. At that time, Ripple plans to start voting in favor of the **fix1578** amendment. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +On behalf of the XRP Community, Ripple would like to thank Guido Vranken and Aaron Hook, for their research effortsand for responsibly disclosing the issues they discovered. As always, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit[ https://ripple.com/](https://ripple.com/bug-bounty/)[bug-bounty](https://ripple.com/bug-bounty/)[/](https://ripple.com/bug-bounty/). + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **As of XRP Ledger version 1.2.0, Boost 1.67.0 is required for all platforms.** + +## 1.2.0 Change Log + +### New and Updated Features + +* Enhance /crawl API endpoint with local server information ([#2823](https://github.com/ripple/rippled/pull/2823)) + +* Report duration in current state ([#2772](https://github.com/ripple/rippled/pull/2772)) + +* Allow servers to detect transaction censorship attempts ([#2700](https://github.com/ripple/rippled/pull/2700)) + +* Add RPC command shard crawl ([#2697](https://github.com/ripple/rippled/pull/2697)) + +* Default ledger_entry by index to return JSON, not hex ([#2713](https://github.com/ripple/rippled/pull/2713)) + +* Add support for Ed25519 seeds encoded using ripple-lib ([#2734](https://github.com/ripple/rippled/pull/2734)) + +### New and Changed Amendments + +* Improve error indicators on two transactions ([#2584](https://github.com/ripple/rippled/pull/2584)) + +* Reduce the account reserve for a Multisign SignerList ([#2649](https://github.com/ripple/rippled/pull/2649)) + +* fixTakerDryOfferRemoval Amendment to fix non-removal of dry offers when autobridging ([#2695](https://github.com/ripple/rippled/pull/2695)) + +* Retire the FeeEscalation amendment ([#2730](https://github.com/ripple/rippled/pull/2730)) + +### Config Changes + +* Remove [ips] section from sample config (e5d6f16) + +* "Add zaphod.alloy.ee to default hub config" ([#2807](https://github.com/ripple/rippled/pull/2807)) + +* Load validator list from file: ([#2744](https://github.com/ripple/rippled/pull/2744)) + +* Change conflicting example websocket port ([#2726](https://github.com/ripple/rippled/pull/2726)) + +* Remove outdated example configs. ([#2648](https://github.com/ripple/rippled/pull/2648)) + +### Bug Fixes + +* Improve preferred ledger calculation ([#2784](https://github.com/ripple/rippled/pull/2784)) + +* Account for minimum reserve in potential spend ([#2750](https://github.com/ripple/rippled/pull/2750)) + +* STObject:setType() returns description of error if any ([#2753](https://github.com/ripple/rippled/pull/2753)) + +* Improve RPC error message for fee command ([#2704](https://github.com/ripple/rippled/pull/2704)) + +* Eliminate potential undefined behavior ([#2762](https://github.com/ripple/rippled/pull/2762)) + +* Fix memory leak in Json move assignment operator ([#2747](https://github.com/ripple/rippled/pull/2747)) + +* Use after move fix ([#2752](https://github.com/ripple/rippled/pull/2752)) + +* Use correct manifest cache when loading ValidatorList ([#2745](https://github.com/ripple/rippled/pull/2745)) + +### Other Improvements: + +* Support for boost 1.68 ([#2652](https://github.com/ripple/rippled/pull/2652)) + +* Improve ssl and NIH in cmake ([#2655](https://github.com/ripple/rippled/pull/2655)) + +* Refine json object test for NDEBUG case ([#2656](https://github.com/ripple/rippled/pull/2656)) + +* Use ExternalProject for some third party deps ([#2678](https://github.com/ripple/rippled/pull/2678)) + +* Report fetch pack errors with shards ([#2680](https://github.com/ripple/rippled/pull/2680)) + +* Rollup of small changes ([#2714](https://github.com/ripple/rippled/pull/2714)) + +* Prefer regex to manual parsing in parseURL ([#2763](https://github.com/ripple/rippled/pull/2763)) + +* Remove custom terminate handler ([#2773](https://github.com/ripple/rippled/pull/2773)) + +* Implement missing string conversions for JSON ([#2779](https://github.com/ripple/rippled/pull/2779)) + +* Properly handle the `--rpc_port` command line argument ([#2777](https://github.com/ripple/rippled/pull/2777)) + +* Correct amount serialization comments ([#2790](https://github.com/ripple/rippled/pull/2790)) + +* Reserve correct vector size for fee calculations ([#2794](https://github.com/ripple/rippled/pull/2794)) + +* Improve crawl shard resource usage ([#2805](https://github.com/ripple/rippled/pull/2805)) + +* Ensure no overflow in casts between enums and integral types ([#2814](https://github.com/ripple/rippled/pull/2814)) + +* Upgrade sqlite to 3.26 ([#2818](https://github.com/ripple/rippled/pull/2818)) + +* Include more information LedgerTrie log messages ([#2826](https://github.com/ripple/rippled/pull/2826)) + +* Simplify strHex ([#2668](https://github.com/ripple/rippled/pull/2668)) + +* Add a flag that track whether we've already dispatched ([#2468](https://github.com/ripple/rippled/pull/2468)) + +* Add user defined literals for megabytes and kilobytes ([#2631](https://github.com/ripple/rippled/pull/2631)) + +* TxQ developer docs, and faster ledger size growth ([#2682](https://github.com/ripple/rippled/pull/2682)) + +* Add RPCCall unit tests ([#2685](https://github.com/ripple/rippled/pull/2685)) + +* Remove unused function in AutoSocket.h ([#2692](https://github.com/ripple/rippled/pull/2692)) + +* Report fetch pack errors with shards ([#2680](https://github.com/ripple/rippled/pull/2680)) + +* Improve codecov builds ([#2690](https://github.com/ripple/rippled/pull/2690)) + +* Remove beast::Journal default constructor ([#2691](https://github.com/ripple/rippled/pull/2691)) + +* Add dependency for NuDB ExternalProject ([#2703](https://github.com/ripple/rippled/pull/2703)) + +* Include entire src tree in multiconfig projects ([#2707](https://github.com/ripple/rippled/pull/2707)) + +* Remove unused execinfo.h header ([#2712](https://github.com/ripple/rippled/pull/2712)) + +* Build protobuf as ExternalProject when not found ([#2760](https://github.com/ripple/rippled/pull/2760)) + +* Reset the validator list fetch timer if an error occurs ([#2761](https://github.com/ripple/rippled/pull/2761)) + +* Remove WaitableEvent ([#2737](https://github.com/ripple/rippled/pull/2737)) + +* Cleanup unused Beast bits and pieces ([#2739](https://github.com/ripple/rippled/pull/2739)) + +* Add source filtering for coverage with option to disable ([#2742](https://github.com/ripple/rippled/pull/2742)) + +* Remove unused json_batchallocator.h ([#2743](https://github.com/ripple/rippled/pull/2743)) + +* Inline calls to cachedRead ([#2749](https://github.com/ripple/rippled/pull/2749)) + +* Remove the state file for the random number generator ([#2754](https://github.com/ripple/rippled/pull/2754)) + +* Remove duplicated include ([#2732](https://github.com/ripple/rippled/pull/2732)) + +* CI rpm build fix (7c96bba) + +* Allow rippled to compile with C++17 ([#2718](https://github.com/ripple/rippled/pull/2718)) + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at . + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to the XRP Ledger prior to the release of 1.2.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As the XRP Ledger moves through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/rippled-1.2.1.md b/content/blog/2019/rippled-1.2.1.md new file mode 100644 index 0000000000..d61c0832a0 --- /dev/null +++ b/content/blog/2019/rippled-1.2.1.md @@ -0,0 +1,115 @@ +# Introducing XRP Ledger (rippled) version 1.2.1 + +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](https://developers.ripple.com/partial-payments.html#the-delivered-amount-field) to more responses to simplify the handling of payment or check cashing transactions. + + + +## Action Required + +**If you operate a XRP Ledger server,** then you should upgrade to version 1.2.1 immediately. + +### Impact of Not Upgrading + +Ripple expects the **MultisignReserve**, **fixTakerDryOfferRemoval** and **fix1578** Amendments to become enabled no earlier than Tuesday, 2019-03-12. When this happens, if you are not running release 1.2.0 or greater, your server will become [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +If the **MultisignReserve**, **fixTakerDryOfferRemoval **and** fix1578** Amendments do not become enabled, then your XRP Ledger server will not become Amendment blocked and should continue to operate. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see here: . + +The SHA-256 for the RPM is: `dafe6dcc93252be317c12637850bd1a1c38a7c8f5db25c4f281c079b4ac3db71` + +The SHA-256 for the source RPM is: `699b4b740075ecf72d0ff0ef422e9747745552c4e17c21c28beb48fbb193ba75` + +For other platforms, please compile version 1.2.1 from source. + +* [Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) + +* [macOS](https://developers.ripple.com/build-run-rippled-macos.html) + +* [Other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + +```text +commit a3470c225b2cc9f33021d75757172de62dac70d6 +Author: Nik Bougalis +Date: Sat Feb 23 10:47:59 2019 -0800 + + Set version to 1.2.1 +``` + +## Network Update + +The Ripple technical operations team plans to deploy version 1.2.1 to all XRP Ledger servers under its operational control, including private clusters, starting at 2:00 PM PST on Tuesday, 2019-02-26. At that time, Ripple plans to start voting in favor of the **fix1578** Amendment. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss + +Related documentation is available in the XRP Ledger Dev Portal, including detailed example API calls and web tools for API testing: [https://developers.ripple.com/](https://developers.ripple.com/) + +Other resources: + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **As of XRP Ledger version 1.2.1, Boost 1.67.0 is required for all platforms.** + +## 1.2.1 Change Log + +### Config Changes + +* Make validators opt out of crawl ([b335adb](https://github.com/ripple/rippled/commit/b335adb674ec6042c8d52c3d50fb2e3cec6f5e79)) + +### Bug Fixes + +* Fix a race condition during TMStatusChange handling ([9dbf849](https://github.com/ripple/rippled/commit/9dbf8495eed1f8e862fe69869bba56a694e00815)) + +* Properly transition state to disconnected ([2529edd](https://github.com/ripple/rippled/commit/2529edd2b6d107256170ddcc1045f69a29a0d954)) + +* Display validator status only in response to admin requests ([c6ab880](https://github.com/ripple/rippled/commit/c6ab880c030bb7492002b843247030e15f9b89a6)) + +* Add the delivered_amount to more RPC commands ([c5d215d](https://github.com/ripple/rippled/commit/c5d215d901d25b1ea18bf0e96529799b1b5158cc)) + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at . + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.2.1: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger moves through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/rippled-1.2.2.md b/content/blog/2019/rippled-1.2.2.md new file mode 100644 index 0000000000..a40f396685 --- /dev/null +++ b/content/blog/2019/rippled-1.2.2.md @@ -0,0 +1,99 @@ +# Introducing XRP Ledger (rippled) version 1.2.2 + +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. + + + +## Action Required + +**If you operate a XRP Ledger server,** then you should upgrade to version 1.2.2 immediately. + +### Impact of Not Upgrading + +If you operate a rippled server, but do not upgrade to 1.2.2 as soon as possible, then your server may experience restarts or outages. + +Additionally, the **MultisignReserve**, **fixTakerDryOfferRemoval** and **fix1578** Amendments are expected to become enabled no earlier than Wednesday, 2019-03-20. When this happens, if you are not running [release 1.2.0](https://developers.ripple.com/blog/2019/rippled-1.2.0.html) or greater, your server will become [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +If the **MultisignReserve**, **fixTakerDryOfferRemoval** and **fix1578** Amendments do not become enabled, then your XRP Ledger server will not become amendment blocked. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see here: [Install `rippled`](https://developers.ripple.com/install-rippled.html) + +The SHA-256 for the RPM is: `e846e864c273593fcfbc9b1f21c7f2cf236454fd88ab8624446f446e9df0a447` + +The SHA-256 for the source RPM is: `c8a67054d81fc5d7dfba5b4ebe630f44507886da418c5ba6fb7a245e9d78cd01` + +For other platforms, please compile version 1.2.2 from source. + +* [Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) + +* [macOS](https://developers.ripple.com/build-run-rippled-macos.html) + +* [Other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + + commit 0ebed961424d9757f5d26ce7e8b3e5e8d83eb239 + Author: seelabs + Date: Mon Mar 4 11:45:12 2019 -0500 + + Set version to 1.2.2 + +## Network Update + +The Ripple technical operations team plans to deploy version 1.2.2 to all XRP Ledger servers under its operational control, including private clusters, starting at 2:00 PM PST on Wednesday, 2019-03-06. At that time, Ripple plans to start voting in favor of the **fix1578** Amendment. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit[ https://ripple.com/](https://ripple.com/bug-bounty/)[bug-bounty](https://ripple.com/bug-bounty/)[/](https://ripple.com/bug-bounty/). + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **As of XRP Ledger version 1.2.2, Boost 1.67.0 is required for all platforms.** + +## 1.2.2 Change Log + +### Bug Fixes + +* Fix a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly. ([4c03b3f](https://github.com/ripple/rippled/commit/4c06b3f86fdca59cc1fb14d0730c6de14662bcff)) + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at . + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (`rippled`) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.2.2: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger moves through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/rippled-1.2.3.md b/content/blog/2019/rippled-1.2.3.md new file mode 100644 index 0000000000..2d523e6100 --- /dev/null +++ b/content/blog/2019/rippled-1.2.3.md @@ -0,0 +1,101 @@ +# Introducing XRP Ledger (rippled) version 1.2.3 + +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](https://www.owasp.org/index.php/Null_Dereference), which could result in the server process being terminated by the operating system. + + + +## Action Required + +If you operate an XRP Ledger server, then you should **upgrade to version 1.2.3 immediately.** + +### Impact of Not Upgrading + +If you operate a rippled server, but do not upgrade to 1.2.3 immediately, then your server may experience restarts or outages. + +Additionally, if you are not already running [release 1.2.0](https://developers.ripple.com/blog/2019/rippled-1.2.0.html) or greater, then your server is [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see [Install rippled](https://developers.ripple.com/install-rippled.html). + +The SHA-256 for the RPM is: `8e6c5727c359d0c1d8a7235a149b18ddbad63d18de127b9370c335b1e4bc6775` + +The SHA-256 for the source RPM is: `b2664e7e47af0ceefbea3619505f37426f026146690a13565f381c8cb7ca25a6` + +For other platforms, please compile version 1.2.3 from source. + +* [Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) + +* [macOS](https://developers.ripple.com/build-run-rippled-macos.html) + +* [Other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + + commit 0329ee236ffe2d7658bbdd1d970bb2af6337a941 + Author: seelabs + Date: Thu Mar 28 16:38:43 2019 -0400 + + Set version to 1.2.3 + +## Network Update + +The Ripple technical operations team plans to deploy version 1.2.3 to all XRP Ledger servers under its operational control, including private clusters, starting at 2:00 PM PST on Tuesday, 2019-04-02. At that time, Ripple plans to also start voting in favor of the **MultisignReserve** Amendment. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Known Issues + +Version 1.2.3 has a bug that can cause the server to stop checking for updates to its configured validator list sites. If this happens, your server may lose sync with the network when its current validator list file expires. You can restore sync by restarting the rippled service. (This issue is related to the issues fixed in the [version 1.1.1 release](https://developers.ripple.com/blog/2018/rippled-1.1.1.html).) A fix for this issue is forthcoming. + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **For XRP Ledger version 1.2.3, Boost 1.67.0 is required for all platforms.** (This is unchanged from versions 1.2.0, 1.2.1, and 1.2.2.) + +## 1.2.3 Change Log + +### Bug Fixes + +* Better error checking in CachedViewImpl::read ([b347afcc5b](https://github.com/ripple/rippled/commit/b347afcc5b4c5228a425508d96e99b85cac7a1d7)) + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at . + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.2.3: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger moves through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/rippled-1.2.4.md b/content/blog/2019/rippled-1.2.4.md new file mode 100644 index 0000000000..c28c5cdfdf --- /dev/null +++ b/content/blog/2019/rippled-1.2.4.md @@ -0,0 +1,100 @@ +# Introducing XRP Ledger (rippled) version 1.2.4 + +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. + + + +## Action Required + +If you operate an XRP Ledger server, then you should **upgrade to version 1.2.4 immediately.** + +### Impact of Not Upgrading + +If you operate a rippled server, but do not upgrade to 1.2.4 immediately, then your server may experience restarts or outages and may be unable to retrieve updated validator lists from the publishers that you have configured. + +Additionally, if you are not already running [release 1.2.0](https://developers.ripple.com/blog/2019/rippled-1.2.0.html) or greater, then your server is [amendment blocked](https://developers.ripple.com/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; + +* Cannot submit or process transactions; + +* Cannot participate in the consensus process; + +* Cannot vote on future amendments; and + +* Could rely on potentially invalid data. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see [Install rippled](https://developers.ripple.com/install-rippled.html). + +The SHA-256 for the RPM is: `63f33ca0fbd089a4d1bf5ca4f5c925087bb33209ccc0f29eba04a8e5de0c501a` + +The SHA-256 for the source RPM is: `9b38ee937d19c57d6461d7ed47ae477893ed7d9e23bfc4d867291d5e3b86b7cb` + +For other platforms, please compile version 1.2.4 from source. + +* [Ubuntu Linux](https://developers.ripple.com/build-run-rippled-ubuntu.html) + +* [macOS](https://developers.ripple.com/build-run-rippled-macos.html) + +* [Other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + + commit 834f545498c0ff8fe22eb4648fe4534dea2ab965 + Author: Nik Bougalis + Date: Mon Apr 15 12:38:52 2019 -0700 + Set version to 1.2.4 + + +## Network Update + +The Ripple technical operations has deployed version 1.2.4 to all XRP Ledger servers under its operational control, including private clusters. + + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://developers.ripple.com/), including detailed example API calls and web tools for API testing. + +Other resources: + +* The Ripple Forum (_Disabled._ Formerly `forum.ripple.com`) + +* [The Ripple Dev Blog](https://developers.ripple.com/blog/) + +* Ripple Technical Services: + +* [XRP Chat Forum](http://www.xrpchat.com/) + +## Other Information + +### Bug Bounties and Responsible Disclosures + +Ripple welcomes reviews of the **XRP Ledger** open source codebase and urge reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Boost Compatibility + +When compiling XRP Ledger from source, you must use a compatible version of the Boost library. **For XRP Ledger version 1.2.4, Boost 1.67.0 is required for all platforms.** (This is unchanged from versions 1.2.0 through 1.2.3.) + +## 1.2.4 Change Log + +### Bug Fixes + +- Corrects a technical flaw that improves the way that shard crawl requests are verified and routed +- Fixes an issue where the component that would check for updated validator list could become blocked for an indefinite amount of time by imposing a 20 second timeout + + +## Contributions + +We welcome external contributions to the XRP Ledger codebase. Please submit a pull request with your proposed changes on the GitHub project page at . + +On behalf of the XRP Community, Ripple would like to thank those who have contributed to the development of the XRP Ledger (rippled) open source code, whether they did so by writing code, running the software, reporting issues, discovering bugs or offering suggestions for improvements. + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.2.4: + +Aishraj Dahal, Alex Chung, Alex Dupre, Andrey Fedorov, Arthur Britto, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, David Grogan, David Schwartz, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Evan Hubinger, Frank Cash, Howard Hinnant, Jack Bond-Preston, jatchili, Jcar, Jed McCaleb, Jeff Trull, Joe Loser, Johanna Griffin, Josh Juran, Justin Lynn, Keaton Okkonen, Lieefu Way, Luke Cyca, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul and Yana Novikova. + +As XRP Ledger moves through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/rippled-1.3.1.md b/content/blog/2019/rippled-1.3.1.md new file mode 100644 index 0000000000..2513c9d14f --- /dev/null +++ b/content/blog/2019/rippled-1.3.1.md @@ -0,0 +1,186 @@ +# Introducing XRP Ledger (rippled) version 1.3.1 + +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](https://xrpl.org/manage-the-rippled-server.html). + +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. + + + + +## Installing or Updating `rippled` +The installation instructions on supported platforms have changed for `rippled` 1.3.x. + +- For all new installs, see [Install `rippled`](https://xrpl.org/install-rippled.html). +- On Red Hat Enterprise Linux 7 or CentOS 7, if you have **automatic updates** enabled, the updates should work successfully. For more information or for manual update instructions, see the [Migration Instructions for RHEL 7 / CentOS](https://xrpl.org/rippled-1-3-migration-instructions.html#migration-on-centos-or-red-hat-enterprise-linux-rhel). +- On Ubuntu Linux (16.04, 18.04, or newer), native (APT) packages are now available. If you already have `rippled` installed using the previous method (installing RPMs with Alien), see [Migration Instructions for Ubuntu Linux](https://xrpl.org/rippled-1-3-migration-instructions.html#migration-on-ubuntu-linux) for steps to migrate to the new, native packages. Additionally, it is now possible to enable [automatic updates](https://xrpl.org/update-rippled-automatically-on-linux.html) on Ubuntu. +- Debian 9 Stretch is now a supported operating system. See [Installation on Ubuntu or Debian Linux](https://xrpl.org/install-rippled-on-ubuntu.html) for instructions. +- For other platforms, please [compile from source](https://github.com/ripple/rippled/tree/develop/Builds/). + - Step-by-step instructions for compiling `rippled` are also available for [macOS](https://xrpl.org/build-run-rippled-macos.html) and [Ubuntu](https://xrpl.org/build-run-rippled-ubuntu.html). + + +## Summary of Changes + +The `rippled` 1.3.1 release introduces several new features and overall improvements to the codebase, including the `fixMasterKeyAsRegularKey` amendment, code to adjust the timing of the consensus process and support for decentralized validator domain verification. The release also includes miscellaneous improvements including in the transaction censorship detection code, transaction validation code, manifest parsing code, config file parsing code, log file rotation code, and in the build, continuous integration, testing and package building pipelines. + +**New and Updated Features** + +- The `fixMasterKeyAsRegularKey` amendment which, if enabled, will correct a technical flaw that allowed setting an account's regular key to the account's master key. +- Code that allows validators to adjust the timing of the consensus process in near-real-time to account for connection delays. +- Support for decentralized validator domain verification by adding support for a "domain" field in manifests. + +**Bug Fixes** + +- Improve ledger trie ancestry tracking to reduce unnecessary error messages. +- More efficient detection of dry paths in the payment engine. Although not a transaction-breaking change, this should reduces spurious error messages in the log files. +- Improved handling of deadlock conditions. + +### Test Net + +This release is currently live on the [XRP Ledger Test Net](https://xrpl.org/xrp-test-net-faucet.html), with the `fixMasterKeyAsRegularKey` amendment active. To connect your server to the test net, please upgrade to version 1.3.1 immediately. + +## Upgrading + +On supported platforms, see the [instructions on updating rippled](https://xrpl.org/install-rippled.html). + +| Package Type | Platform | Link | SHA-256 | +|--------------|---------------|------|:-------:| +| RPM | Linux x86-64 | [rippled-1.3.1-1.el7.x86_64.rpm](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.3.1-1.el7.x86_64.rpm) | `98ffea13716c3b37472d75cbb25870bfb6a7ee2360fe89a2b86833774174b370` | +| DEB | Linux x86-64 | [rippled_1.3.1-1_amd64.deb](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.3.1-1_amd64.deb) | `3ecd391ba12f69060851952cef8ee1079a6f5e22ecb784bf05f50ef8f294aa92` | + +### Git commit + +When compiling from source, the first log entry should be the change setting the version: + +```text +commit e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236 +Author: Manoj doshi +Date: Wed Jul 24 15:21:56 2019 -0700 + + Set version to 1.3.1 +``` + +### Commits + +- [`e1adbd7dd`](https://github.com/ripple/rippled/commit/e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236) Set version to 1.3.1 +- [`355a7b04a`](https://github.com/ripple/rippled/commit/355a7b04a8e8abeea108af82246449859ea9fb7e) Add a LogicError when a deadlock is detected +- [`d3ee0df93`](https://github.com/ripple/rippled/commit/d3ee0df93ad5d2f12e44af9f652cc39939f7445e) Add links to in-repo build-instructions +- [`7c24f7b17`](https://github.com/ripple/rippled/commit/7c24f7b1706dd464152ca3551c5775f90430f3e8) Improve logging during process startup. +- [`a3060516c`](https://github.com/ripple/rippled/commit/a3060516c6ffedb2ca6e4e129bd40a26068f1371) Improve package build pipeline +- [`caa5c9e22`](https://github.com/ripple/rippled/commit/caa5c9e2232ff1eee1d0c61907283649e48e6fbc) Set version to 1.3.0 +- [`846538304`](https://github.com/ripple/rippled/commit/846538304fa9ddee17e9baa196c98d6649f06b13) Set version to 1.3.0-rc2 +- [`7b7e3b675`](https://github.com/ripple/rippled/commit/7b7e3b6750028d25bdfd390150d5bbe4743b36ef) Return WS error on closure when balance threshold exceeds +- [`a988b3224`](https://github.com/ripple/rippled/commit/a988b3224fa898523e94769b4b518e808aa1eb90) Use NuDB context with backends +- [`89b3bf079`](https://github.com/ripple/rippled/commit/89b3bf07960a0980ee5de448333290f33bdb5871) Stabilize RPC error code values: +- [`6d8988b78`](https://github.com/ripple/rippled/commit/6d8988b78a0b07030d833a10e46f373810a26944) Improve handling of revoked manifests: +- [`3acbd84f1`](https://github.com/ripple/rippled/commit/3acbd84f1ddeed747e7518c4c48787f6918a8f84) Set proper system openssldir in package build +- [`45403b877`](https://github.com/ripple/rippled/commit/45403b877f876dfc8daf496be0e1c74d8adbbcd4) Set version to 1.3.0-rc1 +- [`f17d9bc42`](https://github.com/ripple/rippled/commit/f17d9bc42143e9ae0c7bc1fb171a4a00290a0299) Set version to 1.3.0-b6 +- [`ba2714fa2`](https://github.com/ripple/rippled/commit/ba2714fa22efdd7101afacf47f07e16281c1895f) Make protocol message counters more granular: +- [`2c4b3d515`](https://github.com/ripple/rippled/commit/2c4b3d515d6aa3a4ae91986196f15e0cd212c4df) Trim whitespace for all config lines +- [`59973a435`](https://github.com/ripple/rippled/commit/59973a435ec01e1740b71ac2e21d94a5f80f5fc6) Add beast/cxx17 to install set +- [`93232ec7d`](https://github.com/ripple/rippled/commit/93232ec7dfb4d47ba8552ad01d2f18cab63c53d8) Add logrotate config to rpm/deb pkgs +- [`efa926676`](https://github.com/ripple/rippled/commit/efa926676c1b63fddb88f7686fb3e6edc26b169c) Set version to 1.3.0-b5 +- [`dc24748c2`](https://github.com/ripple/rippled/commit/dc24748c24cc2ca8412735a895c3d517bd97a7f5) Improve locking of PeerImp member variables +- [`f8365f500`](https://github.com/ripple/rippled/commit/f8365f5009c1c5b49ab3cb499bc3eb08156bc515) Add JsonOptions enum class to contain options passed to getJSON methods +- [`c2138c4e8`](https://github.com/ripple/rippled/commit/c2138c4e8814b563d37c3f4fcc998be8f25c9208) Fix Docker error about "FROM" macro usage +- [`bfad96dbb`](https://github.com/ripple/rippled/commit/bfad96dbb99fffd8dde01a4db40f6f148fbd9b47) Force snappy compression for RocksDB (remove option): +- [`0ef6d9f9a`](https://github.com/ripple/rippled/commit/0ef6d9f9a0cb192a260ba94fb6e4240c662664bb) Add slack notify for approvals, remove old RPM build +- [`c1a1cfe55`](https://github.com/ripple/rippled/commit/c1a1cfe5500deec742d2cf17d6d2ce3afe3e868a) Pkgbld - Make approval blocking, add slack summary message +- [`773dcd1d4`](https://github.com/ripple/rippled/commit/773dcd1d488bf70c205196176a216e0e49ca636e) Modernize base_uint: +- [`de99e79bf`](https://github.com/ripple/rippled/commit/de99e79bf1e55f198fd03fc5a0cfa6c13c45ca4a) Fix SNTPClock shutdown +- [`e83d367f4`](https://github.com/ripple/rippled/commit/e83d367f49cceb4b5f28830fb1965a5978744450) Set version to 1.3.0-b4 +- [`aa76b382a`](https://github.com/ripple/rippled/commit/aa76b382afce98927e122cac8ed77f1b3a67563e) Document IPv6 usage in sample config: +- [`595b7b194`](https://github.com/ripple/rippled/commit/595b7b194c0f587b2f3007017875026c761818f7) Improve locking: +- [`5f908ba87`](https://github.com/ripple/rippled/commit/5f908ba870446f19f9f78ad84008a146f93dca41) Make some locks more granular: +- [`adc1b8a36`](https://github.com/ripple/rippled/commit/adc1b8a36b723e5be30e6fe7b4a61b07f4a59fb6) Update package build env to boost 1.70 +- [`73c6e47e8`](https://github.com/ripple/rippled/commit/73c6e47e8a56f643e7e2c5cb1b9fe6efd8d1294c) Use local rippled core lib during pkg build +- [`3a780f80f`](https://github.com/ripple/rippled/commit/3a780f80f17429928e5305516662f260a12c534b) Remove repo package check from update script +- [`c78404e23`](https://github.com/ripple/rippled/commit/c78404e233268d4983e41b7ceefaec101accdf5a) Pause for lagging validators. +- [`79a0cb096`](https://github.com/ripple/rippled/commit/79a0cb096b1ec86fe40367e6ccb61f4a42fa15db) Payment paths with a zero output step are dry (RIPD-1749): +- [`6f9e8dc72`](https://github.com/ripple/rippled/commit/6f9e8dc72033a2f92c68f9c9c0dcf5657b8b40e1) Support Boost 1.70: +- [`b39b0fef3`](https://github.com/ripple/rippled/commit/b39b0fef395d5851b3df4e0e74e939f06bf5fddc) Get names of transactions and ledger types from jss +- [`be139d9bd`](https://github.com/ripple/rippled/commit/be139d9bde99b62ba483aa8ead05e572b5577b77) Add some missing items to help command list: +- [`c6d82c722`](https://github.com/ripple/rippled/commit/c6d82c722b0d2bc66ce9c40f0e0158ac84176b75) Configure build+test matrix for GitLab CI: +- [`0c20e2eb8`](https://github.com/ripple/rippled/commit/0c20e2eb8b33e45b35628ff0a721c609624c6719) Refine parseUrl regular expression (RIPD-1708): +- [`63eeb8d73`](https://github.com/ripple/rippled/commit/63eeb8d7342065098eb701659493eea87b303b84) Use recursive remove and clean for apt (OPS-508) +- [`5214b3c1b`](https://github.com/ripple/rippled/commit/5214b3c1b09749420ed0682a2e49fbbd759741e5) Set version to 1.3.0-b3 +- [`5f7a61f04`](https://github.com/ripple/rippled/commit/5f7a61f040546057935fcf6222ebf0ba0609584f) Report a peer's public key and IP address in log messages (fixes #2675) +- [`c5a938de5`](https://github.com/ripple/rippled/commit/c5a938de551b24d5df505d4276120e480fb7d828) Disallow using the master key as the regular key: +- [`9372a587e`](https://github.com/ripple/rippled/commit/9372a587e431293e491a2ec1939e4e6ce9cd65e1) Request RocksDB PORTABLE build option +- [`948e724df`](https://github.com/ripple/rippled/commit/948e724dff5e05d1168de47296a0af3d3c37e4c5) Improvements to pkg CI pipeline: +- [`06faf2bd5`](https://github.com/ripple/rippled/commit/06faf2bd5b58ad0f6f5e1ec3d7127b439aab5fe5) Improve exit and test failure handling in CI +- [`1dd81c04f`](https://github.com/ripple/rippled/commit/1dd81c04f33436dbf823dfc764c727a06023ba75) Improve jemalloc build config: +- [`56dbf70c3`](https://github.com/ripple/rippled/commit/56dbf70c3c43c2b50091da76c3578430266991cc) Improve windows build README +- [`f8a4ac6ad`](https://github.com/ripple/rippled/commit/f8a4ac6ad7db5824941e5d710c19fc55aab977d5) Use optimized OpenSSL implementations when possible +- [`61bd06177`](https://github.com/ripple/rippled/commit/61bd06177ffe425184f4a3514094555817944cdb) Reserve memory before inserting into a flat set +- [`80e535a13`](https://github.com/ripple/rippled/commit/80e535a13c8d988fd8fa438e7ea038540a6c0fb5) Arguments passed to jtx Env::operator() must be invocable: +- [`64b55c0f8`](https://github.com/ripple/rippled/commit/64b55c0f888d6be1e07849563f567f80c487e003) Rename JsonFields.h to jss.h: +- [`afcc4ff29`](https://github.com/ripple/rippled/commit/afcc4ff296546fb59775bae4a6b3ee64cd6b9472) Reduce likelihood of malformed SOTemplate: +- [`57fe197d3`](https://github.com/ripple/rippled/commit/57fe197d3ee63793cbc078bdb444a0a857f7ab04) Remove runtime inference of unrecognized SFields +- [`9279a3fee`](https://github.com/ripple/rippled/commit/9279a3fee7747deb3c41ef37735d6d0b73cae1db) Refactor SField construction: +- [`b6363289b`](https://github.com/ripple/rippled/commit/b6363289bfb57a6674d7d37e7b3790bdf414303d) Use Json::StaticString for field names +- [`8c1123edc`](https://github.com/ripple/rippled/commit/8c1123edc6206c54e6092dbfd78a1e5eb49ca6d8) Merge master (1.2.4) into develop (1.3.0-b2) +- [`fa5785947`](https://github.com/ripple/rippled/commit/fa57859477441b60914e6239382c6fba286a0c26) Set version to 1.3.0-b2 +- [`88cb0e592`](https://github.com/ripple/rippled/commit/88cb0e5928510d684a894ddf8a4ccc379c09d8fe) Allow manifests to include an optional 'domain' field: +- [`e239eed6d`](https://github.com/ripple/rippled/commit/e239eed6de4e9f557558b0eb8933e5bb6872b24f) Remove obsolete code +- [`504b3441d`](https://github.com/ripple/rippled/commit/504b3441ddd87da6f612ba066a105d52bb650580) Apply resource limits to proxied clients: +- [`872478d96`](https://github.com/ripple/rippled/commit/872478d96502f708bd8893d8acf4b61e592a1c7a) Construct ErrorCodes lookup table at compile time +- [`185f2baf7`](https://github.com/ripple/rippled/commit/185f2baf76e5971ccfe6fbce8de44c3f934ab995) Remove unused RPC error codes: +- [`36d675894`](https://github.com/ripple/rippled/commit/36d6758945954fab757b024b2afc8c3a5ad76919) Disallow both single- and multi-signing in RPC (RIPD-1713): +- [`d8c450d27`](https://github.com/ripple/rippled/commit/d8c450d272c8aa41401416c449639dbeff3aa5bb) Remove incorrectly defaulted functions: +- [`8ef5b9bab`](https://github.com/ripple/rippled/commit/8ef5b9bab4c21c23a644add2a8c94b64bc16e600) Make LedgerTrie remove work for truncated history +- [`e6370a648`](https://github.com/ripple/rippled/commit/e6370a6482e5888e79f9528943fbb41952cdc44b) Add dpkg/rpm building capability: +- [`b2170d016`](https://github.com/ripple/rippled/commit/b2170d016a7ece31ca6b12228b2fac9929f11d6c) Update travis dist/tools +- [`5c124f11c`](https://github.com/ripple/rippled/commit/5c124f11c259f19346d2949a2f6dd32b558eb639) Remove the 'rocksdb' subtree +- [`2aed24a55`](https://github.com/ripple/rippled/commit/2aed24a5525b6634a94c2c182c633f59a3c9d734) Build RocksDB by ExternalProject +- [`296469f5f`](https://github.com/ripple/rippled/commit/296469f5fe768b111ae991f54130bd58cdfa91a4) Reduce memory allocations for RCLCensorshipDetector +- [`08371ba2c`](https://github.com/ripple/rippled/commit/08371ba2c4b55541fc8764b75131660632b43876) Improve shard downloader status reporting +- [`56bc2a2ad`](https://github.com/ripple/rippled/commit/56bc2a2adebdee58be61cdaeeb2f8e806eedfc71) Improve SSLHTTPDownloader: +- [`1084dc6dd`](https://github.com/ripple/rippled/commit/1084dc6dd3cb51062632327559aa5c8ce5bc19dc) Set version to 1.3.0-b1 +- [`8023caaa9`](https://github.com/ripple/rippled/commit/8023caaa9742bd32eb18e2b28cdc7849793f298f) Correct example configuration file: +- [`8b9746628`](https://github.com/ripple/rippled/commit/8b97466285255e1da55a2196af5b3b6cd60db6a3) Always use UTC to be timezone-neutral (RIPD-1659) +- [`de1d10253`](https://github.com/ripple/rippled/commit/de1d1025353a41ad8375574b23d3820527705c1e) Allow build to support XCode 10.2 +- [`1e1e8c254`](https://github.com/ripple/rippled/commit/1e1e8c2547a322b8d425f1f982f384374d1953d4) Remove assert that accesses object post-dtor (RIPD-1704) +- [`aa49be65a`](https://github.com/ripple/rippled/commit/aa49be65a12685041b5c235a4c8f1bba6924ae54) Remove conditional check for feature introduced in 0.28.1-b7 +- [`cd820b377`](https://github.com/ripple/rippled/commit/cd820b37779cf2cf5559f1b6087ca65999822c84) Improve the server's PING/PONG logic +- [`8d59ed5b2`](https://github.com/ripple/rippled/commit/8d59ed5b2aefd443d68b862893b865b33223fca7) Remove STValidation::isValid overload +- [`e03efdbe0`](https://github.com/ripple/rippled/commit/e03efdbe0b50522f8fb5e318c8601f070cfa4a26) Remove use of beast's detail::sec_ws_key_type +- [`4f52c2989`](https://github.com/ripple/rippled/commit/4f52c2989c88242d72f1ef439f91aa6df8ac1701) Remove use of beast::detail::is_invocable trait +- [`3fb13233a`](https://github.com/ripple/rippled/commit/3fb13233a985121a122d8ef96ac834737c1a2caf) Provide patch for FindBoost and apply it +- [`9695fd44b`](https://github.com/ripple/rippled/commit/9695fd44bae802e6ad9a6f9a2011e4693e2e5ac4) Support boost 1.69 +- [`1bb32134f`](https://github.com/ripple/rippled/commit/1bb32134f881846bba9b032837c680ad7a036f2d) Remove censorshipMaxWarnings + +## Contributions + +### GitHub +[![GitHub: Stars](https://img.shields.io/github/stars/ripple/rippled.svg)](https://img.shields.io/github/stars/ripple/rippled.svg) +[![GitHub: Watchers](https://img.shields.io/github/watchers/ripple/rippled.svg)](https://img.shields.io/github/watchers/ripple/rippled.svg) + +The public git repository for `rippled` is hosted on GitHub at . + +We welcome contributions, big and small, and invite everyone to join the community +of XRP Ledger developers and help us build the Internet of Value. + +### Credits +The following people contributed directly to this release: + +- [Crypto Brad Garlinghouse](https://github.com/cryptobrad) (cryptobradgarlinghouse@protonmail.com) +- [Ethan MacBrough](https://github.com/ChronusZ) (chronuszed@gmail.com) +- [Edward Hennis](https://github.com/ximinez) (ed@ripple.com) +- [Elliot Lee](https://github.com/intelliot) (github.public@intelliot.com) +- [Howard Hinnant](https://github.com/HowardHinnant) (howard.hinnant@gmail.com) +- [invalidator](https://github.com/invalidator) (9765843+invalidator@users.noreply.github.com) +- [James Fryman](https://github.com/jfryman) (jfryman@ripple.com) +- [Jesper Wallin](https://github.com/zelest) (jesper@ifconfig.se) +- [Joseph Busch](https://github.com/jwbusch) (jbusch@ripple.com) +- [David Scwhartz](https://github.com/JoelKatz) (DavidJoelSchwartz@GMail.com) +- [John Freeman](https://github.com/thejohnfreeman) (jfreeman08@gmail.com) +- Lazaridis (49013958+lazaridiscom@users.noreply.github.com) +- [Manoj Doshi](https://github.com/manojsdoshi) (manoj.s.doshi@gmail.com, mdoshi@ripple.com) +- [Mark Travis](https://github.com/mtrippled) (mtravis@ripple.com) +- [Miguel Portilla](https://github.com/miguelportilla) (miguelportilla@pobros.com) +- [Mike Ellery](https://github.com/mellery451) (mellery451@gmail.com) +- [Mo Morsi](https://github.com/movitto) (mo@morsi.org) +- [Nik Bougalis](https://github.com/nbougalis) (nikb@bougalis.net) +- [Scott Schurr](https://github.com/scottschurr) (scott@ripple.com) +- [Scott Determan](https://github.com/seelabs) (scott.determan@yahoo.com) diff --git a/content/blog/2019/rippled-1.4.0.md b/content/blog/2019/rippled-1.4.0.md new file mode 100644 index 0000000000..2d7d2de882 --- /dev/null +++ b/content/blog/2019/rippled-1.4.0.md @@ -0,0 +1,316 @@ +# Introducing XRP Ledger version 1.4.0 + +**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](https://xrpl.org/reserves.html) in the process. + +The 1.4.0 release also includes improved peer slot management, improved CI integration and package building and support for [C++17](https://en.wikipedia.org/wiki/C%2B%2B17) and [Boost 1.71](https://www.boost.org/users/history/version_1_71_0.html). + +Finally, the 1.4.0 release removes the code for the **SHAMapV2** Amendment, which failed to gain majority support and has been made obsolete by other improvements. + +## Action Required + +**If you operate an XRP Ledger server,** then you should upgrade to XRP Ledger version 1.4.0 by Monday, 2019-12-16, to ensure service continuity. + +### Impact of Not Upgrading + +Ripple expects the **DeletableAccounts** Amendment to become enabled no earlier than Monday, 2019-12-16. When this happens, if you are not running release 1.4.0 or greater, your server will become [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; +* Cannot submit or process transactions; +* Cannot participate in the consensus process; +* Cannot vote on future amendments; and +* Could rely on potentially invalid data. + +If the **DeletableAccounts** Amendment does not become enabled, then your XRP Ledger server will not become Amendment blocked and should continue to operate. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see here: + +- [Install `rippled`](https://xrpl.org/install-rippled.html) + +The SHA-256 hashes for the official packages are as follows: + +| Package | SHA-256 | +|:--------|:--------| +| [Red Hat RPM (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.4.0-1_amd64.deb) | `0a06914cca3b24ace8ab893fbf3af003df9e308501376f86b043e672024f044b` +| [Ubuntu DEB (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.4.0-1.el7.x86_64.rpm) | `0ed0f6e80610ccf786cd35132a32a891cd648d37daab113bebda8c004fd9e881` | + +For other platforms, please compile version 1.4.0 from source. + +* [Build on Ubuntu Linux](https://xrpl.org/build-run-rippled-ubuntu.html) + +* [Build on macOS](https://xrpl.org/build-run-rippled-macos.html) + +* [Build on other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + +```text +commit 06c371544acc3b488b9d9c057cee4e51f6bef7a2 +Author: Nik Bougalis +Date: Mon Nov 25 22:58:03 2019 -0800 + Set version to 1.4.0 +``` + +## Network Update + +The Ripple technical operations team plans to deploy version 1.4.0 to all XRP Ledger servers under its operational control, including private clusters, starting on Monday, 2019-12-02. At that time, Ripple plans to start voting in favor of the **DeletableAccounts** amendment. The deployment is expected to complete within 4 hours. The network should continue to operate during deployment and no outage is expected. + +## Learn, ask questions, and discuss + +Related documentation is available in the XRP Ledger Dev Portal, including detailed example API calls and web tools for API testing: [https://xrpl.org](https://xrpl.org) + +Other resources: + +* [XRP Chat Forum](http://www.xrpchat.com/) + + +## Other Information + +### Bug Bounties and Responsible Disclosures + +As always, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Compilation Requirements & Compatibility + +Starting with version **1.4.0**, compiling the codebase from source on any platform requires a compiler that supports the C++17 ISO standard and version 1.70.0 of the **[Boost](https://www.boost.org/)** C++ libraries. + +## 1.4.0 Change Log + +### New and Updated Features + +* The **DeletableAccounts** amendment which, if enabled, allow users to delete their XRP Ledger accounts and recover some of their base reserve. + +* Support for improved management of peer slots and the ability to add and remove reserved connections without requiring a restart of the server. + +* Tracking and reporting of cumulative and instantaneous peer bandwidth usage. + +* Preliminary support for post-processing historical shards after downloading to index their contents. + +* Reporting the master public key alongside the ephemeral public key in the validation stream [subscriptions](https://xrpl.org/subscribe.html). + +* Reporting consensus phase changes in the server stream [subscription](https://xrpl.org/subscribe.html). + +### Bug Fixes + +* The **fixPayChanRecipientOwnerDir** Amendment which corrects a minor technical flaw that would cause a payment channel to not appear in the recipient's owner directory, which made it unnecessarily difficult for users to enumerate all their payment channels. + +* The **fixCheckThreading** Amendment which corrects a minor technical flaw that caused checks to not be properly threaded against the account of the check's recipient. + +* Respect the `ssl_verify` configuration option in the `SSLHTTPDownloader` and `HTTPClient` classes. + +* Properly update the `server_state` when a server detects a disagreement between itself and the network. + +* Allow Ed25519 keys to be used with the `channel_authorize` command. + +### List of Commits: + +* Use signed artifacts in pkg pipeline ([22ca0041b](https://github.com/ripple/rippled/commit/22ca0041b847c38dd34e67faced7c6b296401619)) + +* Document the minimum GCC version as 7 ([4e8486874](https://github.com/ripple/rippled/commit/4e848687474242580e3770d8a3fd02b15b678b08)) + +* GPG Sign DEB and RPM packages generated by build pipeline ([9e1ccb900](https://github.com/ripple/rippled/commit/9e1ccb900ec72641a86a88e1169ead3f80dfb029)) + +* Ensure permissions for initial config ([e720a6607](https://github.com/ripple/rippled/commit/e720a660769ba58935619981795103167d7fe123)) + +* Make the HTTP response size const ([7be7343e0](https://github.com/ripple/rippled/commit/7be7343e05c685e30ceb45b1f1f66b49fe8c875e)) + +* Reject overlong encodings earlier ([e26dd7bdf](https://github.com/ripple/rippled/commit/e26dd7bdfee46d780452dcd8743802fe5e1e854a)) + +* Don't use set in AccountObjects test ([906b9ae00](https://github.com/ripple/rippled/commit/906b9ae00b5bb7ed9bce0e894ee2a849fdc9e495)) + +* Report consensus phase changes in the server subscription stream ([15c5f9c11](https://github.com/ripple/rippled/commit/15c5f9c1111eeea0743dbd9d9b0028756ff72ade)) + +* Make Env::AppBundle constructor exception safe ([726dd69ab](https://github.com/ripple/rippled/commit/726dd69ab920d0ba6bf84cc30100f54f2f081f6c)) + +* Relax STTx test failure criterion ([cd01502d1](https://github.com/ripple/rippled/commit/cd01502d17d6b674bccad5e0f74f2ac0e00e8c78)) + +* Omit downloader resolve test when it won't fail ([b2317f8b4](https://github.com/ripple/rippled/commit/b2317f8b41e1a61c74117db827d88ff9e1c9e80e)) + +* Allow channel_authorize to use Ed25519 keys ([113167acf](https://github.com/ripple/rippled/commit/113167acf4ec49a6b986f09036dde49153a8d1b1)) + +* Introduce support for deletable accounts ([a3a9dc26b](https://github.com/ripple/rippled/commit/a3a9dc26b4d4f049cf87fb7152f1fcef6697e505)) + +* Add deletion_blockers_only param to account_objects RPC command ([7e7664c29](https://github.com/ripple/rippled/commit/7e7664c29a616da308c13fc9f4aadaf300488fc2)) + +* Switch deadlock detector to steady_clock ([3f45b8c3b](https://github.com/ripple/rippled/commit/3f45b8c3bd97c9cdc9083edd2f27855460b36ffc)) + +* Support for boost 1.71 ([ca6d5798e](https://github.com/ripple/rippled/commit/ca6d5798e9de8d20eacc89bbe6f4a851ac016132)) + +* Add omitted unit tests, cleanup old files ([2110b2409](https://github.com/ripple/rippled/commit/2110b240902dc0a105f4ed80062ef062b1033ea2)) + +* Add option to enable -Wextra for gcc/clang. ([82484e26f](https://github.com/ripple/rippled/commit/82484e26f57719199f67870dc21f10dcf82adb14)) + +* Small bug fixes in BuildLedger.cpp ([ca47583a3](https://github.com/ripple/rippled/commit/ca47583a3bc22c6d088ed0e1269759219ce553eb)) + +* Add metrics for PeerImp to track bandwidth usage ([f4d6b0e1c](https://github.com/ripple/rippled/commit/f4d6b0e1c49fc008932a85df99b404c66e46ab1e)) + +* Include validator's master public key in validation stream ([9196d954](https://github.com/ripple/rippled/commit/9196d9541ae196785df29191865c7244876ecd58)) + +* CI: remove boost from MacOS / Hombrew ([9a5911f94](https://github.com/ripple/rippled/commit/9a5911f94c1ff2f8375ff647ee3ebfa2530b80f6)) + +* Fix startup error with --import ([80acc85e5](https://github.com/ripple/rippled/commit/80acc85e59618f59c4f4ef8210fae93a19153da7)) + +* Fix VS2019 debug build ([8ce1c189f](https://github.com/ripple/rippled/commit/8ce1c189f7c9fd24a24f321cc794d51e4b2381cc)) + +* Remove SHAMap V2 ([7228b2e06](https://github.com/ripple/rippled/commit/7228b2e068b21968acd2723139da1b7060bca036)) + +* Automatically update NodeDB path if changed ([33ab0cd7b](https://github.com/ripple/rippled/commit/33ab0cd7bd1eec167f931134bd2b07de0fc31c20)) + +* Add PayChan to recipient's owner directory ([e33ac1d45](https://github.com/ripple/rippled/commit/e33ac1d45090891bbb38ad96817a96f6106c8583)) + +* Clarify Linux build instructions for configuring ([826cbbc3b](https://github.com/ripple/rippled/commit/826cbbc3bfaab8327d91ac322503600f1ea7ee0a)) + +* Cleanup usage of ScopedUnlock ([d9bb78c8b](https://github.com/ripple/rippled/commit/d9bb78c8b8ca293468aefa653f41b7ac07d44ae1)) + +* Modularize cmake build config ([905f631b7](https://github.com/ripple/rippled/commit/905f631b716d1bbc91caad48b207c8d2e76e5c5b)) + +* Honor SSL config settings for ValidatorSites ([9213c49ca](https://github.com/ripple/rippled/commit/9213c49ca1ac8f0f5acb11ba2a105b15a2f8121f)) + +* Clarify online delete data error message ([a6944be5c](https://github.com/ripple/rippled/commit/a6944be5cfade694df96953fad09e83a55177fbc)) + +* Update operating mode upon network disagreement ([e5b61c9ac](https://github.com/ripple/rippled/commit/e5b61c9ac939342bf30293d6db1c6f56a6d6d88a)) + +* Add Destination to Check threading ([a9a4e2c8f](https://github.com/ripple/rippled/commit/a9a4e2c8fb7f5da0e6770c0f9f3d810dbfb25495)) + +* Fix rand_int assert in shard store ([56eac5c9a](https://github.com/ripple/rippled/commit/56eac5c9a1b1bab95185095fab56ee3368916262)) + +* Log database connection error ([4b1970afa](https://github.com/ripple/rippled/commit/4b1970afa9cad952a90990618ccd1c6dbb8ad39d)) + +* Add shard thread safety ([22c9de487](https://github.com/ripple/rippled/commit/22c9de487a6171c4ed8a48850b328d87c8a3c6bb)) + +* Implement Shard SQLite support ([66fad62e6](https://github.com/ripple/rippled/commit/66fad62e661bc8b8739d109e78c18c8d5002c6e9)) + +* Improve CI and packaging ([008fc515](https://github.com/ripple/rippled/commit/008fc5155af34d832aec4953415f79118eaccc1f)) + +* Disable shadow warning ([06219f115](https://github.com/ripple/rippled/commit/06219f11517e802d625efed49a1becae24ccbe00)) + +* Simplify code using if constexpr ([c2d2ba9f4](https://github.com/ripple/rippled/commit/c2d2ba9f45380afd03ed1359b917e2041794787b)) + +* Replace `from_string_checked` pair return type with `optional` ([1eb3753f2](https://github.com/ripple/rippled/commit/1eb3753f262924879ce79774051f3fbf9582fc5a)) + +* Replace `strUnHex` pair return type with `optional` ([0a256247a](https://github.com/ripple/rippled/commit/0a256247a039c5ca3a2927f1809d362e4b0225e3)) + +* Use structured bindings in some places ([7912ee6f7](https://github.com/ripple/rippled/commit/7912ee6f7b51527e0ff981acc6aebd081e4c7b08)) + +* Replace unordered_map::emplace with insert_or_assign ([9c58f23cf](https://github.com/ripple/rippled/commit/9c58f23cf8419091e34dc622a4221313e3dbd1ba)) + +* Use std::gcd to implement lowestTerms ([9245b0b66](https://github.com/ripple/rippled/commit/9245b0b666a4f1fc4a2524a6872cacfeb9476eb7)) + +* Use [[fallthrough]] in some switch statements ([92925a0af](https://github.com/ripple/rippled/commit/92925a0af6cad2a02a65001985c02e8712e08447)) + +* remove make_Amounts ([70c2e1b41](https://github.com/ripple/rippled/commit/70c2e1b4192aeb64931dd4f12b264c67f117240d)) + +* Use class template argument deduction for locks ([5d1728cc9](https://github.com/ripple/rippled/commit/5d1728cc962be658c423f38df05567a2e168644f)) + +* Replace for_each_arg trick with fold expressions ([4076b6d92](https://github.com/ripple/rippled/commit/4076b6d92e098f0eabfe62aea08502dabc934084)) + +* Fix shadowing variables ([b9e73b485](https://github.com/ripple/rippled/commit/b9e73b4852ad4763b28c230de6153cb1a9fd43d5)) + +* Remove unused member variable ([014df67fe](https://github.com/ripple/rippled/commit/014df67fed72cf83651a3589729da7840641e408)) + +* Build packages with gcc-8 ([014ec021b](https://github.com/ripple/rippled/commit/014ec021bb8365917daadcb96339ff8dc5cc44df)) + +* Fix jenkins/travis CI ([7fa9b91d2](https://github.com/ripple/rippled/commit/7fa9b91d23a76ee9f7cce7083e7fbd00ea81bae4)) + +* Add "sahyadri.isrdc.in" to list of bootstrap nodes ([c04c00d27](https://github.com/ripple/rippled/commit/c04c00d279af8e52decbcbce649ccfd0e4c824a1)) + +* Update README.md ([ef139e8b3](https://github.com/ripple/rippled/commit/ef139e8b3ce23d3965224e67c54923a6ae7f7728)) + +* Warn if the update script is not executed as root ([45c1c3899](https://github.com/ripple/rippled/commit/45c1c38993c3ce19efd6e9f98ddf8512e7471394)) + +* Modernize code and clean up out-of-date or obsolete comments ([1942fee58](https://github.com/ripple/rippled/commit/1942fee58139c6499bb217236c67c584528c629d)) + +* Remove unused TER code from StrandResult ([b3c85e270](https://github.com/ripple/rippled/commit/b3c85e270987edd9683df035c04547880dcbd40d)) + +* Use enums for some parameters in payments ([561942da2](https://github.com/ripple/rippled/commit/561942da23e518cc7e7df218bc46b3d32d6f8cb9)) + +* Enable C++17 ([c217baa36](https://github.com/ripple/rippled/commit/c217baa367a65724808c5df9d157b9a22eb6f563)) + +* Fix incorrect snapShot unsharing ([c699864c8](https://github.com/ripple/rippled/commit/c699864c85664056db0ae2b347130e959966ea3e)) + +* Remove unneeded and unused base classes in insight ([4ff0f482c](https://github.com/ripple/rippled/commit/4ff0f482c34b7a970b8cdac6317b30096bda4b4b)) + +* Enhance AccountTx unit test ([28b942b18](https://github.com/ripple/rippled/commit/28b942b186fcd1fa6ff5dc75a12b676c353d5ec4)) + +* Update appveyor dependencies for boost 1.70 ([4900e3081](https://github.com/ripple/rippled/commit/4900e3081d99768d0218a22cdffc3c8cf9dba647)) + +* Add policy check to FindBoost ([145326c00](https://github.com/ripple/rippled/commit/145326c00c8642d1736d917cad22d5269673102e)) + +* Update to current SOCI HEAD ([c7d90bfdd](https://github.com/ripple/rippled/commit/c7d90bfddd684d38076f9c3b04c713e70e624e36)) + +* Fix io_latency_probe test on CI environments ([bfa84cfca](https://github.com/ripple/rippled/commit/bfa84cfca56c8f7a88ed963ecbeb539185569566)) + +* Set minimum versions for gcc/clang ([cbc6e500b](https://github.com/ripple/rippled/commit/cbc6e500b676849d554b04d992e7226ef903ce76)) + +* Travis CI improvements ([13a4fefe3](https://github.com/ripple/rippled/commit/13a4fefe3466b413d273526c4b0c4d393793ff02)) + +* Add support for reserved peer slots ([87e9ee5ce](https://github.com/ripple/rippled/commit/87e9ee5ce93088d95ffbfa6d8ce01a88fd7491f0)) + +* Fix GitLab CI ([20cc5df5f](https://github.com/ripple/rippled/commit/20cc5df5fe8b0cadb1e6a24767f796b54418fedb)) + +* Fix shard path detection ([9e117b7b3](https://github.com/ripple/rippled/commit/9e117b7b384b541ba083fed5a9b390d8d965e82b)) + +* Move shard store init to Application ([a02d91409](https://github.com/ripple/rippled/commit/a02d91409319b6b924659ce08217f75eb6301c6f)) + +* Remove SQLite Validations table ([c5a95f1eb](https://github.com/ripple/rippled/commit/c5a95f1eb5a5eedc7ece46ad26505209c1703486)) + +## Contributions + +### GitHub + +The public git repository for `rippled` is hosted on GitHub: [https://github.com/ripple/rippled](https://github.com/ripple/rippled) + +We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value. + +### Credits + +The following people contributed directly to this release: + +* Alloy Networks 45832257+alloyxrp@users.noreply.github.com + +* Devon White devon@prometheanlabs.io + +* Edward Hennis ed@ripple.com + +* Elliot Lee github.public@intelliot.com + +* Howard Hinnant howard.hinnant@gmail.com + +* John Freeman jfreeman08@gmail.com + +* John Northrup jnorthrup@ripple.com + +* Joseph Busch jbusch@ripple.com + +* Manoj Doshi mdoshi@ripple.com + +* Mark Travis mtravis@ripple.com + +* Miguel Portilla miguelportilla@pobros.com + +* Mike Ellery mellery451@gmail.com + +* Mo Morsi mo@morsi.org + +* Nik Bougalis nikb@bougalis.net + +* Rome Reginelli rome@ripple.com + +* Scott Schurr scott@ripple.com + +* seelabs scott.determan@yahoo.com + +* Vishwas Patil ivishwas@gmail.com + +* Yusuf Sahin HAMZA yusufsahinhamza@gmail.com + +#### Lifetime Contributors + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.4.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA. + +For a real-time view of all contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: . + +As XRP Ledger continues to move through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2019/secure-development-practices.md b/content/blog/2019/secure-development-practices.md new file mode 100644 index 0000000000..048e2af222 --- /dev/null +++ b/content/blog/2019/secure-development-practices.md @@ -0,0 +1,46 @@ +# Protecting the Ledger: Secure Development Practices + +_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](https://developers.ripple.com/blog/2017/invariant-checking.html), 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. + + + +## Security Audits + +Security reviews are an important component of any security development playbook. Unlike a simple code review, which typically focuses only on changes to the code, security reviews involve a deep and thorough analysis of the codebase with the intent of discovering latent bugs. + +Such audits can take several weeks to plan and several months to complete. On average, we’ve completed almost one security review every two years, although not every review covers every section of the codebase. + +In broad terms, previous audits have not identified any serious issues with the codebase, although some low severity, like resource leaks, were discovered and [fixed](https://github.com/ripple/rippled/commit/b5dbd7942f8896367e65cbc8f58e9bfbce81d953); furthermore, as a result of these audits we added [enhanced warnings about brain-wallets](https://github.com/ripple/rippled/commit/ab8102f927e7db5fee19b453206249f446ab9c70) and deployed [secure memory zeroization](https://github.com/ripple/rippled/commit/39f91351046bdff30b153f8442b562a3abe0ac82) more broadly throughout the codebase. Overall, however, the consensus has been that the software is “well-written and designed” and that the developers have “taken time to carefully consider the implementation.” + +In 2018 we engaged with [Guido Vranken](https://twitter.com/guidovranken), a renowned security analyst, who spent several months examining the code base. His excellent and well-researched reports helped us to improve handling of [malformed](https://github.com/ripple/rippled/commit/ea76103d5f522ae3ce4b27155e194faab99e379e) or [incorrect](https://github.com/ripple/rippled/commit/ba9ca1378e0c93c448ab7f73e3246959aaa67783) input data and improve the overall quality and robustness of the code in the face of malicious user input. Guido also supplied us with a suite of tools that we will integrate into our CI/CD process, that will help us to detect a broader set of errors in an automated fashion. + +During 2019, we are going to continue engaging with experts like Guido and leading security consulting firms as we work to conduct a thorough and comprehensive assessment of the codebase. Unlike previous assessments which were not made public, we intend to request that the reviewers publicly release their analysis as part of our commitment to transparency and quality. + +## Bounty Hunters + +Of course, there are plenty of hugely talented individuals who don’t work for a large, established firm and who, unlike Guido, may not be well-known in this space. Perhaps they’re freelancing, analyzing open source software for bugs in their free time or just starting out. Maybe they just stumbled on a bug in the process of evaluating the codebase. Regardless, it makes sense to engage with them as well and to reward them for their efforts. That’s where [Ripple’s Bug Bounty program](https://ripple.com/bug-bounty/) comes into play. + +Bug bounty programs must, at first, have seemed an odd practice. After all, why pay strangers to break code? Over time, however, they have proven invaluable, by incentivizing and encouraging responsible disclosure and have become an integral part of any vulnerability management program. At Ripple, our program has been in place for several years already and it has attracted individuals of the highest caliber who have carefully analyzed the code and produced highly detailed bug reports. In fact, during 2018 we paid over $50,000 in bug bounties. + +## Improved Threat Models & Processes + +Threat models are another important part of secure software development lifecycle because they help identify categories of threats, allowing countermeasures or other protections to be designed and developed. Throughout 2018 we sought to improve not only the codebase directly, but to review and update our threat models and our internal processes as well, something which we will continue to do during 2019. + +Going forward, we will expand our use of high-quality third-party libraries, such as [Beast](https://www.boost.org/doc/libs/1_69_0/libs/beast/doc/html/beast/introduction.html) (itself a part of the excellent collection of [Boost](https://www.boost.org/) libraries) and also seek to leverage new C++ features that can help us write simpler and more expressive code. + +This reduction in the amount of code and custom functionality will result in a “leaner” and more compact codebase, which will help us expand our use of static and dynamic analysis tools. Together with the improvements in our automated testing and CI/CD processes we will be able to catch more errors, especially those that are typically found in user-accessible API endpoints, before the code is merged. + +The net result of these changes will be better, safer code and a reduction in the overall [attack surface](https://en.wikipedia.org/wiki/Attack_surface) of rippled. + +## Always Improving + +Despite all the improvements made, we know that there’s more that we could be doing. We look forward to working together with the community of XRP Ledger developers and hope that we can exchange ideas that will help to improve the quality of the codebase and advance our shared goal of building a system that allows value to move both securely and quickly, helping to bring about the Internet of Value. + +_Contact Nik: _
+_Follow Nik on Twitter: [@nbougalis](https://twitter.com/nbougalis)_ diff --git a/content/blog/2019/statement-on-the-biased-nonce-sense-paper.md b/content/blog/2019/statement-on-the-biased-nonce-sense-paper.md new file mode 100644 index 0000000000..c393b6ae4c --- /dev/null +++ b/content/blog/2019/statement-on-the-biased-nonce-sense-paper.md @@ -0,0 +1,25 @@ +# Statement on the “Biased Nonce Sense” Paper + +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](https://eprint.iacr.org/2019/023.pdf) authored by Joachim Breitner and Nadia Heninger discloses a more serious attack than was previously known on signatures with imperfect nonces. + + + +The vulnerability comes from defects in software that signs transactions that are subsequently submitted to systems that use secp256k1 signatures -- including Bitcoin, Ethereum, XRP Ledger and dozens of other distributed ledger technologies. This vulnerability is not present in the core software that operates these blockchains / distributed ledgers. + +For several years, the widely agreed upon industry recommendation has been to use deterministic nonces as described in [RFC6979](https://tools.ietf.org/html/rfc6979) when generating signatures for any of these systems. Those who use exclusively deterministic nonces (or use Ed25519 keys) are not vulnerable to this attack. Signing software contained in `rippled` and ripple-lib packages published by Ripple from August 2015 and later always use deterministic nonces. + + +## FAQ + +- **Q: Is this an issue with the XRP Ledger?** +- **A:** No. It’s an issue with improperly made ECDSA signatures. The vulnerability comes from defects in signing software that does not properly use unbiased (random or deterministic but apparently random) nonces. + +- **Q: What systems are affected?** +- **A:** At least any systems that use secp256k1 signatures and support private key reuse. This includes Bitcoin, Ethereum, XRP Ledger, and many other blockchain systems. + +- **Q: What should users do?** +- **A:** It is recommended that users utilize either Ed25519 keys (which are unaffected) or software that uses deterministic nonces in its signatures. No changes to the XRP Ledger software are required. You can proactively rotate the keys associated with an XRP Ledger address by [assigning a regular key pair](https://xrpl.org/assign-a-regular-key-pair.html) and then, optionally, disabling the master key. (If you are worried your master key may be compromised, you should disable it.) + +- **Q: Do I need to be worried about the security of my XRP Ledger accounts?** +- **A:** Follow this flowchart: + ![If you have an XRP Ledger account, you have signed transactions from that account, you do not know whether your signatures all used deterministic nonces, _and_ you have not changed your key after any signatures that might have used weak nonces, you may be affected. Otherwise, you are not affected with regards to the XRP Ledger. Versions of rippled and ripple-lib from August 2015 and later always use deterministic nonces.](/blog/img/biased-nonce-sense-flowchart.png) diff --git a/content/blog/2019/testnet-reset.md b/content/blog/2019/testnet-reset.md new file mode 100644 index 0000000000..5940514984 --- /dev/null +++ b/content/blog/2019/testnet-reset.md @@ -0,0 +1,44 @@ +# XRP Testnet Has Been Reset + +> **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. + + + +## Background + +Ripple operates an XRP test network (the XRP Testnet) to help the community test new features and integrations without requiring real XRP on the XRP Ledger Mainnet. Although Ripple has stated publicly the intention to reset the Testnet on a monthly basis, feedback from members of the XRP Ledger ecosystem has been that monthly resets would too disruptive, and in practice, resets of the Testnet have been irregular and infrequent. + +Recently use of the Testnet Faucet has increased, causing it to fund over 1 million new accounts per month. On 2019-08-25, Ripple's XRP Testnet Faucet address exhausted its supply of Testnet XRP, rendering it unusable. Like real XRP, the supply of Testnet XRP is limited and most Testnet XRP was being held by addresses whose keys have been discarded. Thus, the only way to add more XRP to the Testnet Faucet is to restart the network from scratch. + +In the future, Ripple intends to reset the Testnet approximately every 90 days or as needed. Ripple will make every effort to provide advance notice before resetting the XRP Testnet in the future. + +Furthermore, to better accommodate the increased usage, the Testnet Faucet has been reconfigured to distribute 1,000 Testnet XRP at a time to new accounts, instead of 10,000. + + +## Testnet Status + +Currently, the Testnet is available and users can get new accounts and new Testnet XRP from the [Testnet Faucet](https://xrpl.org/xrp-test-net-faucet.html), but new accounts and transactions will be deleted again when the next reset occurs. + +If your test app relies on data being present in the Testnet ledger, we recommend building automated testing scripts that repopulate the Testnet with test data after a reset. For example, if your test finds that necessary data is not on the ledger, you can re-create it. + +Do not rely on the Testnet ledger's state. The data on it will be deleted when the next reset occurs. + +At this time, no amendments are enabled on the Testnet, so features such as [Multi-signing](https://xrpl.org/multi-signing.html), [Escrow](https://xrpl.org/escrow.html), and [Payment Channels](https://xrpl.org/payment-channels.html) are currently unavailable. Following the latest reset, the status of Amendments in the Testnet should exactly match the [current status of the Mainnet](https://xrpl.org/known-amendments.html). Specifically, the Checks amendment will not be re-enabled at this time. + +This change does not have any bearing on the future status of the Checks amendment, but is being made so that the Testnet's transaction processing matches the Mainnet as closely as possible. + +## Action Recommended + +If you run a `rippled` server [connected to the XRP Testnet](https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html), you should delete your database data and restart your server after the reset occurs. For example: + +```sh +# rm -r /var/lib/rippled/db/* + +# systemctl restart rippled.service +``` + +**Warning:** Be sure that you have not put any files you want to keep in the folder before you delete it. It is generally safe to delete all of a `rippled` server's database files, but you should only do this if the configured database folder is not used for anything other than `rippled`'s databases. diff --git a/content/blog/2019/websocket-tool-update.md b/content/blog/2019/websocket-tool-update.md new file mode 100644 index 0000000000..a5904a9ac8 --- /dev/null +++ b/content/blog/2019/websocket-tool-update.md @@ -0,0 +1,72 @@ +# WebSocket Tool Update + +As part of [the recent site relaunch](/blog/2019/welcome-to-xrpl-org), the XRP Ledger Dev Portal has an updated version of the [WebSocket API Tool](/resources/dev-tools/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. + + + +## Revisiting an Oldie + +The original WebSocket tool was built before 2014, and things were different at the time. For one thing, web technology was different: The latest HTTP version was 1.1, Chrome and Firefox each had about 30 fewer version numbers under their belts, and Microsoft's Internet Explorer had yet to yield to its successor, Edge. The cryptocurrency space was still in its infancy: Ripple ("Ripple Labs" at the time) had fewer than 50 employees, and XRP prices were hovering somewhere in the neighborhood of USD $0.005—half a cent—at the time. Many other popular coins and networks, such as Ethereum, had not even launched yet. + +The landscape has changed a lot in the past five years. The JavaScript ecosystem has matured dramatically, as has [the language itself](https://en.wikipedia.org/wiki/ECMAScript) and the technologies it interfaces with, including HTML and CSS. Still, the WebSocket tool continues to be one of the most popular pages on the site, because it provides a quick and easy way to ask the XRP Ledger for authoritative answers. As part of refreshing the XRP Ledger Dev Portal, it was time to revisit the WebSocket tool to bring it up to date with modern standards, so it could be more efficient, more extensible, and leverage more shared technology. + +## New Features + +A big motivator for updating the tool was to introduce new functionality: things that were tough to add with the tool's existing structure. The refresh provided an opportunity to add several new, long-desired features: a server selector, permalinking to tool status, curl syntax button, error highlighting, and better message history management. + +### Server Selector + +![Server Selector button showing an active connection to the Test Net](/blog/img/wstool-server-selector.png) + +The WebSocket tool originally had the problem of connecting only to a hardcoded pool of servers run by Ripple, and sometimes, if you lost connection, it would not update to show that you had disconnected. The new tool adds a button to select where to connect, and shows you the status of your connection. The refreshed tool provides options to connect to Ripple's general-purpose public XRP Ledger servers, full-history public servers, Test Net servers, or to your own server running locally. This list can also change to provide more options in the future. + + +### Permalinking + +![Permalink button](/blog/img/wstool-permalink-button.png) + +The new Permalink button, represented by a button with a chain-link icon, provides a link you can use to share the current state of your inputs—the request body and the chosen server. Like other web tools such as JSFiddle or CodePen, this provides a way to prepare a set of inputs and share it with others. This might come in handy in a bunch of different ways. Link people the inputs to reproduce a weird bug. Show others [how to look up the latest Amendments status directly in the ledger](https://xrpl.org/websocket-api-tool.html?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%22id%22%3A%22hello_from_the_blog%22%2C%22command%22%3A%22ledger_entry%22%2C%22index%22%3A%227DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4%22%2C%22ledger_index%22%3A%22validated%22%7D). Have your offline signing tool provide links to submit pre-signed transaction blobs. Be creative! + + +### curl Syntax Button + +![curl syntax button](/blog/img/wstool-curl-syntax-button.png) + +Maybe you're more comfortable using the command line, or you're trying to figure out how to replicate a given thing using JSON-RPC. The new curl syntax button, represented by a `>_` icon, loads a popup with the current inputs of the request box translated into a JSON-RPC call you can make with [the `curl` utility](https://curl.haxx.se/). Copy-paste this into your command line or your bash scripts and see it go! + +**Note:** The [`path_find`](/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/path_find/) command isn't available over JSON-RPC, so the button is hidden when that command is selected. Some other commands may not work without modification on JSON-RPC; for example, the [`subscribe`](/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe/) and [`unsubscribe`](/references/http-websocket-apis/public-api-methods/subscription-methods/unsubscribe/) commands require an admin-only `url` callback field in JSON-RPC. + + +### Error Highlighting + +![Red mark and tooltip indicating where a JSON syntax error occurs](/blog/img/wstool-error-highlighting.png) + +Some of the easiest mistakes to make when using the WebSocket are simple syntax errors: things like a missed comma, a mismatched quotation mark or an extra curly-brace. The new tool goes further than simply telling you there's a syntax error: it highlights the lines where errors occurred by placing red circled X marks on them. Hover your cursor over the error to get a description of the error and what the parser expected to see there. + + +### Message History Management + +![Keep last setting, pause subscription button, and clear history button](/blog/img/wstool-message-history-management.png) + +Previously, the WebSocket tool had one box for direct responses to commands, and another area that held all other messages (such as subscriptions). The interface now displays messages of all types in one stream, keeping a history of your previous calls until you close the page, choose a different server, or choose to clear history with the new "Clear History" button (represented by a trash can icon). That way, you can try changing one detail of your request and see the two side-by-side. It also better represents the nature of a WebSocket connection. + +The amount of history the tool keeps at a time isn't unlimited, which is another change from the previous version. By default, any time the tool receives a new message, it deletes any messages older than the most recent 50, though you can set this to be any amount you like. If you leave the tab open so that it continues receiving messages for a long time, the amount that accumulates can really slow down your browser. This new setting gives you the control over if and when that happens. + +Unlike the old tool, the refreshed WebSocket tool also does not automatically subscribe you to any message streams like ledger-closing events, so you won't get inundated with messages unless you've used a command to subscribe to them. If you do, messages still can pile up quickly, so the tool carries over the ability to pause notification-type messages while still showing direct responses to the commands you run. To save space, this pause/resume button has been changed to use familiar "pause/play" icons. + + + +## Under the Hood + +Some of the code for the WebSocket tool remains the same: no need to fix things that are working perfectly well even today. Other parts were restructured or thrown out entirely as part of the process. Here's a high-level view of the big changes: + +- **No ripple-lib** - One of the biggest changes in the new WebSocket tool is to bypass the ripple-lib library in favor of a direct WebSocket connection. There's nothing wrong with ripple-lib, but the WebSocket tool was using a tiny chunk of its functionality and was stuck on an ancient version from before the "RippleAPI" interface of modern versions. Going through ripple-lib also introduced some tiny differences that you wouldn't see if you were to use the WebSocket interface natively from any other programming language. For example, the tool ignored your ID values and supplied its own, purely numerical, IDs. The new tool replaces 352 KB of ripple-lib code with 3.4 KB of code for opening and managing WebSocket connections—literally a 99% reduction in size! The new code sends requests and responses with minimal preprocessing, so you don't have to guess what's part of the server and what's a result of passing things through ripple-lib. (As a result, it uses the exact ID you've provided for each message, or none if you omit the ID.) The only processing the new tool does on request and response messages is to run the JSON through your browser's built-in parser so it can add line breaks and indentation for readability. + +- **Bootstrap Styles** - The [Bootstrap](https://getbootstrap.com/) framework is ubiquitous in today's web, and for good reason. It provides styles, scripts, and shortcuts for making websites that look great on a range of devices and screen sizes. The XRP Ledger Dev Portal already uses Bootstrap for the rest of the site, but the old WebSocket Tool had a lot of redundant older styles for things like buttons. These styles led to minor inconsistencies in color and behavior in different parts of the site. The refreshed version uses Bootstrap classes for all the form interfaces, which made it easier to add new buttons and fields for the new features. The refreshed version also drops 5 KB of CSS from the tool page and removes some unused information from the HTML markup of the page itself. + +- **Separate Methods File** - The refreshed tool splits the definitions of the methods in the sidebar into [their own source file](https://github.com/ripple/ripple-dev-portal/blob/master/assets/js/apitool-methods-ws.js), which makes it just a little easier to add, remove, or update example methods because you don't have to dig through the rest of the tool's code and worry about breaking it with a new method. The list has already been updated to match the examples in the documentation, which brings a host of useful updates to the tool, whose old examples included some deprecated fields and not-recommended syntax. + + +## Moving Forward + +The new WebSocket tool is just a small tool in the XRP Ledger toolbox. This refresh makes it just a little bit faster, cleaner, and more powerful than before. It's our hope that this contributes to the further growth of the XRP Ledger, by helping more people get started interacting with the technology. This tool is for the community, so we encourage community contributions — whether it's more public servers to add to the default list, more and better examples, or just creative use of the existing features, the power is yours. Use it responsibly. diff --git a/content/blog/2019/welcome-to-xrpl-org.md b/content/blog/2019/welcome-to-xrpl-org.md new file mode 100644 index 0000000000..105550803e --- /dev/null +++ b/content/blog/2019/welcome-to-xrpl-org.md @@ -0,0 +1,9 @@ +# Welcome to xrpl.org! + +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. + +In the past, Ripple's developer site has been the hub for documentation and tools on the XRP Ledger. As the XRP Ledger community continues to grow and as the network becomes further decentralized, it makes sense to have a website that is openly built and maintained by the community, not just by one institution. While Ripple will still play a significant role in managing and providing content for xrpl.org, so will the many other dedicated developers, designers, writers and business leaders that interact with the XRP Ledger every day. + +The top level navigation of xrpl.org highlights key sections of the site: [Docs](/docs) (documentation), [Use Cases](/about/uses), [Dev Tools](/resources/dev-tools) (interactive tools for XRP Ledger developers), and a [Blog](/blog/) with release notes, news, and other articles from those developing XRP Ledger technologies. All pages in the documentation, use cases, and even developer tools have an "Edit" button you can use to propose corrections, improvements, and additions to the source for the website on GitHub. + +Like the XRP Ledger, anyone can contribute to the evolution of xrpl.org by submitting comments, suggestions and/or pull-requests with changes on GitHub. A team of reviewers from the XRP community will evaluate each request for accuracy, quality and style and approve changes as deemed reasonably appropriate. With everyone's cooperation, xrpl.org will always host the best community-generated technical content related to the XRP Ledger. diff --git a/content/blog/2019/xrpl-devnet-launch.md b/content/blog/2019/xrpl-devnet-launch.md new file mode 100644 index 0000000000..cc90ecb84c --- /dev/null +++ b/content/blog/2019/xrpl-devnet-launch.md @@ -0,0 +1,20 @@ +# Discover Upcoming XRP Ledger Amendments and Features with Devnet! + +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. + +Previously, developers could only access the latest stable version of rippled on either of the following: + +* XRP Ledger Testnet, a test network +* XRP Ledger Mainnet, the production network + +The launch of XRPL Devnet helps promote more developer engagement and experimentation of new use cases on XRP Ledger. + +Devnet will be updated with the latest beta build versions, starting with `rippled` version [1.4.0-b5](https://github.com/ripple/rippled/tree/develop/Builds), as they become available on the [development branch](https://github.com/ripple/rippled/tree/develop) of `rippled`. + +Developers can access [XRP Ledger Devnet](https://xrpl.org/xrp-testnet-faucet.html) by generating account credentials, which automatically deposits Devnet XRP from the Devnet Faucet. + +Upon launch, XRP Ledger Devnet supports the [X-Address Format](https://xrpaddress.info/), which was recently proposed as a new standard format for displaying XRP addresses and [Deletable Accounts](https://github.com/xrp-community/standards-drafts/issues/8), which is a recently proposed [Amendment](https://xrpl.org/amendments.html) that allows users to delete their XRP Ledger accounts and recover all but 5 XRP from their [base reserve](https://xrpl.org/reserves.html#base-reserve-and-owner-reserve) of 20 XRP. + +Developers can expect XRP Ledger Devnet to be updated more frequently than Testnet or Mainnet. Notice will be given ahead of any Devnet ledger resets, which are periodically required. + +Also, as of today, developers can access [XRP-API](https://xrpl.org/xrp-api.html), a language agnostic REST-like API for the XRP Ledger; and the [Xpring SDK](https://github.com/xpring-eng/Xpring-SDK), which is a set of language-specific libraries and services designed by the [Xpring](https://xpring.io/) team at Ripple, to make interaction with the XRP Ledger and Interledger easy and intuitive. diff --git a/content/blog/2020/checks-enabled.md b/content/blog/2020/checks-enabled.md new file mode 100644 index 0000000000..0236eb4929 --- /dev/null +++ b/content/blog/2020/checks-enabled.md @@ -0,0 +1,33 @@ +# The Checks Amendment is Now Enabled + +[As previously announced](https://xrpl.org/blog/2020/checks-expected.html), the Checks amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6) on 2020-06-18. + + + +## Checks Summary + +Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and recipient. Later, the recipient can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so the recipient can try again later. + +For more information, see [Checks](https://xrpl.org/checks.html). + +## Action Recommended + +No action is required at this time. The minimum XRP Ledger server version to remain synced to the network already has support for Checks. + +The Checks amendment also enables a minor improvement to the XRP Ledger's [decentralized exchange](https://xrpl.org/decentralized-exchange.html): OfferCreate transactions that failed because their expiration time had already passed when the transaction executed are now assigned the [error code `tecEXPIRED`](https://xrpl.org/tec-codes.html). Previously, such offers were assigned the success code `tesSUCCESS` despite not being executed. Users of the API can use the new status code to more easily recognize when an offer was not executed because it had already expired. + +If you are the developer for a library that reads and writes the XRP Ledger's binary format, make sure your library can read and write the new transaction and ledger types introduced by the Checks amendment. Ripple's reference libraries already support Checks, including [`ripple-binary-codec` (since v0.1.13)](https://github.com/ripple/ripple-binary-codec/) and [`ripple-lib` (since v0.19.0)](https://github.com/ripple/ripple-lib/). + +If you have an XRP Ledger business, you may also want to read about [Checks](https://xrpl.org/checks.html) to see if your business model could benefit from using this feature. + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments) +* [Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/checks-expected.md b/content/blog/2020/checks-expected.md new file mode 100644 index 0000000000..5d89d1cc38 --- /dev/null +++ b/content/blog/2020/checks-expected.md @@ -0,0 +1,33 @@ +# The Checks Amendment is Expected 2020-06-18 + +The Checks amendment to the XRP Ledger, introduced all the way back in [`rippled` v0.90.0](https://github.com/ripple/rippled/releases/tag/0.90.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/F2CACEB0680626E8A4DE7EDA02DEC7438E1FB0D7C8736DD327074F85877E6D8E). Currently, it is expected to become enabled on 2020-06-18. As long as the Checks amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date. + + + +## Checks Summary + +Introduces "Checks" to the XRP Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and recipient. Later, the recipient can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so the recipient can try again later. + +For more information, see [Checks](https://xrpl.org/checks.html). + + +## Action Recommended + +No action is required at this time. The minimum XRP Ledger server version to remain synced to the network already has support for Checks. + +If you are the developer for a library that reads and writes the XRP Ledger's binary format, make sure your library can read and write the new transaction and ledger types introduced by the Checks amendment. Ripple's reference libraries already support Checks, including [`ripple-binary-codec` (since v0.1.13)](https://github.com/ripple/ripple-binary-codec/) and [`ripple-lib` (since v0.19.0)](https://github.com/ripple/ripple-lib/). + +If you have an XRP Ledger business, you may also want to read about [Checks](https://xrpl.org/checks.html) to see if your business model could benefit from using this feature. + + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments) +* [Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/deletableaccounts-enabled.md b/content/blog/2020/deletableaccounts-enabled.md new file mode 100644 index 0000000000..b4dbf22a87 --- /dev/null +++ b/content/blog/2020/deletableaccounts-enabled.md @@ -0,0 +1,38 @@ +# DeletableAccounts is Now Enabled + +As previously announced, the DeletableAccounts amendment [became enabled on the XRP Ledger](https://livenet.xrpl.org/transactions/47B90519D31E0CB376B5FEE5D9359FA65EEEB2289F1952F2A3EB71D623B945DE) on **2020-05-08**. + + + +## DeletableAccounts Summary + +Prior to this amendment, every [account in the XRP Ledger](https://xrpl.org/accounts.html) was permanent. With this amendment, accounts can now be deleted at a cost of 5 XRP by sending a new AccountDelete transaction type. This amendment also changes the starting `Sequence` number for new accounts so that it matches the ledger index when they were created instead of starting at 1. + +For more details on what to look out for or how to use deletable accounts, see [the previous primer](/blog/2020/get-ready-for-deletable-accounts). + +## Adieu, Deleted Accounts + +Within minutes of the amendment going live, some XRP Ledger users have already started reclaiming XRP by deleting their excess accounts. A few of the first accounts to be deleted include: + +- [r4WQTd2Ck9tVS536U6EBNErBbrToUoVGh8](https://livenet.xrpl.org/transactions/CF61501174E29B3C7A63E65FFCEF4EA882BD22B449490AB453701DCA7EEAF0B3/detailed) +- [r93Fr5Cmf6KAho1GfF9mvNKV97tZsCFKcB](https://livenet.xrpl.org/transactions/2BCD5B4C9CB7DC65C4C620F2767104CF3F35F805B189A414C1E02479788B7FDA/detailed) +- [rpZ74gjYqVGmRQpXYXbsMXXQXJGJaWhgNu](https://livenet.xrpl.org/transactions/9E471809937837E1D7F6DB5542BECFFD2CE4D43E93D6169613333858CB865436/detailed) + +We salute these early adopters for cleaning up extra cruft from the ledger. + +## Action Recommended + +**If you have software that uses the XRP Ledger,** you should be sure your code still works with the changes to make accounts deletable. See [Get Ready for Deletable Accounts](https://xrpl.org/blog/2020/get-ready-for-deletable-accounts.html) for details on starting sequence numbers, deleted accounts' transaction history, and more. + +Additionally, **if you operate an XRP Ledger server,** then you should upgrade to **version 1.5.0** as soon as possible. Two amendments new to v1.5.0, `fixQualityUpperBound` and `RequireFullyCanonicalSig`, are currently **open for voting** and could gain supermajority support among trusted validators at any time. After that point, the amendments could become enabled in two weeks, causing any servers not running at least v1.5.0 to become amendment blocked. + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/deletableaccounts-expected.md b/content/blog/2020/deletableaccounts-expected.md new file mode 100644 index 0000000000..b86635940f --- /dev/null +++ b/content/blog/2020/deletableaccounts-expected.md @@ -0,0 +1,74 @@ +# DeletableAccounts and Two Other Amendments Expected Soon + +Three amendments to the XRP Ledger protocol currently hold support of a majority of trusted validators, and are expected to become enabled on the following dates (in UTC): + +- [fixPayChanRecipientOwnerDir is expected](https://xrpcharts.ripple.com/#/transactions/2EBB6EC9C6A070EF665D482C2E725319DEB552D88B079227333A5BE452602C2A) on **2020-05-01**. +- [fixCheckThreading is expected](https://xrpcharts.ripple.com/#/transactions/413007375A2D1B213D477154375A6878AF58360E4190D339C8B43122CA366AA7) also on **2020-05-01**. +- [DeletableAccounts is expected](https://xrpcharts.ripple.com/#/transactions/592E5151BFAE5B544FF4213A4358D341EA6F394ECF738CBC740F555CEC5A6C70) on **2020-05-08**. + + + +As long as these amendments continue to have the support of at least 80% of trusted validators continuously, they will become enabled on the scheduled dates. All three amendments were introduced in [`rippled` v1.4.0](https://github.com/ripple/rippled/releases/tag/1.4.0). + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.4.0 or higher by **2020-05-01**, for service continuity. **Version 1.5.0** is _strongly recommended_. + +- The DeletableAccounts amendment changes the starting [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) for accounts. If you have automatic processes that send transactions from newly-funded accounts, please check that the change does not break critical processes. + +## Note Regarding Payment Channels + +The fixPayChanRecipientOwnerDir amendment previously [gained majority support in January.](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html) However, several trusted validators withdrew support from the amendment because it would cause [breaking changes](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html#action-required) to the [`account_channels` API method](https://xrpl.org/account_channels.html). Version 1.5.0 of `rippled` contains a fix that makes the `account_channels` API method continue to work without breaking changes. If you use `account_channels`, be sure to upgrade to `rippled` version 1.5.0 to avoid breaking changes to the API. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.4.0 or higher by 2020-05-01, when the fixPayChanRecipientOwnerDir and fixCheckThreading amendments are expected to become enabled, then your server will become [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If none of the amendments become enabled, then your server will not become amendment blocked and should continue to operate. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + + +## DeletableAccounts Summary + +The DeletableAccounts amendment makes it possible to delete [XRP Ledger accounts](https://xrpl.org/accounts.html). + +If you have accounts on the XRP Ledger, you may be able to reclaim some of the [XRP account reserve](https://xrpl.org/reserves.html) by deleting your accounts after this amendment becomes active. Deleting an account costs 5 XRP and sends the deleted account's remaining XRP to another address. You can send the remaining XRP to another account you own, or even deposit the remaining XRP at a hosted wallet such as an exchange. (When sending to a hosted wallet, be sure to include a [destination tag](https://xrpl.org/source-and-destination-tags.html) or use an [X-address](https://xrpaddress.info/).) Not all accounts can be deleted. For the complete list of requirements, see [Deletion of Accounts](https://xrpl.org/accounts.html#deletion-of-accounts) and the [XRP Community Standards Draft 7](https://github.com/xrp-community/standards-drafts/issues/8). + +With this amendment, new accounts start with their `Sequence` numbers equal to the `Sequence` number matching the [index of the ledger](https://xrpl.org/basic-data-types.html#ledger-index) in which the account is created. This change protects accounts that have been deleted from having their old transactions executed again if the same address is later re-created. + +Without this amendment, new accounts always start with their `Sequence` numbers at 1, and there is no way to remove accounts from the state data of the ledger. + + +## fixPayChanRecipientOwnerDir Summary + +Changes the [PaymentChannelCreate transaction](https://xrpl.org/paymentchannelcreate.html) type so that it adds new [payment channels](https://xrpl.org/payment-channels.html) to the recipient's [owner directory](https://xrpl.org/directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged. + +This change prevents accounts from being deleted if they are the recipient for open payment channels, except for channels created before this amendment. + + +## fixCheckThreading Summary + +This amendment fixes an aspect of the [Checks amendment](https://xrpl.org/known-amendments.html#checks) and has no effect until the Checks amendment is also enabled. However, enabling this amendment first ensures that all Checks have proper threading metadata from the start. + +The fixCheckThreading amendment changes the way Checks transactions affect account metadata, so that Checks are properly added to the [account](https://xrpl.org/accounts.html) history of the receiving account. (Specifically, they update the `PreviousTxnID` and `PreviousTxnLedgerSeq` fields of the receiving account's [AccountRoot object](https://xrpl.org/accountroot.html), which can be used to trace the "thread" of transactions that affected the account and the objects it owns.) + +Without this amendment, Checks transactions ([CheckCreate](https://xrpl.org/checkcreate.html), [CheckCash](https://xrpl.org/checkcash.html), and [CheckCancel](https://xrpl.org/checkcancel.html)) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts. + + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/developer-reflections-xrp-toolkit.md b/content/blog/2020/developer-reflections-xrp-toolkit.md new file mode 100644 index 0000000000..426d9448b3 --- /dev/null +++ b/content/blog/2020/developer-reflections-xrp-toolkit.md @@ -0,0 +1,27 @@ +--- +category: 2020 +date: 2020-07-17 +labels: + - Developer Reflections +--- +# Developer Reflections: XRP Toolkit + +[XRP Toolkit](https://www.xrptoolkit.com/), developed by [Towo Labs](https://towo.io), is a platform for managing crypto assets on the XRP Ledger, including a full-featured graphical user-interface (GUI) for the XRP Ledger's built-in decentralized exchange (DEX). + +> ![Screenshot: trade tab](../img/xrp-toolkit/trade-tab.png) + +XRP Toolkit is used by thousands of Xumm App and Ledger hardware wallet users to access advanced XRP Ledger features, such as limit orders, cross-currency payments, escrows, checks, and account settings. + +> ![Screenshot: account tab](../img/xrp-toolkit/account-tab.png) + +When a user connects their wallet to XRP Toolkit, they get the security benefits of their favorite non-custodial wallet, and the usability of a full-featured web interface. + +> ![Screenshot: send tab](../img/xrp-toolkit/send-tab.png) + +XRP Toolkit has been designed from the ground up with strong security standards, and only handles public data and public keys. XRP Toolkit uses ripple-lib and the JSON-RPC Websocket to access the XRP Ledger. + +> ![Screenshot: escrow tab](../img/xrp-toolkit/escrow-tab.png) + +All transaction signing has been offloaded to the supported wallets, which reduces the need to copy/paste sensitive key material, and allows XRP Toolkit to focus on offering users advanced XRP Ledger features. + +If you're a developer that uses the [XRP Ledger](https://xrpl.org/), [Interledger](https://interledger.org/), [Xpring SDK](https://github.com/xpring-eng/xpring-sdk), [XRP API](https://github.com/xpring-eng/xrp-api), [ripple-lib](https://github.com/ripple/ripple-lib), [XRP CLI](https://github.com/xpring-eng/xrp-cli) or related open-source technologies in your products and apps, then fill out this form [[link](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link)] with details about your product or app, and join the community. diff --git a/content/blog/2020/developer-reflections-xrplorer.md b/content/blog/2020/developer-reflections-xrplorer.md new file mode 100644 index 0000000000..58bab64be7 --- /dev/null +++ b/content/blog/2020/developer-reflections-xrplorer.md @@ -0,0 +1,34 @@ +--- +category: 2020 +date: 2020-05-30 +labels: + - Developer Reflections +--- +# Developer Reflections: Xrplorer + +This week on Developer Reflections, we're proud to highlight [Xrplorer](https://xrplorer.com), a powerful open analytics platform built on top of a graph database representation of the XRP Ledger. + +Xrplorer was built by [Thomas Silkjaer](https://twitter.com/Silkjaer), a Danish data scientist, designer, and popular [Forbes Contributor](https://www.forbes.com/sites/thomassilkjaer/#4562826a7348), as a side-project on [Neo4j](https://neo4j.com/), to prove out the benefits of using a graph database over a traditional relational database management system (RDBMS), which is typically used to store XRP Ledger historical data. + + + +**Note:** The Xrplorer project as described in this post has been deprecated, as forensics and other data are being combined with related efforts within the XRP Ledger Foundation. _(Updated October 2022)_ + +A primary benefit of the graph database is that the ledgers are not stored in their original binary form or JSON representations, which makes it easier to do more complex relational queries, apply graph algorithms, run fraud detection algorithms and integrate XRP Ledger data with machine learning. + +To that extent, Xrplorer has been widely used by the XRP Community as a watchdog platform to prevent, report and combat fraudulent activity on the XRP Ledger. + +A forensic team was formed on [Twitter](https://twitter.com/xrpforensics) using Xrplorer and social media data to serve as a safety beacon for the XRP Community by reporting scammers and fake giveaways. + +> ![Xrplorer tweet flagging a scam domain](../img/xrplorer/xrplorer-anti-scam-tweet.png) + +[Xrplorer](https://twitter.com/xrplorer) has also been effective at identifying "[amendment blocked](https://xrpl.org/amendments.html#amendment-blocked)" servers and notifying their operators, who hadn't yet upgraded to the latest stable version of the XRP Ledger. + +> ![Xrplorer tweet about finding amendment blocked services](../img/xrplorer/xrplorer-amendment-blocked-tweet.png) + +The graph database structure has also enabled Silkjaer to [visualize XRP Ledger data in stunning ways](https://www.forbes.com/sites/thomassilkjaer/2019/05/13/visualization-the-xrp-ledger-expanding-over-time/#6508d5a446ea) , which have uniquely expressed his combined passion and talent for data and design. + +> ![XRP Ledger visualization by Thomas Silkjaer](../img/xrplorer/xrpl-visualized-by-silkjaer.png) +> _XRP Ledger visualized by Thomas Silkjaer in [Forbes](https://www.forbes.com/sites/thomassilkjaer/2019/05/13/visualization-the-xrp-ledger-expanding-over-time/#52c7b3746ea7)._ + +If you're a developer that uses the [XRP Ledger](https://xrpl.org/), [Interledger](https://interledger.org/), [Xpring SDK](https://github.com/xpring-eng/xpring-sdk), [XRP API](https://github.com/xpring-eng/xrp-api), [ripple-lib](https://github.com/ripple/ripple-lib), [XRP CLI](https://github.com/xpring-eng/xrp-cli) or related open-source technologies in your products and apps, then fill out this form [[link](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link)] with details about your product or app, and join the community. diff --git a/content/blog/2020/developer-reflections-xrpscan.md b/content/blog/2020/developer-reflections-xrpscan.md new file mode 100644 index 0000000000..cf22f56c37 --- /dev/null +++ b/content/blog/2020/developer-reflections-xrpscan.md @@ -0,0 +1,28 @@ +--- +category: 2020 +date: 2020-05-02 +labels: + - Developer Reflections +targets: [devblog] +--- +# Developer Reflections: XRPScan + +This week on Developer Reflections, we’re proud to highlight [XRPScan](https://xrpscan.com/), one of the most popular blockchain explorers for XRP, used by over 50+ exchanges globally, including Coinbase, Bitfinex, Bitkub, and Bitpay, among others, to look up XRP Ledger account information and show Proof-of-Transaction to their users. + +![Screenshot: account summary](/blog/img/dev-reflections-xrpscan-1.webp) + +[XRPScan](https://twitter.com/xrpscan) is also used by a growing number of wallets, crypto tax software providers, market maker trading bots, and has seen over 180 million individual API calls in the last 30 days alone. XRPScan uses [xrpl.js](https://github.com/XRPLF/xrpl.js) _(Note: formerly ripple-lib)_ to surface transaction data across the XRP Ledger. + +![Screenshot: transaction summary](/blog/img/dev-reflections-xrpscan-2.webp) + +As one of the largest providers of XRP Ledger account identification services in the community, with over 550 verified exchange, payment, AML and compliance services integrated, XRPScan sees several thousand unique visitors per day. + +![Screenshot: Amendments dashboard](/blog/img/dev-reflections-xrpscan-3.webp) + +The Xpring team at Ripple even uses the XRPScan Amendments page internally to track the status of amendment activations among validators on the XRP Ledger network. We believe that XRPScan has built a powerful platform for visualizing actionable data across the XRP Ledger, using Xpring tools. + +![Screenshot: DeleteableAccounts amendment status page](/blog/img/dev-reflections-xrpscan-4.webp) + +XRPScan is the first app that we’re featuring in a new content series called Developer Reflections, which will highlight some of the work being done by the growing community of talented developers using the open-source protocols, tools and services that Xpring helps to build and maintain. + +If you’re a developer that uses the [XRP Ledger](https://xrpl.org), [Interledger](https://interledger.org/), [xrpl.js](https://github.com/XRPLF/xrpl.js) or related open-source technologies in your products and apps, then [fill out this form](https://docs.google.com/forms/d/e/1FAIpQLSeQAWZFBanNeuYyTFoA2FzHXJzzduoQGSGxgeInzCL_WKJpdQ/viewform?usp=sf_link) with details about your product or app, and join the community. _(Editor's note: this post was updated to remove links to deprecated projects.)_ \ No newline at end of file diff --git a/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.md b/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.md new file mode 100644 index 0000000000..cb204f417c --- /dev/null +++ b/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.md @@ -0,0 +1,50 @@ +# Two Fix Amendments are Expected 2020-01-18 + +On 2020-01-03, the [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/71460CE2DB7594C25A649C042D18BC3C027910CF02C60EC7F1E77660C9CAE1D2) and [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/4F5C639512B14BC6986026A2871CBF348C6092B1D4BE2DE9EE64D0F04E1EA5F7) amendments to the XRP Ledger gained support from a majority of trusted validators. These amendments were introduced in [`rippled` v1.4.0](https://github.com/ripple/rippled/releases/tag/1.4.0). Currently, they are expected to become enabled on 2020-01-18. Each amendment that continues to have the support of at least 80% of trusted validators continuously will become enabled on the scheduled date. + +## fixCheckThreading Summary + +Changes the way Checks transactions affect account metadata, so that Checks are properly added to the [account](https://xrpl.org/accounts.html) history of the receiving account. (Specifically, they update the `PreviousTxnID` and `PreviousTxnLedgerSeq` fields of the receiving account's [AccountRoot object](https://xrpl.org/accountroot.html), which can be used to trace the "thread" of transactions that affected the account and the objects it owns.) + +Without this amendment, Checks transactions ([CheckCreate](https://xrpl.org/checkcreate.html), [CheckCash](https://xrpl.org/checkcash.html), and [CheckCancel](https://xrpl.org/checkcancel.html)) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts. This amendment has no direct effect unless the [Checks amendment](https://xrpl.org/known-amendments.html#checks) is also enabled. + +By enabling this amendment in advance of the Checks amendment, the corrected behavior will apply to all Checks. + +## fixPayChanRecipientOwnerDir Summary + +Changes the [PaymentChannelCreate transaction](https://xrpl.org/paymentchannelcreate.html) type so that it adds new [payment channels](https://xrpl.org/payment-channels.html) to the recipient's [owner directory](https://xrpl.org/directorynode.html). Without this amendment, new payment channels are added only to the sender's owner directory; with this amendment enabled, newly-created payment channels are added to both owner directories. Existing payment channels are unchanged. + +This change makes it easier to look up payment channels by their recipient and prevents accounts from being deleted if they are the recipient for open payment channels (except those channels created before this amendment). + + +## Action Required + +- If you operate a `rippled` server, **you must upgrade to version 1.4.0 (or higher) by 2020-01-18, for service continuity.** + +- If you use the XRP Ledger APIs to list payment channels, such as using the [account_channels](https://xrpl.org/account_channels.html) method, be aware that the fixPayChanRecipientOwnerDir amendment affects the results of this API. Specifically, the method will list newly-created channels for which the specified account is the recipient. Previously, this method only listed channels for which the account is the sender. (Existing payment channels for which the specified account is the recipient will continue not to appear in the results. Only new channels, created after the amendment becomes enabled, are affected.) + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.4.0 (or higher) by 2020-01-18, when the fixCheckThreading and fixPayChanRecipientOwnerDir amendments are expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If neither amendment becomes enabled, then your server will not become amendment blocked and should continue to operate. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The XRP Ledger Dev Blog](https://xrpl.org/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-lost-majority.md b/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-lost-majority.md new file mode 100644 index 0000000000..a5114928e6 --- /dev/null +++ b/content/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-lost-majority.md @@ -0,0 +1,37 @@ +# fixCheckThreading and fixPayChanRecipientOwnerDir Amendments Lost Majority + +On 2019-01-11, the fixCheckThreading and fixPayChanRecipientOwnerDir amendments lost the support of several validators, causing those amendments' support to fall below the 80% threshold for approval. (EnableAmendment LostMajority transactions: [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/3D10E846B1DA4BA07FA79BA1C13F802DD587F842F3810D997224C3693B120F51), [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/C848F96FDB815623753F27E8B5C83F4E38CFC8F50B28307142A6DFAC946EF070).) As a result, these amendments are no longer expected to become enabled on 2020-01-18, and their status depends on more validators to resume voting in favor of the amendments. + +For more information on the Amendment process, see [Amendments](https://xrpl.org/amendments.html) in the XRP Ledger Dev Portal. + + +## Ripple's Statement + +Ripple is one of several validators in the recommended list that are [currently voting](https://xrpscan.com/amendment/621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8) against enabling the fixCheckThreading and fixPayChanRecipientOwnerDir amendments. Ripple's statement on the validator voting is as follows: + +> We would like to see these amendments enabled before Deletable Accounts because they fix some edge cases that could be more confusing with Deletable Accounts. However, we have seen a slower than usual uptake of the new core XRP Ledger server version, with almost half the network still using version 1.3.1 instead of the newer 1.4.0. Additionally, [the announcement about these amendments getting a majority](https://xrpl.org/blog/2020/fixcheckthreading-fixpaychanrecipientownerdir-expected.html) was the first time it was reported that fixPayChanRecipientOwnerDir would result in a backwards-incompatible change in the behavior in the API for Payment Channels. Since neither amendment fixes an immediate bug, and enabling either one would [amendment block](https://xrpl.org/amendments.html#amendment-blocked) everyone who's still on v1.3.1, we decided to temporarily have our validators vote against the amendments with the hopes that it would give people more time to upgrade. + +## Action Recommended + +All XRP Ledger servers should continue to operate as normal for now. If any new amendment gains (or regains) a majority of 80% of validators, it must hold that majority for a continuous period of two weeks to become enabled. However, the following actions are strongly recommended to prepare for the likelihood of future amendments: + +- If you operate a `rippled` server, please [upgrade](https://xrpl.org/install-rippled.html) to version 1.4.0. + + **Caution:** Upgrading to v1.4.0 may take longer than usual because of SQL database cleanup the server performs the first time after upgrading. For more information, see [XRP Ledger version 1.4.0 Upgrade Advisory](https://xrpl.org/blog/2020/rippled-1.4.0-upgrade-advisory.html). + +- If you use the XRP Ledger APIs to list payment channels, such as using the [account_channels](https://xrpl.org/account_channels.html) method, be aware that the fixPayChanRecipientOwnerDir amendment affects the results of this API. Specifically, the method will list newly-created channels for which the specified account is the recipient. Previously, this method only listed channels for which the account is the sender. (Existing payment channels for which the specified account is the recipient will continue not to appear in the results. Only new channels, created after the amendment becomes enabled, are affected.) + +- If you use the XRP Ledger, you may want to read about [how Deletable Accounts work](https://xrpl.org/accounts.html#deletion-of-accounts) in case the changes affect your use of the XRP Ledger. The Deletable Accounts amendment is open for voting, so it may become available within a few weeks depending on how the network's trusted validators vote. (See also: the [Deletable Accounts Draft Specification](https://github.com/xrp-community/standards-drafts/issues/8).) + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments) +* This XRP Ledger Dev Blog +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/get-ready-for-deletable-accounts.md b/content/blog/2020/get-ready-for-deletable-accounts.md new file mode 100644 index 0000000000..865f5cb06f --- /dev/null +++ b/content/blog/2020/get-ready-for-deletable-accounts.md @@ -0,0 +1,77 @@ +# Get Ready for Deletable Accounts + +The XRP Ledger is currently [expected to enable](https://xrpl.org/blog/2020/deletableaccounts-expected.html) the deletion of on-ledger accounts for the first time, through the [DeletableAccounts Amendment](https://xrpl.org/known-amendments.html#deletableaccounts), on **2020-05-08 (UTC)**. This amendment comes with changes to some fairly fundamental details of the XRP Ledger protocol. If you use the XRP Ledger for your business, this is a good time to do a last check to make sure you're ready. + +Read on for some tips on: + +- Deletable accounts in general +- Handling changes to account creation +- Dealing with accounts that could be deleted +- Getting XRP back by deleting your extra accounts + + + +## Deletable accounts in general + +Prior to this amendment, every [account in the XRP Ledger](https://xrpl.org/accounts.html) was permanent. That's part of why there's a 20 XRP reserve to create new accounts; they take up space in the shared ledger. + +After the amendment, any account that meets [the prerequisites](https://xrpl.org/accounts.html#deletion-of-accounts) can be deleted. Only the owner of an account can delete it, though, since you have to send a transaction from the account to be deleted. After an account has been deleted, it's completely gone from the current ledger. Its transaction history continues to exist in immutable historical ledger data, so [full-history servers](https://xrpl.org/ledger-history.html#full-history) won't forget about it. It will eventually be forgotten by servers that only keep recent ledger history; to those servers, an account that has been deleted is pretty much the same as an account that never existed. + +After an account has been deleted, anyone can re-create it by sending at least 20 XRP to its address to fund the account, just like with any other valid XRP Ledger address. The newly created account is initialized like any other new account: settings from before it was deleted _do not_ carry over. Just like any other address, you don't get any special powers over the account for funding it; you need the cryptographic keys associated with the address to have control over the account. + + +## Handling changes to account creation + +The DeletableAccounts amendment changes the way new accounts' [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) work in the XRP Ledger: instead of starting at sequence number 1, the starting sequence number matches the current ledger index when the account was created. This change protects accounts from having their old transactions replayed if the account gets deleted and then re-created. + +Sequence numbers otherwise work the same. There are no changes necessary if you are continuing to use an account that was already created before deletable accounts. + +Sending transactions from newly-funded accounts is mostly the same as before; the main difference with deletable accounts is that you should check the account's starting sequence number when you confirm that the account has been funded, instead of assuming the starting sequence number is 1. If you let your signing software [auto-fill](https://xrpl.org/sign.html#auto-fillable-fields) the `Sequence` number, no changes are necessary. + +In cases where you must explicitly specify the sequence number, you can look it up using the [account_info method](https://xrpl.org/account_info.html) first. For a detailed walkthrough of how to do this process with an airgapped machine, see [Offline Account Setup](https://xrpl.org/offline-account-setup.html). + + +## Dealing with accounts that could be deleted + +One change that is likely to have a mild impact on many integrations with the XRP Ledger is simply the fact that accounts are no longer permanent. Even if you have looked up an account once to confirm that it exists now, deletable accounts mean the account may not still be there later when you try to interact with it again. + +For example, if someone gives you the address of an account where they want you to send a payment, your transaction may fail if the account you're sending to has been deleted. In this case, your transaction may result in a code such as [`tecNO_DST` or `tecNO_DST_INSUF_XRP`](https://xrpl.org/tec-codes.html). (If you send at least 20 XRP, your transaction will successfully fund the account instead.) You should **not automatically re-send** payments that failed with these codes, because the second transaction is very likely to fail with the same error. In this case, you should check with the intended recipient for a different address that you should use instead. The typical way to handle these errors has not changed, but there are more circumstances where they can come up. + +If you try to look up the [account_info](https://xrpl.org/account_info.html) of an account that does not exist in the ledger version you've queried, the server responds with the error code `actNotFound`. This could mean the account has been deleted, or it did not exist to begin with. If you want to know if an account has ever existed, you can use the [account_tx method](https://xrpl.org/account_tx.html) on a full-history server. + +One of the prerequisites for deleting an account is that it must not be linked to any objects in the ledger. You don't need to worry about not being able to finish an [Escrow](https://xrpl.org/escrow.html), and the [issuer of a non-XRP currency](https://xrpl.org/issued-currencies-overview.html) won't go away as long as anyone holds a balance of that currency. + +Payment Channels are a little more complicated because channels that have been grandfathered in from before the [fixPayChanRecipientOwnerDir amendment went live on 2020-05-01](https://xrpl.org/blog/2020/two-fixes-enabled.html) don't actually block their destinations from being deleted. (All new payment channels created since then do.) If the destination of a grandfathered payment channel has been deleted, the following options are possible: + +- Someone can re-create the destination account by funding it with at least 20 XRP. +- The sender of the payment channel can request to close the channel, according to the normal restrictions. +- If the channel has an immutable expiration time or is already scheduled to close, you can wait for it to close and then remove the expired channel from the ledger as normal. + + +## Getting XRP back by deleting your extra accounts + +If you have any accounts on the XRP Ledger that you're not using, you may have up to 20 XRP locked up for the [reserve requirements](https://xrpl.org/reserves.html) for each of those accounts. (It's possible for an account to have less than 20 XRP if you've destroyed XRP to pay [transaction costs](https://xrpl.org/transaction-cost.html).) If your account meets the prerequisites, you can get most of the reserved XRP back by deleting your unused accounts. + +**The cost to delete an account is 5 XRP,** which is destroyed in the process of deleting the account. This cost protects the XRP Ledger from attacks where someone excessively creates accounts and then deletes them to get their XRP reserves back. If an account currently holds less than 5 XRP, it cannot be deleted. + +To delete an account, it must have _no_ [trust lines](https://xrpl.org/trust-lines-and-issuing.html), [Escrows](https://xrpl.org/escrow.html), or [Payment Channels](https://xrpl.org/payment-channels.html) in the ledger linked to it. If your account currently has any of these ledger objects, you may be able to delete the account _after_ removing some objects: + +- To remove a trust line, reset it to its default state. (0 limit, 0 balance, and no non-default settings.) +- To remove an Escrow, finish it (if the escrow is ready), or cancel it (if the escrow is expired). If it is a time-based escrow, you cannot remove it until its FinishAfter time has passed. +- To remove a PaymentChannel, close the channel. If the channel has unclaimed XRP, you may have to wait for the `SettleDelay` to expire after requesting to close the channel. + +If your account meets the requirements to be deleted, send an [AccountDelete transaction](https://xrpl.org/accountdelete.html) from that account. The `Destination` address in the transaction receives the deleted account's remaining XRP (after subtracting the destroyed XRP). If you are withdrawing to an account at an exchange or hosted wallet, don't forget to include your `DestinationTag` at that exchange. + + +## Next steps + +Stay tuned for updates on whether the DeletableAccounts amendment becomes enabled as expected, as well as the status of other amendments that are currently in voting such as the Checks amendment. + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/moving-devnet-to-vl.md b/content/blog/2020/moving-devnet-to-vl.md new file mode 100644 index 0000000000..87c2c8a601 --- /dev/null +++ b/content/blog/2020/moving-devnet-to-vl.md @@ -0,0 +1,70 @@ +--- +category: 2020 +date: 2020-08-10 +labels: + - Advisories +--- +# Moving Devnet to a Validator List + +Ripple plans to upgrade [the XRP Ledger Devnet](https://xrpl.org/parallel-networks.html) to use a recommended validator list like the ones used on the Testnet and Mainnet. Ripple also plans to reset the Devnet history and state at this time. If you operate a server on the XRP Ledger Devnet, or run software on the Devnet, you must upgrade your configuration to remain synced. + + + +## Background + +Ripple runs the Devnet as a way to preview and test upcoming XRP Ledger features. Until now, the Devnet has used a short, hard-coded list of trusted validators that every server must use to remain synced. Configurations with a different set of trusted validators may not be fork-safe, so the entire network has to coordinate adding or removing trusted validators from the list. + +Ripple plans to add more trusted validators to the Devnet before testing the upcoming [Negative UNL feature](https://www.xrpchat.com/topic/33072-suggestion-robustness-improvements/). A validator list site helps to coordinate adding more validators to servers' UNLs, and provides a test environment that more closely resembles the Testnet and Mainnet. + +Balances in the Devnet have no real-world value. To enforce this and to keep the Devnet a free place to run tests, Ripple resets the ledger state and history of the Devnet periodically. + + +## Actions Required + +Ripple plans to upgrade and reset its Devnet validators on Tuesday, 2020-08-11. After the upgrade, the way to [connect your server to the Devnet](https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html) will be to use a validator list site, as described below. + +If you had any Devnet accounts, balances, or in-ledger settings, you must re-create those accounts and settings. Use the [Devnet Faucet](https://xrpl.org/xrp-testnet-faucet.html) to fund new addresses with a new supply of Devnet Test XRP. + + +### Configuration Changes + +To connect to the Devnet after the update, complete the following steps: + +1. Add the new validator list and key to your `validators.txt`. + + [validator_list_sites] + https://vl.devnet.rippletest.net + + [validator_list_keys] + EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12 + + The `validators.txt` file defines a server's trusted validator settings. The [recommended installation](https://xrpl.org/install-rippled.html) places this file at `/etc/opt/ripple/validators.txt` by default. + +2. Remove or comment-out any other URLs in `[validator_list_sites]` and any other keys in `[validator_list_keys]`. If this server was previously connected to the devnet, **remove or comment out the `[validators]` stanza and any hard-coded validator public keys in that stanza**. + + For example: + + # # Old Hard-coded List of Devnet Validators + # [validators] + # n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c + # n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B + # n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD + # n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U + # n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd + # n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC + # n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS + +3. After changing your config, **restart** the `rippled` service. + + $ sudo systemctl restart rippled + + +## Next Steps + +Stay tuned to the [XRP Ledger Dev Blog](https://xrpl.org/blog/) for the upcoming release of version 1.6.0 of the core XRP Ledger server (`rippled`) and details about the upcoming tests of the Negative UNL feature. To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Other resources: + +- [XRP Ledger Dev Portal](https://xrpl.org/) +* [The Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/requirefullycanonicalsig-expected.md b/content/blog/2020/requirefullycanonicalsig-expected.md new file mode 100644 index 0000000000..45e5b6d477 --- /dev/null +++ b/content/blog/2020/requirefullycanonicalsig-expected.md @@ -0,0 +1,46 @@ +# The RequireFullyCanonicalSig Amendment is Expected 2020-07-03 + +The RequireFullyCanonicalSig amendment to the XRP Ledger, introduced in [`rippled` v1.5.0](https://github.com/ripple/rippled/releases/tag/1.5.0), has [gained support from a majority of trusted validators](https://xrpcharts.ripple.com/#/transactions/4DF3E28D6920D917CE0A0A9E341BC5F792B3584E2DD5E679BD7679FE0875AEE6). Currently, it is expected to become enabled on 2020-07-03 (UTC). As long as the RequireFullyCanonicalSig amendment continues to have the support of at least 80% of trusted validators continuously, it will become enabled on the scheduled date. + + + +## RequireFullyCanonicalSig Summary + +Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](https://xrpl.org/transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](https://xrpl.org/transaction-common-fields.html#global-flags) enabled. + +Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. + +With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](https://xrpl.org/transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. + + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.5.0 (or higher) by 2020-07-03, for service continuity. + +- If you use a custom or very old (pre-2014) tool for signing XRP Ledger transactions using secp256k1, check that your tool produces _fully canonical_ signatures. All valid Ed25519 signatures are fully canonical. If your tool produces secp256k1 signatures that are not fully canonical (see [Alternate secp256k1 signatures](https://xrpl.org/transaction-malleability.html#alternate-secp256k1-signatures) for details), you must update your tool to continue sending XRP Ledger transactions. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to version 1.5.0 (or higher) by 2020-07-03, when the RequireFullyCanonicalSig amendment is expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If the RequireFullyCanonicalSig amendment does not become enabled, then your server will not become amendment blocked and should continue to operate. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments) +* [Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/requirefullycanonicalsig-fixqualityupperbound-flowcross-enabled.md b/content/blog/2020/requirefullycanonicalsig-fixqualityupperbound-flowcross-enabled.md new file mode 100644 index 0000000000..1dc16a5cc2 --- /dev/null +++ b/content/blog/2020/requirefullycanonicalsig-fixqualityupperbound-flowcross-enabled.md @@ -0,0 +1,69 @@ +# RequireFullyCanonicalSig, fixQualityUpperBound, and FlowCross are Now Available + +[As previously announced](https://xrpl.org/blog/2020/requirefullycanonicalsig-expected.html), the **RequireFullyCanonicalSig** amendment [became enabled on the XRP Ledger](https://xrpcharts.ripple.com/#/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3) on 2020-07-03. Additionally, the **fixQualityUpperBound** amendment [became enabled](https://xrpcharts.ripple.com/#/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E) on 2020-07-09 and the **FlowCross** amendment [became enabled](https://xrpcharts.ripple.com/#/transactions/44C4B040448D89B6C5A5DEC97C17FEDC2E590BA094BC7DB63B7FDC888B9ED78F) on 2020-08-04. + +With these amendments enabled, **version 1.5.0 is the minimum** server version to remain synced to the XRP Ledger. + + + +## Action Required + +- If you operate a `rippled` server, you should upgrade to version 1.5.0 (or higher) immediately. + + For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + + **Note:** As of 2020-08-04, [version 1.6.0 is in the release candidate process](https://github.com/ripple/rippled/commit/7b048b423e8ae08a54018a89231d050b9f562855), so the full 1.6.0 release is expected in the near future. + +- If you use a custom or very old (pre-2014) tool for signing XRP Ledger transactions using secp256k1, check that your tool produces _fully canonical_ signatures. All valid Ed25519 signatures are fully canonical. If your tool produces secp256k1 signatures that are not fully canonical (see [Alternate secp256k1 signatures](https://xrpl.org/transaction-malleability.html#alternate-secp256k1-signatures) for details), you must update your tool to continue sending XRP Ledger transactions. + +- If you trade in the XRP Ledger's decentralized exchange, the FlowCross amendment requires no further action at this time. There may be some differences in rounding when executing OfferCreate transactions compared to before the amendment, but the overall functionality of the decentralized exchange is unchanged and the actual currency value of any differences is expected to be very, very small. + + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.5.0, then your server is now [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked), meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + + +## RequireFullyCanonicalSig Summary + +Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against [transaction malleability](https://xrpl.org/transaction-malleability.html) on _all_ transactions, instead of just transactions with the [tfFullyCanonicalSig flag](https://xrpl.org/transaction-common-fields.html#global-flags) enabled. + +Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. + +With this amendment, no single-signed transactions are malleable. ([Multi-signed transactions may still be malleable](https://xrpl.org/transaction-malleability.html#malleability-with-multi-signatures) if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. + +For more information, see [`rippled` issue #3042](https://github.com/ripple/rippled/issues/3042). + + +## fixQualityUpperBound Summary + +Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. + +Although this has no impact on current transaction processing, it [corrects a flaw in the flow cross engine](https://twitter.com/nbougalis/status/1273415169482223616). The fixQualityUpperBound was considered a prerequisite for the [FlowCross amendment](https://xrpl.org/known-amendments.html#flowcross) to be activated safely. + + +## FlowCross Summary + +Originally [introduced in `rippled` v0.70.0, back in 2017](https://xrpl.org/blog/2017/rippled-0.70.0.html), the Flow amendment streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. With FlowCross, [OfferCreate transactions](https://xrpl.org/offercreate.html) use the logic for Payment transactions, originally introduced by the [Flow](https://xrpl.org/known-amendments.html#flow) amendment. This has subtle differences in how offers are processed: + +- Rounding is slightly different in some cases. +- Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially. +- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.) + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [XRPScan Amendments Dashboard](https://xrpscan.com/amendments) +* [Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/rippled-1.4.0-upgrade-advisory.md b/content/blog/2020/rippled-1.4.0-upgrade-advisory.md new file mode 100644 index 0000000000..820c8e893a --- /dev/null +++ b/content/blog/2020/rippled-1.4.0-upgrade-advisory.md @@ -0,0 +1,74 @@ +# XRP Ledger version 1.4.0 Upgrade Advisory + +Version 1.4.0 of the XRP Ledger core server (`rippled`) contains a change that can cause upgrades to take much longer than usual. + +When upgrading to version 1.4.0, `rippled` automatically reorganizes its SQL databases to remove some unused data. This happens during startup the first time the server runs after upgrading to 1.4.0. The SQL reorganization should complete within 10 to 20 minutes for most servers. For servers that have been running for longer than a few months, the operation may take significantly longer. During this time, your server will not be usable. + +Plan accordingly for the time that this upgrade may take. + +If you currently use a single `rippled` server, consider instead running two or more independent `rippled` servers to avoid downtime while one server is being upgraded. (Do not run more than one validator.) + +## Database Reorganization Details + +Previous releases stored data in a "Validations" table in the SQLite data store. This data is not needed, so `rippled` 1.4.0 drops (deletes) the Validations table, if it exists. Dropping the Validations table can take many, many hours, depending on how large the Validations table is. This varies based on the server's configuration and how long it has been collecting past history. During this time, the rippled server is unable to operate or serve requests. + +If needed, a workaround is possible. However, we do not recommend this procedure if you are not familiar with sqlite3. + +## Workaround + +The following workaround can reduce `rippled`'s initial startup time after upgrading to version 1.4.0. It requires making changes to one of the SQL databases maintained by the server. Instead of deleting the unneeded data, this workaround renames the table. The old data continues to take up disk space on the server. + +**WARNING:** We do not recommend this procedure to anyone not familiar with sqlite3. + +1. Install the required tool: `sqlite3`. This is operating-system dependent. + + On Ubuntu you can use the following commands: + + sudo apt-get update + sudo apt-get install sqlite3 + +2. Stop your `rippled` instance. + + This is operating-system dependent. On Linux, you can use the following commands: + + sudo systemctl stop rippled.service + +3. Read your configuration file and find the `[database_path]` stanza. + + On Linux, the configuration file is usually located at `/opt/ripple/etc/rippled.cfg`. + + The directory in the `[database_path]` stanza is where your server stores its SQL databases. + +4. Change to a user that has permissions to read and write files in the SQL database directory you found in the previous step. + + On Linux, you can use the `sudo -i` command. + +5. Open the `ledger.db` file using the SQLite commandline: + + sqlite3 ledger.db + +6. Execute the following command (the trailing semicolon is required): + + ALTER TABLE Validations RENAME TO OldValidations; + +7. Execute the following command (the leading period is required): + + .quit + +8. You should now be able to start `rippled` without experiencing any delay. + + sudo systemctl start rippled.service + +For general instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The XRP Ledger Dev Blog](https://xrpl.org/blog/) +* Ripple Technical Services: +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/rippled-1.5.0.md b/content/blog/2020/rippled-1.5.0.md new file mode 100644 index 0000000000..1e0827aa60 --- /dev/null +++ b/content/blog/2020/rippled-1.5.0.md @@ -0,0 +1,150 @@ +# Introducing XRP Ledger version 1.5.0 + +**XRP Ledger (`rippled` server) version 1.5.0** has been released. The `rippled` 1.5.0 release introduces several improvements and new features, including support for gRPC API, API versioning, UNL propagation via the peer network, new RPC methods `validator_info` and `manifest`, augmented `submit` method, improved `tx` method, improved CLI parsing, improved protocol-level handshaking protocol, improved package building and various other minor bug fixes and improvements. + + + +## Action Required + +This release introduces two new amendments: `fixQualityUpperBound` and `RequireFullyCanonicalSig`. These amendments are now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), which enables protocol changes following two weeks of >80% support from trusted validators. + +**If you operate an XRP Ledger server,** then you should upgrade to version 1.5.0 by 2020-04-13, to ensure service continuity. The exact time that protocol changes take effect could be on that date or later, depending on the voting decisions of the decentralized network. + +If you operate an XRP Ledger validator, please [learn more about these amendments](https://xrpl.org/known-amendments.html) so you can make informed decisions about if and when your validator should [support them](https://xrpl.org/amendments.html#configuring-amendment-voting). If you take no action, your validator begins voting in favor of the new amendments as soon as it has been upgraded. + +### Impact of Not Upgrading + +When one or both of the new amendments become enabled, any server on a version earlier than 1.5.0 will become [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked), meaning that it: + +* Cannot determine the validity of a ledger; +* Cannot submit or process transactions; +* Cannot participate in the consensus process; +* Cannot vote on future amendments; and +* Could rely on potentially invalid data. + +If the amendments do not become enabled, then your XRP Ledger server will not become amendment blocked and should continue to operate. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see here: + +- [Install `rippled`](https://xrpl.org/install-rippled.html) + +The SHA-256 hashes for the official packages are as follows: + +| Package | SHA-256 | +|:--------|:--------| +| [Red Hat RPM (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.5.0-1.el7.x86_64.rpm) | `fe6b5ba0958fd4531a917af4ba58efecf51c951e534f06e025a684c2777aa7f8` | +| [Ubuntu DEB (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.5.0-1_amd64.deb) | `4ed13ab7cd65fcfe95d2ea85522414509b13e49f8a1633ac51b3457974cad6c6` | + +For other platforms, please compile version 1.5.0 from source. + +* [Build on Ubuntu Linux](https://xrpl.org/build-run-rippled-ubuntu.html) + +* [Build on macOS](https://xrpl.org/build-run-rippled-macos.html) + +* [Build on other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + +```text +commit f00f263852c472938bf8e993e26c7f96f435935c +Author: Carl Hua +Date: Mon Mar 30 13:59:28 2020 -0400 + + Set version to 1.5.0 +``` + +## Learn, ask questions, and discuss + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org), including detailed example API calls and web tools for API testing, at . + +Other resources: + +- [XRP Chat Forum](http://www.xrpchat.com/) +- [Xpring Forum](https://forum.xpring.io/) + + +## Other Information + +### Bug Bounties and Responsible Disclosures + +As always, Ripple welcomes reviews of the **XRP Ledger** open source codebase and urges reviewers to responsibly disclose any issues that they may find. For more on Ripple's Bug Bounty program, please visit . + +### Compilation Requirements & Compatibility + +Compiling `rippled` 1.5.0 from source on any platform requires a compiler that supports the C++17 ISO standard and a compatible edition of the [Boost](https://www.boost.org/) C++ libraries. Version 1.5.0 of `rippled` is compatible with **Boost versions 1.70.0 through 1.72.0**. + +## 1.5.0 Change Log + +### New and Updated Features + +- The `RequireFullyCanonicalSig` amendment which changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled. Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions. With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014. For more information. [`ec137044a`](https://github.com/ripple/rippled/commit/ec137044a014530263cd3309d81643a5a3c1fdab) +- Native [gRPC API](https://grpc.io/) support. Currently, this API provides a subset of the full `rippled` [API](https://xrpl.org/rippled-api.html). You can enable the gRPC API on your server with a new configuration stanza. [`7d867b806`](https://github.com/ripple/rippled/commit/7d867b806d70fc41fb45e3e61b719397033b272c) +- API Versioning which allows for future breaking change of RPC methods to co-exist with existing versions. [`2aa11fa41`](https://github.com/ripple/rippled/commit/2aa11fa41d4a7849ae6a5d7a11df6f367191e3ef) +- Nodes now receive and broadcast UNLs over the peer network under various conditions. [`2c71802e3`](https://github.com/ripple/rippled/commit/2c71802e389a59118024ea0152123144c084b31c) +- Augmented `submit` method to include additional details on the status of the command. [`79e9085dd`](https://github.com/ripple/rippled/commit/79e9085dd1eb72864afe841225b78ec96e72b5ca) +- Improved `tx` method response with additional details on ledgers searched. [`47501b7f9`](https://github.com/ripple/rippled/commit/47501b7f99d4103d9ad405e399169fc251161548) +- New `validator_info` method which returns information pertaining to the current validator's keys, manifest sequence, and domain. [`3578acaf0`](https://github.com/ripple/rippled/commit/3578acaf0b5f2d27ddc33f5b4cc81d21be1903ae) +- New `manifest` method which looks up manifest information for the specified key (either master or ephemeral). [`3578acaf0`](https://github.com/ripple/rippled/commit/3578acaf0b5f2d27ddc33f5b4cc81d21be1903ae) +- Introduce handshake protocol for compression negotiation (compression is not implemented at this point) and other minor improvements. [`f6916bfd4`](https://github.com/ripple/rippled/commit/f6916bfd429ce654e017ae9686cb023d9e05408b) +- Remove various old conditionals introduced by amendments. [`(51ed7db00`](https://github.com/ripple/rippled/commit/51ed7db0027ba822739bd9de6f2613f97c1b227b), [`6e4945c56)`](https://github.com/ripple/rippled/commit/6e4945c56b1a1c063b32921d7750607587ec3063) +- Add `getRippledInfo` info gathering script to `rippled` Linux packages. [`acf4b7889`](https://github.com/ripple/rippled/commit/acf4b78892074303cb1fa22b778da5e7e7eddeda) + +### Bug Fixes + +- The `fixQualityUpperBound` amendment which fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments. [`9d3626fec`](https://github.com/ripple/rippled/commit/9d3626fec5b610100f401dc0d25b9ec8e4a9a362) +- `tx` method now properly fetches all historical tx if they are incorporated into a validated ledger under rules that applied at the time. [`11cf27e00`](https://github.com/ripple/rippled/commit/11cf27e00698dbfc099b23463927d1dac829ed19) +- Fix to how `fail_hard` flag is handled with the `submit` method - transactions that are submitted with the `fail_hard` flag that result in any TER code besides tesSUCCESS are neither queued nor held. [`cd9732b47`](https://github.com/ripple/rippled/commit/cd9732b47a9d4e95bcb74e048d2c76fa118b80fb) +- Remove unused `Beast` code. [`172ead822`](https://github.com/ripple/rippled/commit/172ead822159a3c1f9b73217da4316df48851ab6) +- Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys.[`6529d3e6f`](https://github.com/ripple/rippled/commit/6529d3e6f7333fc5226e5aa9ae65f834cb93dfe5) + + +## Contributions + +### GitHub +[![GitHub: Stars](https://img.shields.io/github/stars/ripple/rippled.svg)](https://img.shields.io/github/stars/ripple/rippled.svg) +[![GitHub: Watchers](https://img.shields.io/github/watchers/ripple/rippled.svg)](https://img.shields.io/github/watchers/ripple/rippled.svg) + +The public git repository for `rippled` is hosted on GitHub: + + + +We welcome contributions, big and small, and invite everyone to join the community +of XRP Ledger developers and help us build the Internet of Value. + +### Credits + +The following people contributed directly to this release: + +- Carl Hua +- CJ Cobb +- Devon White +- Edward Hennis +- Elliot Lee +- Howard Hinnant +- Jeroen Meulemeester +- John Freeman +- John Northrup +- Manoj doshi +- Mark Travis +- mbhandary +- Miguel Portilla +- Mike Ellery +- Mo Morsi +- Nik Bougalis +- p2peer +- Peng Wang +- Scott Schurr +- seelabs +- ShangyanLi + +#### Lifetime Contributors + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.5.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Casey Bodley, Christian Ramseier, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Teufelberger, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, Patrick Dehne, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA. + +For a real-time view of all contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: . + +As XRP Ledger continues to move through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2020/rippled-1.6.0.md b/content/blog/2020/rippled-1.6.0.md new file mode 100644 index 0000000000..839948be97 --- /dev/null +++ b/content/blog/2020/rippled-1.6.0.md @@ -0,0 +1,285 @@ +--- +category: 2020 +date: 2020-08-19 +labels: + - rippled Release Notes +--- +# Introducing XRP Ledger version 1.6.0 + +**XRP Ledger (`rippled` server) version 1.6.0** has been released. This release introduces several new features including changes to the XRP Ledger's consensus mechanism to make it even more robust in adverse conditions, as well as numerous bug fixes and optimizations. _(This post has been updated with recommendations for upgrading.)_ + + + +## Action Required + +This release introduces three new amendments to the XRP Ledger protocol: fixAmendmentMajorityCalc, HardenedValidations, and fix1781. These amendments are now **open for voting** according to the XRP Ledger's [amendment process](https://xrpl.org/amendments.html), which enables protocol changes following two weeks of >80% support from trusted validators. + +**If you operate an XRP Ledger server,** then you should upgrade to version 1.6.0 by 2020-09-02, to ensure service continuity. The exact time that protocol changes take effect could be on that date or later, depending on the voting decisions of the decentralized network. + +If you operate an XRP Ledger validator, please [learn more about these amendments](https://xrpl.org/known-amendments.html) so you can make informed decisions about if and when your validator should [support them](https://xrpl.org/amendments.html#configuring-amendment-voting). If you take no action, your validator begins voting in favor of the new amendments as soon as it has been upgraded. + +### Upgrading + +For instructions on updating XRP Ledger on supported platforms, see here: + +- [Install `rippled`](https://xrpl.org/install-rippled.html) + +The SHA-256 hashes for the official packages are as follows: + +| Package | SHA-256 | +|:--------|:--------| +| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-1.6.0-1.el7.x86_64.rpm) | `894d1a7a4713bfbf16264dbef9e0958a25572e0f1fce588d5a8c00452fb68115` | +| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_1.6.0-1_amd64.deb) | `1d29124623bd81ba6eaf8a74bf7e14a18c511312d29213bfa6dc3351d30eedba` | + +For other platforms, please compile version 1.6.0 from source. + +* [Build on Ubuntu Linux](https://xrpl.org/build-run-rippled-ubuntu.html) + +* [Build on macOS](https://xrpl.org/build-run-rippled-macos.html) + +* [Build on other platforms](https://github.com/ripple/rippled/tree/master/Builds) + +The first log entry should be the change setting the version: + +```text +commit 01bd5a2646cda78ee09d2067c287c8f89872736d +Author: manojsdoshi +Date: Tue Aug 18 15:32:50 2020 -0700 + + Set version to 1.6.0 +``` + +## Change Summary + +### New and Improved Features + +- **Initial implementation of Negative UNL functionality:** This change can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match. This change requires an amendment, but the amendment is not in the **1.6.0** release. Ripple expects to run extensive public testing for Negative UNL functionality on the Devnet in the coming weeks. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included in a version 2.0 release. [[#3380](https://github.com/ripple/rippled/pull/3380)] + +- **Validation Hardening:** This change allows servers to detect accidental misconfiguration of validators, as well as potentially Byzantine behavior by malicious validators. Servers can now log a message to notify operators if they detect a single validator issuing validations for multiple, incompatible ledger versions, or validations from multiple servers sharing a key. As part of this update, validators report the version of `rippled` they are using, as well as the hash of the last ledger they consider to be fully validated, in validation messages. [[#3291](https://github.com/ripple/rippled/pull/3291)] ![Amendment: Required](https://img.shields.io/badge/Amendment-Required-red) + +- **Software Upgrade Monitoring & Notification:** After the `HardenedValidations` amendment is enabled and the validators begin reporting the versions of `rippled` they are running, a server can check how many of the validators on its UNL run a newer version of the software than itself. If more than 60% of a server's validators are running a newer version, the server writes a message to notify the operator to consider upgrading their software. [[#3447](https://github.com/ripple/rippled/pull/3447)] + +- **Link Compression:** Beginning with **1.6.0**, server operators can enable support for compressing peer-to-peer messages. This can save bandwidth at a cost of higher CPU usage, which should prove useful for servers with a large number of peers. This support is disabled by default and can be enabled in your server's config file. [[#3287](https://github.com/ripple/rippled/pull/3287)] + +- **Unconditionalize Amendments that were enabled in 2017:** This change removes legacy code which the network has not used since 2017. This change limits the ability to [replay](https://github.com/xrp-community/standards-drafts/issues/14) ledgers that rely on the pre-2017 behavior. [[#3292](https://github.com/ripple/rippled/pull/3292)] + +- **New Health Check Method:** Perform a simple HTTP request to get a summary of the health of the server: Healthy, Warning, or Critical. [[#3365](https://github.com/ripple/rippled/pull/3365)] + +- **Start work on API version 2.** Version 2 of the API will be part of a future release. The first breaking change will be to consolidate several closely related error messages that can occur when the server is not synced into a single "notSynced" error message. [[#3269](https://github.com/ripple/rippled/pull/3269)] + +- **Improved shard concurrency:** Improvements to the shard engine have helped reduce the lock scope on all public functions, increasing the concurrency of the code. [[#3251](https://github.com/ripple/rippled/pull/3251)] + +- **Default Port:** In the config file, the `[ips_fixed]` and `[ips]` stanzas now use the [IANA-assigned port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2459) for the XRP Ledger protocol (2459) when no port is specified. The `connect` API method also uses the same port by default. [[#2861](https://github.com/ripple/rippled/pull/2861)]. + +- **Improve proposal and validation relaying**. The peer-to-peer protocol always relays trusted proposals and validations (as part of the [consensus process](https://xrpl.org/consensus.html)), but only relays _untrusted_ proposals and validations in certain circumstances. This update adds configuration options so server operators can fine-tune how their server handles untrusted proposals and validations, and changes the default behavior to prioritize untrusted validations higher than untrusted proposals. [[#3391](https://github.com/ripple/rippled/pull/3391)] + +- **Various Build and CI Improvements** including updates to RocksDB 6.7.3 [[#3356](https://github.com/ripple/rippled/pull/3356)], NuDB 2.0.3 [[#3437](https://github.com/ripple/rippled/pull/3437)], adjusting CMake settings so that rippled can be built as a submodule [[#3449](https://github.com/ripple/rippled/pull/3449)], and adding Travis CI settings for Ubuntu Bionic Beaver [[#3319](https://github.com/ripple/rippled/pull/3319)]. + +- **Better documentation in the config file** for online deletion and database tuning. [[#3429](https://github.com/ripple/rippled/pull/3429)] + + +### Bug Fixes + +- Fix the 14 day timer to enable amendment to start at the correct quorum size [[#3396](https://github.com/ripple/rippled/pull/3396)] +- Improve online delete backend lock which addresses a possibility in the online delete process where one or more backend shared pointer references may become invalid during rotation. [[#3342](https://github.com/ripple/rippled/pull/3342)] +- Address an issue that can occur during the loading of validator tokens, where a deliberately malformed token could cause the server to crash during startup. [[#3326](https://github.com/ripple/rippled/pull/3326)] +- Add delivered amount to GetAccountTransactionHistory. The delivered_amount field was not being populated when calling GetAccountTransactionHistory. In contrast, the delivered_amount field was being populated when calling GetTransaction. This change populates delivered_amount in the response to GetAccountTransactionHistory, and adds a unit test to make sure the results delivered by GetTransaction and GetAccountTransactionHistory match each other. [[#3370](https://github.com/ripple/rippled/pull/3370)] +- Fix build issues for GCC 10 [[#3393](https://github.com/ripple/rippled/pull/3393)] +- Fix historical ledger acquisition - this fixes an issue where historical ledgers were acquired only since the last online deletion interval instead of the configured value to allow deletion.[[#3369](https://github.com/ripple/rippled/pull/3369)] +- Fix build issue with Docker [#3416](https://github.com/ripple/rippled/pull/3416)] +- Add Shard family. The App Family utilizes a single shared Tree Node and Full Below cache for all history shards. This can create a problem when acquiring a shard that shares an account state node that was recently cached from another shard operation. The new Shard Family class solves this issue by managing separate Tree Node and Full Below caches for each shard. [#3448](https://github.com/ripple/rippled/pull/3448)] +- Amendment table clean up which fixes a calculation issue with majority. [#3428](https://github.com/ripple/rippled/pull/3428)] +- Add the `ledger_cleaner` command to rippled command line help [[#3305](https://github.com/ripple/rippled/pull/3305)] +- Various typo and comments fixes. + + + + +## New Commits in This Release + +- [`2b4486837`](https://github.com/ripple/rippled/commit/2b448683736398faa4e58d8f386c32356ad1d3c2) Set version to 1.6.0-rc3 +- [`f79a4a8cd`](https://github.com/ripple/rippled/commit/f79a4a8cdb6ede5dea2753129586fb78307a5f80) Revert "Remove CryptoConditionsSuite stub amendment:" +- [`7bb6b75f3`](https://github.com/ripple/rippled/commit/7bb6b75f3c8b31d00b4800b880c90ce63c287f54) Use the correct root hash for the tx tree +- [`e5d17a945`](https://github.com/ripple/rippled/commit/e5d17a945213eb154912cfe4d8ea2417ea87f03a) Set version to 1.6.0-rc2 +- [`dbd5f0073`](https://github.com/ripple/rippled/commit/dbd5f0073e34bdead616ab30ae4db413363d9c4e) Revert support for deterministic shards: +- [`12c0e8148`](https://github.com/ripple/rippled/commit/12c0e8148bf1d3726bdd2d072f23c769bbe1a607) Improve naming of fields associated with the NegativeUNL +- [`72a9a2bdb`](https://github.com/ripple/rippled/commit/72a9a2bdbb82354446bd0a14d45fd42a35c70ba2) Reorder the Travis build: +- [`80860fa8f`](https://github.com/ripple/rippled/commit/80860fa8f574dba6ed2a3daeff1efaf402ca3ccf) Add preliminary support for Boost 1.74 +- [`8cf542abb`](https://github.com/ripple/rippled/commit/8cf542abb04bdb58932adb7b67a6d7969b2fd789) Fix memory management issues with checkpointers: +- [`a931b020b`](https://github.com/ripple/rippled/commit/a931b020b5e8ed8ecc109e93c077554d68537f83) Switch to updated date library exception handling: +- [`d317060ae`](https://github.com/ripple/rippled/commit/d317060ae455dd31251bfe5d7d391c9c72420cd3) Fix a race condition with TrustedPublisherServer: +- [`eee07a4f9`](https://github.com/ripple/rippled/commit/eee07a4f96255296d418a8e24cafeb93116b3342) Add missing cstdint include +- [`7b048b423`](https://github.com/ripple/rippled/commit/7b048b423e8ae08a54018a89231d050b9f562855) Set version to 1.6.0-rc1 +- [`a45920684`](https://github.com/ripple/rippled/commit/a459206848e8019d892b24e7c63fe4afef4a0ca4) Set version to 1.6.0-b9 +- [`3a3b0b4c1`](https://github.com/ripple/rippled/commit/3a3b0b4c14af67209dcf6fc757c0f488e5412344) Modify health check API +- [`de0c52738`](https://github.com/ripple/rippled/commit/de0c52738785de8bf837f9124da65c7905e7bb5a) Set version to 1.6.0-b8 +- [`b54453d1a`](https://github.com/ripple/rippled/commit/b54453d1a7f173e921c194c659264015568578d0) Fix a build issue caused by pip3 being unavailable +- [`706ca874b`](https://github.com/ripple/rippled/commit/706ca874b01d12a995dd8f914a713634878f1583) Implement negative UNL functionality: +- [`51bd4626b`](https://github.com/ripple/rippled/commit/51bd4626b191da7bd7ffea2a0ff08631fe41eae7) Implement version upgrade warning: +- [`cf6f40ea8`](https://github.com/ripple/rippled/commit/cf6f40ea8f4ddda2986d656d9ddeeb4904fe765d) Deprecate unused/obsolete error codes: +- [`d3798f629`](https://github.com/ripple/rippled/commit/d3798f62903df1bd24a5eb00a221963bf28f45f0) Remove CryptoConditionsSuite stub amendment: +- [`4e33a1abf`](https://github.com/ripple/rippled/commit/4e33a1abf72da95ce3e6f861c87c5f3719d70792) crawl_shards comment fix +- [`86e8f2e23`](https://github.com/ripple/rippled/commit/86e8f2e2324c79856bdb57e3af1fc81734163fe6) Add Shard Family +- [`91e857874`](https://github.com/ripple/rippled/commit/91e857874fdac6cf9dfee9f980ecdd7c0641921e) Improve LedgerMaster shard acquisition +- [`8f50fd051`](https://github.com/ripple/rippled/commit/8f50fd051e17c910d2d8026245d21ba35cda8f37) Use NuDB version 2.0.3 +- [`94e8e9475`](https://github.com/ripple/rippled/commit/94e8e94750e0b308b3ab2e342275d47a846618f1) Add support for deterministic database shards (#2688): +- [`54ece72b6`](https://github.com/ripple/rippled/commit/54ece72b621610d3b0975ab6a63688c2232d423e) Update cmake so that rippled can build as a submodule +- [`4702c8b59`](https://github.com/ripple/rippled/commit/4702c8b591ad2681eac402371a24cb824797f1fa) Improve online_delete configuration and DB tuning: +- [`00702f28c`](https://github.com/ripple/rippled/commit/00702f28c2f56f4f5a9d1a3dd60fdb7cf9d9c96f) Improve reporting of ledger age in server_info +- [`df29e98ea`](https://github.com/ripple/rippled/commit/df29e98ea51e762491ef8549e0e9b1932e16eea0) Improve amendment processing and activation logic: +- [`fe9922d65`](https://github.com/ripple/rippled/commit/fe9922d65428136508bd6e2f62ebe787029581b3) Improve compression support: +- [`362a017ee`](https://github.com/ripple/rippled/commit/362a017eee942a36e8ab8e44c7ff1c86bebe3456) Cleanup SHAMap and simplify interfaces: +- [`e8f352522`](https://github.com/ripple/rippled/commit/e8f35252262b9efd14c84909f29c81a1434a4451) Improve Slice: +- [`1067086f7`](https://github.com/ripple/rippled/commit/1067086f71b56d58b29aaa60884495721432d4ad) Consolidate "Not Synced" error messages: +- [`0214d83aa`](https://github.com/ripple/rippled/commit/0214d83aa5fd53bae81d9e66ddb30609d0055b76) Improve handling of empty buffer in varint parsing (RIPD-1683) +- [`d69a90287`](https://github.com/ripple/rippled/commit/d69a902876e72e958bb78ea078e396d6a5f88c4d) Add comments to protobuf files +- [`f43aeda49`](https://github.com/ripple/rippled/commit/f43aeda49c5362dc83c66507cae2ec71cfa7bfdf) Set version to 1.6.0-b7 +- [`27484f78a`](https://github.com/ripple/rippled/commit/27484f78a95aa8697dbaa9b898c86be941574dc7) Use libarchive version 3.4.3 +- [`93bf77bde`](https://github.com/ripple/rippled/commit/93bf77bdec1321d99a52042bb53cced186421d83) Unit tests for database shards +- [`728651b5d`](https://github.com/ripple/rippled/commit/728651b5d57d8b2c6c7e7c5dbbd5768f8d3a8556) Use LZ4_decompress_safe +- [`fb74eefa9`](https://github.com/ripple/rippled/commit/fb74eefa9edff66d002beb00fce07fcbf740f32d) Update LZ4 library to 1.9.2 +- [`853c96419`](https://github.com/ripple/rippled/commit/853c964194eab29781827100a0d05541b66df73e) Fix a build issue caused by the latest Docker version: * The latest docker version is not supported by artifactory causing the package build to fail. Setting the docker version to 19.03.8 to fix the build. +- [`645c06764`](https://github.com/ripple/rippled/commit/645c06764b84b8c02ea0449c92e9e2ead15f18d5) Update the default port for [ips] and [ips_fixed]: +- [`2d23e7bd1`](https://github.com/ripple/rippled/commit/2d23e7bd18f179844b838b01783307994f603a85) Use std::size in place of std::extent +- [`0290d0b82`](https://github.com/ripple/rippled/commit/0290d0b82c3dcd190d2ce9dad4985ee33d1f845a) Create health_check rpc +- [`3d86b49da`](https://github.com/ripple/rippled/commit/3d86b49dae8173344b39deb75e53170a9b6c5284) Set version to 1.6.0-b6 +- [`0b9e93580`](https://github.com/ripple/rippled/commit/0b9e935806e76e66b6c22cbd434d0ea49b54cf07) Find date::date in CMake package configuration file +- [`17412d17e`](https://github.com/ripple/rippled/commit/17412d17e205c860af1d28bb9fc7ee0e101c5145) Fix historical ledger acquisition when using online deletion: +- [`99f519369`](https://github.com/ripple/rippled/commit/99f5193699485f357721df9ae81fe0bd4bfabed7) Disable formatting operator&: +- [`328e42ad4`](https://github.com/ripple/rippled/commit/328e42ad4256597f5b448179aeb86dbb7ded130d) Minor cleanups: +- [`6d28f2a8d`](https://github.com/ripple/rippled/commit/6d28f2a8d9038715201915844007f40f63ed249f) Cleanup code using move semantics +- [`421417ab0`](https://github.com/ripple/rippled/commit/421417ab07757c5b417a971ad03cd79bd70f4cb5) Fixes for gcc 10 +- [`68494a308`](https://github.com/ripple/rippled/commit/68494a308e15c679af368afaebf96c15095470d1) AmendmentTable improvements +- [`16f79d160`](https://github.com/ripple/rippled/commit/16f79d160ac65cb6e4977571548475e1866f23a4) Add delivered amount to GetAccountTransactionHistory responses +- [`8f984042f`](https://github.com/ripple/rippled/commit/8f984042f42fc7f6f5f6427a77507ea8a4706d09) Try to fix usage of pkg-config for static linking +- [`eb1a699c5`](https://github.com/ripple/rippled/commit/eb1a699c5afb5f90d44b1ab0a8047c79538ea905) Fix typo in error message +- [`ac766ec0e`](https://github.com/ripple/rippled/commit/ac766ec0eb19e0e4345c4177f3f99aa285a916f2) Introduce ShardArchiveHandler improvements: +- [`21340a1c1`](https://github.com/ripple/rippled/commit/21340a1c1e092b6f444b6dda7cc0bb284dcd534d) Validate LastLedgerHash for downloaded shards: +- [`c594f3b0c`](https://github.com/ripple/rippled/commit/c594f3b0cf3833f97d307e76ef39199b2480927b) Reduce visibility of retired amendment identifiers: +- [`268e28a27`](https://github.com/ripple/rippled/commit/268e28a278b717a227e2e5398f69cb3628e04b73) Tune relaying of untrusted proposals & validations: +- [`ca664b17d`](https://github.com/ripple/rippled/commit/ca664b17d39ca747b619970f9b148127c73001bf) Improve handling of sfLedgerSequence field: +- [`3936110c8`](https://github.com/ripple/rippled/commit/3936110c8d93b48bdca7eca7ae6019d438d44260) Use boost::circular_buffer: +- [`9f91870b1`](https://github.com/ripple/rippled/commit/9f91870b1cd6b0c164f9073e1bec7cbdd218868b) Adjust frequency of mtENDPOINTS messages +- [`97712107b`](https://github.com/ripple/rippled/commit/97712107b71a8e2089d2e3fcef9ebf5362951110) Set version to 1.6.0-b5 +- [`d9fa14868`](https://github.com/ripple/rippled/commit/d9fa148688f468f7773219320d5d641852189fbe) Revert "Add PR automation for project boards" +- [`d88a7c73b`](https://github.com/ripple/rippled/commit/d88a7c73b48b895df27bf8fb8c9e081e798a68e4) Improve online delete backend locking +- [`894d3463c`](https://github.com/ripple/rippled/commit/894d3463ce95122b137d838d82380a9a4bbfe0ed) Extend unit testing of account_tx with deleted account: +- [`5b5226d51`](https://github.com/ripple/rippled/commit/5b5226d518aee7fd128053a71fd70ca0257f7453) Cleanup the 'PeerSet' hierarchy: +- [`d025f3fb2`](https://github.com/ripple/rippled/commit/d025f3fb2890296620ba2b1f19570cc5a9e3d466) Add descriptive comments to 'getRippledInfo.sh': +- [`11be30dd4`](https://github.com/ripple/rippled/commit/11be30dd40f2d9a177b340aa1de167f130fdeced) Correct typo in comment +- [`4fad421c8`](https://github.com/ripple/rippled/commit/4fad421c8af28de2de12e49e0f1897f9ea62824a) Correct typos in SECURITY.md +- [`57b3543e7`](https://github.com/ripple/rippled/commit/57b3543e7bad88885279784149e27e9084bbc6e8) Support boost 1.73 +- [`a00543b6b`](https://github.com/ripple/rippled/commit/a00543b6bc6255daf2c406f91c2a37d6de2cfbca) Fix docs about misconfigured neighbor port +- [`dbd25f0e3`](https://github.com/ripple/rippled/commit/dbd25f0e327f11a862a80a137e316a8871044c26) Remove excessive redirect call on PeerManager +- [`62a3f33d7`](https://github.com/ripple/rippled/commit/62a3f33d729dd50b91af81b4da81464d7aad2029) Remove the built-in "sustain" watchdog: +- [`74f9edef0`](https://github.com/ripple/rippled/commit/74f9edef079b8682969e3cd16715ad91334127a3) Prefer keylets instead of naked hashes: +- [`dbee3f01b`](https://github.com/ripple/rippled/commit/dbee3f01b7bde4b0b662cff454fc5e2fcc27beab) Clean up and modernize code: +- [`6c72d5cf7`](https://github.com/ripple/rippled/commit/6c72d5cf7e3b7afd7534df99781a1559857fd9f2) Improve loading of validator tokens (RIPD-1687): +- [`2827de4d6`](https://github.com/ripple/rippled/commit/2827de4d63d5f591addb1a16b87c1ecc23d102ba) Report the server version in published validations: +- [`381606aba`](https://github.com/ripple/rippled/commit/381606aba2efcd179517f2497dc6e8c2770c679e) Harden validations: +- [`567e42e07`](https://github.com/ripple/rippled/commit/567e42e071662720e15ed3d543f0a0341a2ac422) Deprecate 'Time to Live' fields +- [`2bf3b194f`](https://github.com/ripple/rippled/commit/2bf3b194faa23fab4c3f4c9ff263a84893269f78) Set version to 1.6.0-b4 +- [`444ea5618`](https://github.com/ripple/rippled/commit/444ea5618275a6f42806fe086a240c0294da8b28) Adding support to build rippled packages for ubuntu 20.04 +- [`d79758916`](https://github.com/ripple/rippled/commit/d79758916418e429f27ae6e150e098c0318baf51) Add README for gRPC protobuf folder +- [`1577c775b`](https://github.com/ripple/rippled/commit/1577c775b3011db9ffb80b4d2dbab5174b6965d3) Close download socket before result is passed to the callback: +- [`3bf0b724a`](https://github.com/ripple/rippled/commit/3bf0b724a3a9cc137a10279b8a4233779b8d31fb) Adjust timeouts in Validator Site tests: +- [`bd8dbb87b`](https://github.com/ripple/rippled/commit/bd8dbb87b6fbc5dd17563b475d65ac4efb1b0aad) Update to RocksBD 6.7.3 +- [`cd78ce311`](https://github.com/ripple/rippled/commit/cd78ce3118be1275efe7c306da92c74a35388aab) Add PR automation for project boards +- [`023f5704d`](https://github.com/ripple/rippled/commit/023f5704d07d09e70091f38a0d4e5df213a3144b) Set version to 1.6.0-b3 +- [`123e94c60`](https://github.com/ripple/rippled/commit/123e94c6039f854a5184957027c66e70965fd85a) Fix a build issue involving Ubuntu Docker containers: +- [`156dc2ec4`](https://github.com/ripple/rippled/commit/156dc2ec4c03c7e38882e9c915d38ccb2853c572) Add GitHub Action for checking w/ clang-format-10 +- [`b7b7e098b`](https://github.com/ripple/rippled/commit/b7b7e098bea6e39e05302707e90782cb938b6f3a) Add .git-blame-ignore-revs (requires Git >= 2.24) +- [`50760c693`](https://github.com/ripple/rippled/commit/50760c693510894ca368e90369b0cc2dabfd07f3) Format first-party source according to .clang-format +- [`65dfc5d19`](https://github.com/ripple/rippled/commit/65dfc5d19e80b398e8780c42bc2f951e88059b43) Prepare code for formatting +- [`020b28580`](https://github.com/ripple/rippled/commit/020b28580816a295185aef8832a8fe07ecc40de2) Set version to 1.6.0-b2 +- [`bdd22e4d5`](https://github.com/ripple/rippled/commit/bdd22e4d513d91071945204952a499e2478f926c) Improve reporting of missing node exceptions +- [`b7631d2a2`](https://github.com/ripple/rippled/commit/b7631d2a280cbb1a4e512181c7dd3b061f806a3c) Correct a typo that could result in a nullptr dereference +- [`284ed3847`](https://github.com/ripple/rippled/commit/284ed38471c0e1c26dc217b4d88c3736c8c77faf) Reduce calls to std::random_device: +- [`b96ef6adb`](https://github.com/ripple/rippled/commit/b96ef6adb8e68b922e3912bc5918417ebc08a716) Add SECURITY.md to the repository +- [`ce6b42720`](https://github.com/ripple/rippled/commit/ce6b4272021bfc85c256ab064deaf25dcfa2381e) Fix a build issue involving Ubuntu Docker containers: +- [`858e93c7f`](https://github.com/ripple/rippled/commit/858e93c7f8e8c891f1e98fbcf683181fae016960) Improve the Doxygen Workflow +- [`6477bdf3e`](https://github.com/ripple/rippled/commit/6477bdf3e85e027b489bc7e744894326a8ca6f92) Fix division by zero with shards file stats +- [`ce5f24055`](https://github.com/ripple/rippled/commit/ce5f240551a2802cb74bef678107cc5f28a696b4) Fix invalid shard removal +- [`1c3c69f8b`](https://github.com/ripple/rippled/commit/1c3c69f8b5d4c97f1e410db8458dc2da88814e5f) Update Travis to bionic +- [`be2652544`](https://github.com/ripple/rippled/commit/be2652544b4ed899ba1012398f470142ed969583) Add ledger_cleaner command to rippled cmd line help +- [`f155eaff4`](https://github.com/ripple/rippled/commit/f155eaff4bd3029c294985560bf2575528380e9e) Unit test for memo +- [`67981f002`](https://github.com/ripple/rippled/commit/67981f002fae229cbd54e01440740b4b130f91e1) Reduce strand re-execute log message severity to warning: +- [`0d8322344`](https://github.com/ripple/rippled/commit/0d83223445086ad5ff91911d8045e3a07c1f6007) Remove conditionals for fix1201 enabled 14Nov2017 +- [`9f8d64851`](https://github.com/ripple/rippled/commit/9f8d648514128c58798bb0c8fb85de317b750722) Remove conditionals for fix1512 enabled 14Nov2017 +- [`3d3b6d85c`](https://github.com/ripple/rippled/commit/3d3b6d85cd499865edf3999b0ca916ca4d773baa) Remove conditionals for fix1523 enabled 14Nov2017 +- [`8cf7c9548`](https://github.com/ripple/rippled/commit/8cf7c9548a06944fc128d88f01d213aec3d1102f) Remove conditionals for fix1528 enabled 14Nov2017 +- [`323dbc796`](https://github.com/ripple/rippled/commit/323dbc79623184f7cb44d3095957b5fce7cb983d) Remove conditionals for featureSortedDirectories enabled 14Nov2017 +- [`46a76fb31`](https://github.com/ripple/rippled/commit/46a76fb3188f5cebcf875010750bd805c5a6c102) Remove conditionals for featureEnforceInvariants enabled 07Jul2017 +- [`a6246b0ba`](https://github.com/ripple/rippled/commit/a6246b0baaf33dc522fe8ef0079b0f4e09bd19c8) Remove conditionals for fix1373 enabled 07Jul2017 +- [`c8282795e`](https://github.com/ripple/rippled/commit/c8282795ef9404b83e4d4c4d6f27f1127c5fad8d) Remove conditionals for featureEscrow enabled 31Mar2017 +- [`e93a44fe9`](https://github.com/ripple/rippled/commit/e93a44fe9bd44f3b4d6b886831b0cc7f061e9cbf) Remove conditionals for fix1368 enabled 31Mar2017 +- [`3e870866e`](https://github.com/ripple/rippled/commit/3e870866e0c89e315580aa4478d1401f60da19d0) Remove conditionals for featurePayChan enabled 31Mar2017 +- [`78d771af3`](https://github.com/ripple/rippled/commit/78d771af3670438089730af591bb5adaed386c30) Remove conditionals for featureTickSize enabled 21Feb2017 +- [`6bb9dd22e`](https://github.com/ripple/rippled/commit/6bb9dd22e06a627b75b45cdd9bd78c6592a7d910) Remove conditionals for featureCryptoConditions enabled 03Jan2017 +- [`1661c84af`](https://github.com/ripple/rippled/commit/1661c84af6776ad3146474d891b272f1a0d8561c) Remove unused featureCompareFlowV1V2 +- [`4f422f6f3`](https://github.com/ripple/rippled/commit/4f422f6f393b12d5aaba11fb65c33b7885891906) Setting version to 1.6.0-b1 +- [`393ca8757`](https://github.com/ripple/rippled/commit/393ca87572ef46bd7ee34b3cbf205afde4c25f38) Change the location for the project signer public keys: +- [`f4c56cbd5`](https://github.com/ripple/rippled/commit/f4c56cbd53b8352a4ec4633102af08019be959a3) Update SHAMap Documentation +- [`9470558ec`](https://github.com/ripple/rippled/commit/9470558ecc5fd1a33810e6ff9a0084e9a3c0e7fa) Remove all uses of the name scoped_lock +- [`f22fcb3b2`](https://github.com/ripple/rippled/commit/f22fcb3b2a510d6ae982834cc43c137ced31e6fe) Rename canonicalize into two functions: +- [`e257a226f`](https://github.com/ripple/rippled/commit/e257a226f367b8ad5c706512d39578194c9b7dc2) Maintain history back to the earliest persisted ledger: +- [`a4e987879`](https://github.com/ripple/rippled/commit/a4e9878790c4c2153dde7b37e3f32ad71aa6edb8) Document the 'devnet' network identifier setting: +- [`25b13978e`](https://github.com/ripple/rippled/commit/25b13978e78fe58219d6e7647ba3661b9289c4de) Fix unity build +- [`3e9cff928`](https://github.com/ripple/rippled/commit/3e9cff92873003c5b98b1c137d6914394b0c6ed1) Fix Doxygen build +- [`758a3792e`](https://github.com/ripple/rippled/commit/758a3792ebcd877a42f87f8f81a4d14fd68aad68) Add protocol message compression support: +- [`ade5eb71c`](https://github.com/ripple/rippled/commit/ade5eb71cf7e2d0316dfe2f1723206bd152915ca) Fix unneeded copies in range some range for loops: +- [`d097819c5`](https://github.com/ripple/rippled/commit/d097819c528da21791388ba80a8cf399adf38eb3) Check XRP endpoints for circular paths (RIPD-1781): +- [`905a97e0a`](https://github.com/ripple/rippled/commit/905a97e0aa02d0c6e1cf198e78c03ff66e282f4f) Make ShardArchiveHandler downloads more resilient: +- [`cc452dfa9`](https://github.com/ripple/rippled/commit/cc452dfa9b636e0656f327db72db70f1b2c46c23) Improve shard concurrency: + +## Contributions + +### GitHub +[![GitHub: Stars](https://img.shields.io/github/stars/ripple/rippled.svg)](https://img.shields.io/github/stars/ripple/rippled.svg) +[![GitHub: Watchers](https://img.shields.io/github/watchers/ripple/rippled.svg)](https://img.shields.io/github/watchers/ripple/rippled.svg) + +The public git repository for `rippled` is hosted on GitHub: + + + +We welcome contributions, big and small, and invite everyone to join the community +of XRP Ledger developers and help us build the Internet of Value. + +### Credits + +The following people contributed directly to this release: + +- Alloy Networks +- Carl Hua +- CJ Cobb +- Devon White +- Edward Hennis +- Elliot Lee +- Gábor Lipták +- Gregory Tsipenyuk +- Howard Hinnant +- John Freeman +- Kirill Fomichev +- Manoj Doshi +- Mark Travis +- Markus Alvila +- Miguel Portilla +- Mo Morsi +- Nik Bougalis +- p2peer +- Peng Wang +- rabbit (Rabbit Kick Club) +- Rome Reginelli +- Scott Schurr +- Scott Determan +- Yusuf Sahin HAMZA + +#### Lifetime Contributors + +The following is the list of people who made code contributions, large and small, to XRP Ledger prior to the release of 1.6.0: + +Aishraj Dahal, Alex Chung, Alex Dupre, Alloy Networks, Andrey Fedorov, Arthur Britto, Bharath Chari, Bob Way, Brad Chase, Brandon Wilson, Bryce Lynch, Carl Hua, Casey Bodley, Christian Ramseier, CJ Cobb, crazyquark, Crypto Brad Garlinghouse, David Grogan, David 'JoelKatz' Schwartz, Devon White, Donovan Hide, Edward Hennis, Elliot Lee, Eric Lombrozo, Ethan MacBrough, Evan Hubinger, Frank Cash, Gábor Lipták, Gregory Tsipenyuk, Howard Hinnant, Ian Roskam, invalidator, Jack Bond-Preston, James Fryman, jatchili, Jcar, Jed McCaleb, Jeff Trull, Jeroen Meulemeester, Jesper Wallin, Joe Loser, Johanna Griffin, John Freeman, John Northrup, Joseph Busch, Josh Juran, Justin Lynn, Keaton Okkonen, Kirill Fomichev, Lazaridis, Lieefu Way, Luke Cyca, Manoj Doshi, Mark Travis, Markus Alvila, Markus Teufelberger, Mayur Bhandary, Miguel Portilla, Mike Ellery, MJK, Mo Morsi, Nicholas Dudfield, Nikolaos D. Bougalis, Niraj Pant, p2peer, Patrick Dehne, Peng Wang, Roberto Catini, Rome Reginelli, Scott Determan, Scott Schurr, S. Matthew English, Stefan Thomas, ShangyanLi, The Gitter Badger, Ties Jan Hefting, Tim Lewkow, Tom 'Swirly' Ritchford, Torrie Fischer, Vahe Hovhannisyan, Vinnie Falco, Vishwas Patil, Warren Paul Anderson, Will, wltsmrz, Wolfgang Spraul, Yana Novikova and Yusuf Sahin HAMZA. + +For a real-time view of all contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: . + +As XRP Ledger continues to move through the 1.0 series, we look forward to more external contributions and are excited to see the broader XRP Ledger community grow and thrive. diff --git a/content/blog/2020/running-an-xrp-ledger-validator.md b/content/blog/2020/running-an-xrp-ledger-validator.md new file mode 100644 index 0000000000..8737df6571 --- /dev/null +++ b/content/blog/2020/running-an-xrp-ledger-validator.md @@ -0,0 +1,43 @@ +--- +category: 2020 +date: 2021-02-07 +labels: + - Features +--- +# Running an XRP Ledger Validator +_by Mayur Bhandary, Software Engineer at Ripple_ + +Validators are the lifeblood of the XRP Ledger. This post seeks to explain the function and importance of validators on the XRP Ledger network. + + + +## Background + +Like all decentralized ledgers, the XRP Ledger is a program that lives on a distributed set of servers. These servers run a program called [`rippled`](https://github.com/ripple/rippled). Every server can follow the network with a local copy of the ledger and submit transactions to the network. A smaller subset of servers contribute to the consensus process that helps to maintain forward progress of the network. These servers are called validators. Any server that runs rippled can operate as a validator by [enabling validation](https://xrpl.org/run-rippled-as-a-validator.html). + +Validators agree on the set of the candidate transactions to be considered for the next ledger through the [consensus process](https://xrpl.org/consensus.html). Each validator evaluates transaction proposals from a specific set of trusted validators called a Unique Node List (UNL). Validators that appear on a UNL are "trusted" not to collude in an attempt to defraud the server evaluating the proposals. In each round of consensus, validators add transactions to their proposals if a threshold number of trusted validators also propose those transactions. The threshold is increased until a supermajority of validators propose the same set of transactions. + +Finally, every rippled server independently computes a new ledger version with the new set of transactions. Validators broadcast the hash of the new ledger version to all rippled servers, and if a supermajority of a server’s trusted validators computes the same hash, then the ledger version is considered fully validated. + + +## Why Run a Validator + +Those who operate validators do so because they have a demonstrated interest in the long term health of the network. For example, individuals and entities that rely on XRP for their business operations, all stand to benefit from the continued reliability, stability and performance of the XRP Ledger. + +For those more familiar with crypto, the rationale for running a validator is similar to why someone would run a [Bitcoin Full Node](https://bitcoin.org/en/full-node): by contributing to the ecosystem, one hopes that it will continue to thrive and grow. + +Validator operators that appear on a UNL also partake in the governance of the XRP Ledger through voting on fees and amendments, which are proposed changes to the protocol. + + +## Being a Good Validator + +The characteristics of a good validator include high availability, agreement with the network, timeliness, and identification. In order to achieve these properties, it is important to adhere to the [recommended system specifications](https://xrpl.org/system-requirements.html#recommended-specifications) for production servers and [properly configure](https://xrpl.org/run-rippled-as-a-validator.html) the validator. + +Beyond the administrative elements of running a validator, it is important for validator operators to be involved in the XRP community by announcing potential downtime or maintenance work ahead of time. Validators that appear on a UNL have the opportunity to vote on amendments and fees, thereby having a voice in the evolution of the network. Therefore, it is imperative that validator operators stay abreast of the [latest updates](https://xrpl.org/blog/) coming to the XRP Ledger. + + +## No Incentive: A Design Decision + +Unlike other decentralized ledgers, the XRP Ledger does not provide a direct economic incentive for contributing to the consensus process by running a validator. Other blockchains offer direct incentives such as rewards from mining and staking or trading advantages. Instead, the lack of direct incentives for XRP Ledger validators attracts natural stakeholders. + +If you want to learn more about natural stakeholders and the design decision behind no incentive, then we invite you to attend a talk by David Schwartz, Chief Architect of the XRP Ledger and CTO of Ripple, titled “The Best Incentive is No Incentive” at [Stanford Blockchain Conference](https://cbr.stanford.edu/sbc20/). diff --git a/content/blog/2020/testnet-amendments-rippled-1.5.0.md b/content/blog/2020/testnet-amendments-rippled-1.5.0.md new file mode 100644 index 0000000000..06bdacd12c --- /dev/null +++ b/content/blog/2020/testnet-amendments-rippled-1.5.0.md @@ -0,0 +1,43 @@ +# Postmortem: Testnet Amendments from rippled 1.5.0 + +Like most new releases, version 1.5.0 of the XRP Ledger core server (`rippled`) contains new amendments which are not understood by earlier versions of the software. + +On Tuesday, March 10, 2020, Ripple upgraded its Testnet validators to rippled version 1.5.0-rc2. The new amendments, `RequireFullyCanonicalSig` and `fixQualityUpperBound`, were automatically supported by the validators because the server, by default, supports all of the amendments it knows about. The protocol enforces a 2-week delay between an amendment gaining majority support and its activation. This delay is intended to give operators time to upgrade to a version of rippled that supports the amendments. In this case, unfortunately, most operators were not given sufficient notice. The [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) used for such announcements was not notified until about two hours before the amendments were activated. + +On March 24, 2020, the amendments were activated by the Testnet validators. At this point, Ripple had these options: + +1. Deactivate the amendments: From a technical standpoint, it is only feasible to do this by resetting the Testnet ledger, meaning that all accounts and balances would be removed. + +2. Leave it alone: Testnet no longer matches Mainnet in terms of activated amendments, but the changes are minor, so it should not have much impact on testing or development. However, the amendments are only known to rippled 1.5.0, so all rippled servers connected to Testnet are [amendment blocked](https://xrpl.org/amendments.html#amendment-blocked) until they upgrade to rippled 1.5.0. + +3. Roll back the testnet ledger to shortly before the amendments became activated. This would undo any transactions after that point, while leaving most Testnet accounts and balances in place. This should be possible as long as Ripple controls the Testnet validators and Ripple has at least one validator that hasn't yet online-deleted history past the rollback point. However, this has not been tried in practice, and there is no documented procedure for doing so. + +Ripple opted for #2, the least disruptive option. + +Therefore, all rippled servers connecting to the Testnet must be upgraded in order to continue operating. Unfortunately, every operator running a stable-version rippled server connected to Testnet [experienced a disruption](https://github.com/ripple/rippled/issues/3315) because rippled 1.5.0 was still in the release candidate process at the time. To restore service, Testnet servers could be [upgraded to an 'unstable' release candidate version](https://groups.google.com/forum/#!topic/ripple-server/21htQzq4zz0) or wait for the official release, which came out on March 31. + +As new versions of rippled are released, operators should continue to upgrade their servers. Note that `unstable` repositories may update with pre-release versions in the future, so operators who opted to upgrade to a 1.5.0 release candidate should ensure that they do not get automatically upgraded to future 'unstable' versions, unless that is what they want. + +## Action items + +To improve this situation in the future, we recommend that the developers and participants of the XRP Ledger ecosystem incorporate the following process improvements: + +1. When a new amendment is included in a beta, it should be documented on xrpl.org as soon as possible. + +2. Whenever Ripple develops a new amendment with significant new features, Ripple will propose an [XRP Ledger Standard](https://github.com/xrp-community/standards-drafts), in the open source community-run GitHub repo, before merging code to the **develop** branch. + +3. When Devnet/Testnet/Mainnet validators are upgraded to a new version of rippled, Ripple will post an announcement to [the ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server), regardless of whether the release contains new amendments; these posts keep the XRP community up-to-date about new releases and invite them to review the changes. If there are new amendments, they should be emphasized and called out in the email. + +4. New amendments should be vetoed on Testnet until they gain majority on Mainnet. Ripple plans to automate this with a script that monitors when an amendment gains majority (not just when it is activated) on Mainnet. The lag between the two networks would be no more than the time between flag ledgers, 20 minutes or less. Until this automation is in place, Testnet's amendments may be a day or two behind. + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software, subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/). + +Other resources: + +* Ripple Technical Services: +* [Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2020/two-fixes-enabled.md b/content/blog/2020/two-fixes-enabled.md new file mode 100644 index 0000000000..82768f0ef2 --- /dev/null +++ b/content/blog/2020/two-fixes-enabled.md @@ -0,0 +1,40 @@ +# Two Fix Amendments Are Now Enabled + +As [previously announced](https://xrpl.org/blog/2020/deletableaccounts-expected.html), the [fixCheckThreading](https://xrpcharts.ripple.com/#/transactions/74AFEA8C17D25CA883D40F998757CA3B0DB1AC86794335BAA25FF20E00C2C30A) and [fixPayChanRecipientOwnerDir](https://xrpcharts.ripple.com/#/transactions/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09) amendments became enabled on 2020-05-01. + +The DeletableAccounts amendment is still expected for 2020-05-08. + + + +## Action Required + +- If you operate a `rippled` server, you must upgrade to version 1.4.0 or higher by **2020-05-01**, for service continuity. **Version 1.5.0** is _strongly recommended_. + +- If you use the [`account_channels` API method](https://xrpl.org/account_channels.html), you must upgrade to `rippled` version 1.5.0 to avoid breaking changes to the API triggered by the fixPayChanRecipientOwnerDir amendment. + +- The DeletableAccounts amendment changes the starting [sequence numbers](https://xrpl.org/basic-data-types.html#account-sequence) for accounts. If you have automatic processes that send transactions from newly-funded accounts, please check that the change does not break critical processes. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + + +## Impact of Not Upgrading + +If you operate a `rippled` server on a version older than 1.4.0, then your server is now amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + + +## Learn, ask questions, and discuss + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +Related documentation is available in the [XRP Ledger Dev Portal](https://xrpl.org/), including detailed example API calls and web tools for API testing. + +Other resources: + +* [The Xpring Forum](https://forum.xpring.io/) +* [XRP Chat Forum](http://www.xrpchat.com/) diff --git a/content/blog/2021/community-spotlight-developing-wallet-protect.md b/content/blog/2021/community-spotlight-developing-wallet-protect.md new file mode 100644 index 0000000000..d11520fb7f --- /dev/null +++ b/content/blog/2021/community-spotlight-developing-wallet-protect.md @@ -0,0 +1,45 @@ +--- +category: 2021 +date: 2020-03-10 +labels: + - Developer Reflections +--- +# Community Spotlight: Developing Wallet Protect + +GateHub started in 2013 with an idea: _What if there was a wallet that could hold any type of asset, have an integrated exchange built-in and provide the ability to send and receive assets across any payment network instantly?_ + + + +Bitcoin dominated the market at the time, and as an early pioneer, Bitstamp’s exchange was one of the first exchanges to list XRP and become an XRPL gateway. Enej Pungerčar, who at the time worked at Bitstamp as a web designer and developer, was able to see the benefits of a blockchain that would be able to support other types of assets, unlike Bitcoin. Inspired by the challenge, he began building a front-end wallet prototype to ease the burden of transferring funds and to better the user experience. + +He decided to use the XRP Ledger because it was instant and allowed users to send multiple currencies across the network. But, while he could access and transfer funds on the XRP Ledger (XRPL), Pungerčar still needed a Bitstamp account to send money to the wallet itself. He needed more support in order to develop a more robust solution. + +## Building on the XRP Ledger + +In 2014, he presented his idea at Ripple in San Francisco. It was the first time anyone attempted to build something on the front-end of the XRP Ledger and he received overwhelming support from both Ripple’s leadership and developer teams. Shortly thereafter, Pungerčar along with Anžej Simičak and George Frost, formally started [GateHub](https://gatehub.net/?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect) and launched the first version of the wallet in 2015. + +Since then, GateHub has been focused on improving its user experience. On the one side is the wallet. Built for the masses, it is a robust platform but user friendly enough to allow those who haven’t necessarily interacted with the XRP Ledger to jump right in with both feet. Then on the other side is growing GateHub into a gateway, building it out as a platform that would not only attract customers, but also increase the adoption of the XRP Ledger and provide a turn key solution for financial institutions and corporations to act as a gateway without worrying about all the complicated infrastructure requirements. GateHub is the largest wallet provider on the XRP Ledger. Ultimately, it aims to become one of the world’s leading overall wallet providers and the best ‘gateway as a service’ platform. + +The primary reasons they chose to build GateHub on XRPL is the benefits of scalability, speed and low cost. Compared to other blockchains, settlements on XRPL take an average of 3-5 seconds, versus an hour or more. Plus, using the XRPL gives GateHub freedom to build out new tools to better serve their customers. + +> ![Gatehub and Coincover logos](../img/gatehub-coincover.png) + +## Wallet Protect: A New Service for XRPL Wallets + +Security concerns are permeating the crypto market. Since 2011, over $7.6 billion of crypto funds have been stolen due to scams and user’s general unfamiliarity with the market. On top of that, when exchanges are forced to shut down, there is no way for users to recover their funds. This is a problem GateHub is looking to solve. + +[Wallet Protect](https://gatehub.net/blog/wallet-protect-faq/?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect) is a world-first for the XRP Ledger. It provides users with the ability to secure their wallets with multi-signature and up to $100,000 of theft cover through a partnership with [Coincover](http://coincover.com/). Coincover offers a range of cryptocurrency protection products including fund recovery and deposit protection guarantee. + +Additionally, the custody of funds always stays with the customer, meaning whether GateHub exists or not, users will always be able to get their funds back. Thanks to its use of [xrplorer](https://xrplorer.com/) and [Chainalisys](https://www.chainalysis.com/), GateHub flags suspicious account addresses to help mitigate unnecessary security problems in the first place. + +Wallet Protect is built into GateHub and it’s easy for users to [sign-up](https://signin.gatehub.net/signup?utm_source=ripplex&utm_medium=affiliate&utm_campaign=wallet_protect). A special 25% discount has been extended for readers of this blog. For the month of March, $10,000 of theft cover can be purchased for $2.25 per month or upgraded to $100,000 of theft cover for $18 per month. + +
+ +## What’s Next for GateHub + +As GateHub continues to improve its platform and grow, Pungerčar and his team, that is more than 40 people strong, are committed to helping people navigate the world of cryptocurrency more efficiently. By building a network of regulated gateways using the XRP Ledger, it will soon be possible for customers to draw upon any assets or values. + +GateHub, however, doesn’t want to do it alone. The team wants to encourage other developers and merchants to build their own solutions and wallet applications. The sooner more companies and developers adopt the technology, the sooner its value will be recognized on a global scale. + +Are you a developer interested in building on the XRP Ledger? Learn more [here](https://xrpl.org/docs.html). diff --git a/content/blog/2021/five-upcoming-amendments.md b/content/blog/2021/five-upcoming-amendments.md new file mode 100644 index 0000000000..a4685d64eb --- /dev/null +++ b/content/blog/2021/five-upcoming-amendments.md @@ -0,0 +1,82 @@ +--- +category: 2021 +date: 2021-11-10 +labels: + - Amendments +--- +# Five Amendments Expected Soon + +Several amendments to the XRP Ledger protocol are expected to become enabled on the XRP Ledger Mainnet soon. Three of these amendments fix bugs in the XRP Ledger protocol, one (NegativeUNL) improves the ability of the network to make forward progress during periods of instability, and the last one (TicketBatch) adds the ability to prepare and send transactions in a more flexible order. The details are as follows (all dates are in UTC): + +- fixSTAmountCanonicalize (min version: [1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html)) expected **2021-11-11**. +- FlowSortStrands (min version: [1.7.0](https://xrpl.org/blog/2021/rippled-1.7.0.html)) expected **2021-11-11**. +- fixRmSmallIncreasedQOffers (min version: [v1.7.2](https://xrpl.org/blog/2021/rippled-1.7.2.html)) expected **2021-11-18**. +- TicketBatch (min version: [v1.7.2](https://xrpl.org/blog/2021/rippled-1.7.2.html)) expected **2021-11-18**. +- NegativeUNL (min version: [v1.7.3](https://xrpl.org/blog/2021/rippled-1.7.3.html)) expected **2021-11-21**. + +Each amendment will become enabled if it maintains support from at least 80% of trusted validators until its expected time. Operators of `rippled` servers **must** upgrade to the minimum version or higher by the time these amendments become enabled. + + + +## Action Required + +If you operate an XRP Ledger (`rippled`) server, you should upgrade to **version 1.7.3** (or higher) as soon as possible, for service continuity. + +**Note:** Version 1.8.0 is currently in the release candidate stage, and also supports these amendments. However, the amendments may go live before version 1.8.0 reaches full release, so you should not wait to upgrade. + +No action is needed for applications and integrations with the XRP Ledger. You may want to review how [Tickets](https://xrpl.org/tickets.html) work to see if you want to use them in your software, or enable your users to use them. + +## Impact of Not Upgrading + +If you operate a `rippled` server but don’t upgrade to the minimum version by the time the amendments are expected to become enabled, then your server will become amendment blocked, meaning that your server: + +* Cannot determine the validity of a ledger +* Cannot submit or process transactions +* Does not participate in the consensus process +* Does not vote on future amendments +* Could rely on potentially invalid data + +If some amendments do not become enabled, then your server will not be amendment blocked as long as it meets the minimum version for any amendments that did become enabled. However, version 1.7.3 is strongly recommended because it includes important fixes for server stability and supports all four amendments. + +For instructions on upgrading `rippled` on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html). + +## Amendment Summaries + +### fixSTAmountCanonicalize + +This amendment fixes an edge case in [deserializing](https://xrpl.org/serialization.html) Amount-type fields. Without this amendment, in some rare cases the operation could result in otherwise valid serialized amounts overflowing during deserialization. With this amendment, the XRP Ledger detects error conditions more quickly and eliminates the problematic corner cases. + + +### FlowSortStrands + +This amendment improves the payment engine's calculations for finding the most cost-efficient way to execute a cross-currency transaction. + +Without this change, the engine simulates a payment through each possible path to calculate the quality (ratio of input to output) of each path. With this change, the engine calculates the theoretical quality of each path without simulating a full payment. With this amendment, the payment engine executes some cross-currency payments much faster, is able to find the most cost-efficient path in more cases, and can enable some payments to succeed in certain conditions where the old payment engine would fail to find enough liquidity. + + +### fixRmSmallIncreasedQOffers + +This amendment fixes an issue where certain Offers, when almost completely consumed, have a much lower exchange rate than when they were first placed. This occurs when the remaining amounts of one or both assets are so small that they cannot be rounded to a similar ratio as when the Offer was placed. + +Without this amendment, an Offer in this state blocks Offers with better rates deeper in the order book and causes some payments and Offers to fail when they could have succeeded. + +With this amendment, payments and trades can remove these types of Offers the same way that transactions normally remove fully consumed or unfunded Offers. + + +### NegativeUNL + +This amendment implements a ["Negative UNL" system](https://xrpl.org/negative-unl.html), where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the ability of the network to make progress during periods of network instability. + + +### TicketBatch + +This amendment adds [Tickets](https://xrpl.org/tickets.html) as a way of sending transactions out of the typical sequence number order. (Standards Draft: [XLS-13d](https://github.com/XRPLF/XRPL-Standards/issues/16).) If you have an XRP Ledger account, you can create one or more Tickets, then use those Tickets to send transactions that can execute in any order. This allows for usage patterns such as preparing multiple multi-signed transactions in parallel when the process of collecting signatures can take a long time. + + +## Learn, ask questions, and discuss + +To learn more about how the XRP Ledger's amendments system coordinates protocol upgrades, see the [Amendments article](https://xrpl.org/amendments.html). + +To receive email updates whenever there are important releases or changes to the XRP Ledger server software subscribe to the [ripple-server Google Group](https://groups.google.com/forum/#!forum/ripple-server). + +For more platforms with XRP Ledger content and more ways to get involved, see the [XRPL Community Page](https://xrpl.org/contribute.html). diff --git a/content/blog/2021/introducing-xrpl-js.md b/content/blog/2021/introducing-xrpl-js.md new file mode 100644 index 0000000000..f744ad863f --- /dev/null +++ b/content/blog/2021/introducing-xrpl-js.md @@ -0,0 +1,44 @@ +--- +category: 2021 +date: 2021-10-20 +labels: + - xrpl.js Release Notes +--- +# Introducing xrpl.js +_by Team RippleX_ + +[RippleX](https://ripple.com/ripplex/) and the [XRP Ledger Foundation (XRPLF)](https://xrplf.org/) are excited to announce xrpl.js **version 2.0.0**, a JavaScript/TypeScript library for interacting with the XRP Ledger (XRPL). Formerly known as ripple-lib, the library was renamed to better represent its role in the XRPL ecosystem and overhauled to take advantage of modern JavaScript features. + + + +## Background + +JavaScript is one of the most widely-used programming languages, and as such has a massive community of active developers. Maintaining a JavaScript SDK enables these developers to seamlessly interact with the XRP Ledger, both in the browser and in Node.js. In addition, the JavaScript libraries (xrpl.js, ripple-binary-codec, ripple-keypairs, and ripple-address-codec) power many [apps](https://github.com/XRPLF/xrpl.js/blob/develop/APPLICATIONS.md) in the XRPL ecosystem, as well as [packages](https://www.npmjs.com/browse/depended/ripple-lib) from companies such as BitGo and Ledger. + +## Changes + +With this release of xrpl.js, the JavaScript, [Java](https://github.com/XRPLF/xrpl4j), and [Python](https://github.com/XRPLF/xrpl-py/) libraries provided by the XRPLF now have parallel structures and systems. This enables developers to easily work with their preferred programming language depending on their specific needs, without having to learn an entirely new interface. + +xrpl.js will continue to support all ripple-lib features, such as: + +- Serializing, signing, and submitting transactions to the XRPL +- Retrieving information from the XRPL +- Helpful utility functions (such as converting between [drops](https://xrpl.org/xrp.html#xrp-properties) and XRP) +- Support for Node.js, web browsers, and React + +It also introduces a number of new features, including: + +- TypeScript types for all transaction types and WebSocket requests +- A Wallet class to make it easier to work with key pairs +- Protections against the [partial payment attack vector](https://xrpl.org/partial-payments.html#partial-payments-exploit) +- An additional submit implementation that returns the transaction's final outcome after validation. + +In version 2.0, the library is now much more aligned with the core XRP Ledger interface. This means XRPL developers—whether new or experienced—can refer to multiple sources of documentation instead of needing to rely solely on the library-specific documentation. There are also a number of general architecture improvements, such as simplifying code, making user interfaces more intuitive (especially in relation to the core ledger), and revamping the testing structure. For a detailed list of changes, visit the [changelog](https://github.com/XRPLF/xrpl.js/blob/develop/HISTORY.md). + +## Start Building + +To get started using xrpl.js, see [this tutorial on xrpl.org](https://xrpl.org/get-started-using-javascript.html), or check out the [project repo](https://github.com/XRPLF/xrpl.js) or [reference documentation](https://js.xrpl.org/). + +If you already have a project that uses ripple-lib, migrate today! We have a [migration guide for moving your code from ripple-lib v1.10 to xrpl.js v2.0](https://xrpl.org/xrpljs2-migration-guide.html). + +We hope you enjoy building the Internet of Value, and feel welcome to reach out to the XRP Ledger developer community if you have any questions! diff --git a/content/blog/2021/introducing-xrpl-py-for-pythonistas.md b/content/blog/2021/introducing-xrpl-py-for-pythonistas.md new file mode 100644 index 0000000000..e128401b83 --- /dev/null +++ b/content/blog/2021/introducing-xrpl-py-for-pythonistas.md @@ -0,0 +1,36 @@ +--- +category: 2021 +date: 2021-04-06 +labels: + - xrpl-py Release Notes +--- +# Introducing xrpl-py for Pythonistas +_by Team RippleX_ + +Today, [RippleX](https://ripple.com/) and the [XRP Ledger Foundation (XRPLF)](https://xrplf.org/) are excited to announce the launch of [`xrpl-py`](https://github.com/XRPLF/xrpl-py), a pure Python implementation for interacting with the XRP Ledger. The `xrpl-py` library simplifies the hardest parts of XRP Ledger interaction—like serialization and transaction signing—by providing native Python methods and models for [XRP Ledger transactions](https://xrpl.org/transaction-formats.html) and [core server API](https://xrpl.org/api-conventions.html) ([rippled](https://github.com/ripple/rippled)) objects. + + + +Python is one of the most popular programming languages in the world. This library opens up a significant amount of XRP Ledger functionality to Python developers, whether they are just learning to code or have been working in the language for years. Data scientists and engineers working on machine learning will find it far easier to work with and build on top of the XRP Ledger by using this library as part of their Python-based toolkit. + +Previously, the only actively maintained libraries were for [JavaScript](https://github.com/ripple/ripple-lib) or [Java](https://github.com/XRPLF/xrpl4j). To do any extensive work with the XRP Ledger, Python developers had to either switch to a less familiar language or rely on libraries whose shelf life was unclear. All of this is now available natively, as an easy-to-use library that is friendly to crypto newbies. + +The `xrpl-py` library offers a range of features including: + +* Serializing, signing, and submitting transactions +* [Cryptographic key generation](https://github.com/XRPLF/xrpl-py#manage-keys-and-wallets) +* [Converting between X-Addresses and classic addresses](https://github.com/XRPLF/xrpl-py#encode-addresses) +* Retrieving account information, including balances +* [Model objects for all transaction types](https://xrpl-py.readthedocs.io/en/latest/source/xrpl.models.transactions.html) and all core server [requests](https://xrpl-py.readthedocs.io/en/latest/source/xrpl.models.requests.html) + +We think of `xrpl-py` v1.0.0 as the first step in a longer journey. We built `xrpl-py` as part of our larger goal to facilitate development on the XRP Ledger by decreasing the learning curve, creating more inclusive tools and expanding the choice of programming languages. + +The feature set for the first available version is limited but it implements the most common use cases of XRP Ledger development. We're working on adding new features to `xrpl-py` and aim to include everything else the XRP Ledger offers within the library soon. We plan on using this framework to create even more libraries for the XRP Ledger in other languages in the near future. + +Since we designed `xrpl-py` to be usable for a wide range of developer levels, you can find the functionality that matches your skill level. For beginners, the library offers several higher-level functions that abstract away a lot of details and provide useful developer interfaces. More experienced developers can access the lower-level methods and functions to build more complex projects. Overall, `xrpl-py` closely mirrors the underlying [core server API](https://xrpl.org/rippled-api.html) so even developers who have built directly on the core server in the past should find the structure of the project familiar. + +While the team at RippleX built the first release of `xrpl-py`, we did this while taking input from the community. We feel that libraries like `xrpl-py` work best when they are owned, used, and supported by a large and thriving community of excited developers. To that end, we contributed the code to the XRPLF, who are hosting the source code under their [GitHub organization](https://github.com/XRPLF), which features a growing number of libraries and other developer tools. + +To get started, see [this tutorial](https://xrpl.org/get-started-using-python.html) on xrpl.org, check out the [README in the project repo](https://github.com/XRPLF/xrpl-py#xrpl-py), or go right to the [reference documentation](https://xrpl-py.readthedocs.io/). + +For more discussion about developing on the XRP Ledger, catch the [RippleXDev stream](https://www.twitch.tv/ripplexdev) on Twitch! diff --git a/content/blog/2021/introducing-xrpl4j.md b/content/blog/2021/introducing-xrpl4j.md new file mode 100644 index 0000000000..6af149dc02 --- /dev/null +++ b/content/blog/2021/introducing-xrpl4j.md @@ -0,0 +1,27 @@ +--- +category: 2021 +date: 2021-05-20 +labels: + - xrpl4j Release Notes +--- +# Introducing xrpl4j + +RippleX and the XRP Ledger Foundation (XRPLF) are pleased to announce the release of`xrpl4j`, a pure Java library for interacting with the XRP Ledger (XRPL). [`xrpl4j`](https://github.com/XRPLF/xrpl4j) provides convenient tooling for developers to take full advantage of all the XRP Ledger has to offer, including wallet derivation, address encoding, transaction serialization and signing and native Java objects modeling core primitives of the rippled API. + +Though `xrpl4j` was initially built as a tool for internal Ripple projects, we have since open-sourced the code on Github under the XRP Ledger Foundation organization. We’ve also released [two major versions](https://search.maven.org/search?q=org.xrpl) to Maven Central. This library exposes a large portion of the functionality of the XRP Ledger and can be used in any JVM environment, opening the door for Android and server-side Java developers alike to start developing XRP Ledger apps. Whether you are a novice XRP Ledger developer or a seasoned vet, the `xrpl4j` API offers an easy and idiomatic toolkit for your next app. + +Prior to the release of `xrpl4j`, Java developers interested in building on top of the XRP Ledger either had to write large amounts of complicated code themselves or develop their apps using [JavaScript](https://github.com/ripple/ripple-lib) or [Python](https://github.com/XRPLF/xrpl-py). Now, they can enjoy the features of those libraries in an easy-to-use, fully native Java library. + +The `xrpl4j` library offers a range of features including: + +* Cryptographic key and account generation +* Transaction serialization, secure signing and submission +* Model objects for all [transaction types](https://xrpl.org/transaction-formats.html) and the most commonly used [Ledger objects](https://xrpl.org/ledger-data-formats.html) and [server API](https://xrpl.org/public-rippled-methods.html) requests and responses + +The feature set of the library includes almost everything that the XRP Ledger supports. However, by design, `xrpl4j` does not provide abstractions on top of the core rippled API. This design equips developers with the most flexibility in how they use the XRP Ledger, and has the added benefit of being familiar to developers who have built directly on the rippled API. Additionally, newer XRPL developers only have to learn one API instead of needing to learn the core rippled server API along with a new library interface. + +While the team at RippleX has built a majority of `xrpl4j` thus far, we did this with input from the developer community. We feel that libraries like `xrpl4j` work best when they are owned, used and supported by a large and thriving community. To that end, we contributed the code to the XRPLF, who is hosting the source code under their [GitHub organization](https://github.com/XRPLF), which features a growing number of libraries and other developer tools supporting the XRP Ledger community. + +To get started with `xrpl4j`, follow [this tutorial](https://xrpl.org/get-started-using-java.html) on xrpl.org, check out the [README in the project repo](https://github.com/XRPLF/xrpl4j/blob/main/README.md) or go right to the [reference documentation](https://javadoc.io/doc/org.xrpl/xrpl4j-parent/2.0.0/index.html). + +For more discussions about building on top of the XRP Ledger and to see `xrpl4j` in action, tune into the [RippleXDev](https://www.twitch.tv/ripplexdev) Twitch stream on May 25 at 11am PT. diff --git a/content/blog/2021/message-routing-optimizations-pt-1-proposal-validation-relaying.md b/content/blog/2021/message-routing-optimizations-pt-1-proposal-validation-relaying.md new file mode 100644 index 0000000000..ca286a3e3d --- /dev/null +++ b/content/blog/2021/message-routing-optimizations-pt-1-proposal-validation-relaying.md @@ -0,0 +1,139 @@ +--- +category: 2021 +date: 2021-03-16 +labels: + - Development +--- +# Message Routing Optimizations, Pt. 1: Proposal & Validation Relaying + +_by Gregory Tsipenyuk and Nikolaos D. Bougalis of Ripple_ + +Like all peer-to-peer networks, the XRP Ledger needs a strategy to ensure that messages are propagated across the network. Of course, some types of messages are more important or more time-sensitive than others, so the XRP Ledger uses different strategies for relaying different types of messages. + +This blog post discusses the message propagation strategy used for “proposal” and “validation” messages, which are part of the [consensus protocol](https://xrpl.org/consensus.html), and the improvements that the RippleX team researched and is contributing. + + + +## Current System + +Currently, the XRP Ledger uses [flooding](https://en.wikipedia.org/wiki/Flooding_%28computer_networking%29) to propagate proposal and validation messages; in other words, when a server receives a proposal or validation message, that server passes it on to all of its peers except the one it got the message from initially. A proposal message contains a set of candidate transactions and a proposed close time for the next ledger, while a validation message contains information about the ledger built by applying a set of proposals. + +Flooding protocols are generally reliable in propagating messages throughout the network since they naturally utilize every path. However, they can also be inefficient, especially in densely connected networks, where they can increase bandwidth usage dramatically and impose additional work on the servers that must process those messages.. + +For example, in the graph below, if _A_ sends a message to _B_ and _C_, the flood algorithm might result in both _B_ and _C_ sending the message to each other. Unfortunate timing may even make it possible for one of them to even send the message back to _A_, which originated it (Figure 1). + +> ![Figure 1. Redundant message propagation from node A to node B](../img/message-routing/fig-1-redundant-message-propagation.png) +> +> _Figure 1. Redundant message propagation from node A to node B_ + +While this example is a hypothetical scenario, we felt that the impact of redundant message propagation on the XRP Ledger network could be substantial, so we collected and analyzed data in an attempt to better understand the scope of the problem. + +## Initial Research and Approach + +We crawled the XRP Ledger main network with [Peer Crawler](https://xrpl.org/peer-crawler.html) and collected the number of peers for each reachable node: we discovered a total of 759 reachable nodes and 9,926 links between the nodes. About 73% of the nodes have more than 10 peers, 10% have more than 50 peers, and 6% have more than 200 peers. The highest number of peers we detected was 238. + +We also used the [get_counts](https://xrpl.org/get_counts.html) API method on a Ripple-operated node connected to the XRP Ledger mainnet, to determine the frequency of various message types. We discovered that, during the sampling period, proposal and validation messages accounted for 72% of the 42 million messages. + +These percentages are not unexpected and confirmed the theory that the propagation of proposal and validation messages has a significant impact on the bandwidth usage of individual nodes and the network as a whole, and that message duplication likely has a measurable impact on the performance of the network as a whole. + +We are proposing to mitigate the load on the network by optimizing the relaying strategy for proposal and validation messages by limiting transmission of duplicates, resulting in a net reduction of the number of messages relayed. + + +## How It Works + +The proposal, previously [outlined on xrpchat.com](https://www.xrpchat.com/topic/33075-suggestion-reduce-relaying/), accomplishes this by allowing a server to select a subset of its peers to function as the source of proposal and validation messages from a specific validator and suppressing the messages from the rest of its peers by sending a “squelch” message to them. + +This process should work well because, generally, the flooding protocol utilizes all paths throughout the network equally, and since some paths will be “shortest” or “fastest” in the sense that they consistently deliver the message from a particular validator faster than others we can identify the peers with the lowest latency and select them as a preferred source of the proposal and validation messages. + +The node uses the number of messages received from each peer to make a short list of peers who've sent a good number of messages. Then it randomly chooses some of those peers to be its preferred source of validation and proposal messages. To everyone else, the node sends a "squelch" message, telling them not to relay certain messages to it for a while. + +More specifically, the “squelch” message tells a peer to suppress messages originating from a certain validator (identified by a public key) for a given amount of time. After the duration expires, the peer starts relaying messages downstream (Figure 2). + +When the node gets a message from a new peer, or receives a message from a peer whose squelch duration has passed, that node restarts the peer selection process. Similarly, if a selected peer disconnects, then the node sends an “un-squelch” message to all squelched peers requesting that they resume relaying messages, then restarts its peer selection process. + +This mechanism allows to adjust the peer’s selection process to changes in the network topology. Note that a node maintains a record of the squelch duration for each squelched peer and doesn’t start the selection process if a message from a squelched peer is received too soon. + +This process is further demonstrated on a sequence diagram in Figure 2(A). Node _G_ propagates validation and proposal messages from a validator to nodes _B_ through _F_ (blue arrows) via some route (1). + +> ![Figure 2. Relay Reduction concept sequence diagram and graph visualization.](../img/message-routing/fig-2-relay-reduction-concept.png) +> +> _Figure 2. Relay Reduction concept sequence diagram and graph visualization._ + +Nodes _B_ through _F_ are peers of node _A_ and relay the messages to node _A_ (green arrows). Consequently, node _A_ receives each message 5 times. As node _A_ receives the messages from its peers, it determines that messages from nodes _C_, _D_, and _E_ arrive sooner than from the rest of the peers. + +Node _A_ selects these peers as the source of the messages from the validator and sends a “squelch” message to nodes _B_ and _F_ (red arrows). Node _G_ keeps on relaying the messages to nodes _B_ through _F_ but only nodes _C_, _D_, and _E_ relay the messages to node _A_ (2). + +At some point, nodes _B_ and _F_ un-squelch and start relaying the messages to node _A_. Node _A_ determines this time that nodes _B_, _C_, and _E_ should be the source of the messages from the validator and sends squelch messages to nodes _D_ and _F_ (3). + +This is further visualized as a graph on Figure 2 (B, C) where graphs (B) and (C) correspond to sequence (1) and (2) respectively. We can see that the relay reduction algorithm reduces the number of down-links to A by 2. As demonstrated in the Results section below, the reduction in links, when scaled up to the main network, is significant. + +However, as can be seen from Figure 2(C), node _A_ still receives 3 redundant messages. In an ideal network topology a broadcast tree is formed in such a way that each node receives a unique message only once. This topology can be represented as a subgraph or a [spanning tree](https://en.wikipedia.org/wiki/Spanning_tree), which has every node (vertex) covered with a minimum possible number of links (edges). + +> ![Figure 3. Pros and cons of a spanning tree broadcast.](../img/message-routing/fig-3-spanning-tree-broadcast.png) +> +> _Figure 3. Pros and cons of a spanning tree broadcast._ + +Consider a message propagation in a network represented by a directed graph in figure 3(A). A simulated message propagation via Breadth First Search (BFS) from a vertex _A_ through the graph forms the following paths: 1) _A→C_, _A→E_, _A→F_; 2) _C→D_, _C→E_; 3) _E→B_; 4) _F→B_, _F→D_; 5) _D→B_. All together there are 9 edges in the graph and as can be seen, vertices _B_, _D_, and _E_ have multiple incoming edges; i.e. receive the message from _A_ redundantly 3, 2, and 2 times respectively. If we form a spanning tree by selecting one random incoming edge in each node then it forms a graph in Figure 3(B). This graph has 5 edges; i.e. a number of redundant messages is reduced by 45%. + +This topology is optimal in an ideal network with no failures. But in a real crypto network where links and nodes can experience arbitrary byzantine failure, this topology loses resilience and reliability. Indeed, if a link _C→E_ fails then nodes _E_ and _B_ are not going to receive the message as shown in Figure 3(C). If on the other hand we select two random incoming edges in each node then node _E_ can receive the message via link _A→E_ as shown in figure 3(D). Other failures are still possible in this hypothetical network since nodes _C_ and _F_ have only one incoming edge; i.e. there is no redundancy. + +There are some strategies where an optimal broadcast tree can be constructed with the flooding used for fast recovery in case of failures as described in the [Epidemic Broadcast Tree](https://core.ac.uk/download/pdf/32330596.pdf) research paper. We are collaborating with University of Luxembourg researchers to investigate how other overlay optimization strategies can be applied. + +### Validating This Proposal + +To prove the validity of this proposal, we modeled the XRPL network as a [directed graph](https://en.wikipedia.org/wiki/Directed_graph) and demonstrated that the graph remains connected when “squelched” edges are removed and that there is a substantial reduction in relayed messages. + +A network node is represented by a vertex and a connection between two nodes in the network is represented by two directed edges connecting the nodes in the opposite direction. The directed edges model the message propagation within the network. + +To model the peer squelching, for each vertex in the graph we randomly select 5 neighbors, and for the rest of the neighbors, remove the incoming edges. The resulting graph is a snapshot of a message propagation path from a node to all other nodes. + +Note that the resulting paths are not the optimal paths since the source upstream vertices are selected at random. It is expected that on a live network the paths would be better optimized since the peers are selected using latency as the selection criterion. + +We took 100,000 snapshots of the graph constructed this way. For each snapshot we recorded: + +* if the graph is weakly connected; +* a number of nodes in the largest strongly connected component; +* if remaining nodes have an incoming edge from the component; and +* a number of undirected edges. + +## Results + +The graph remains weakly connected in every snapshot. On average there are 465 nodes in the largest strongly connected component, all remaining nodes have an incoming edge from the component, and on average there are 3,477 edges in the component. + +There are two important findings in the results. First that the remaining nodes have an incoming edge from the component. If a node is the originator of a message, a validator in the XRPL network, then it ignores the squelch request and relays the message to all its peers. + +Consequently, if a remaining node is a message’s originator, then the message will be propagated to the strongly connected component, and from the strongly connected component, it can be propagated to any of the remaining nodes. If a node in the strongly connected component is a message’s originator, then the message can be propagated to all remaining nodes. Therefore, a message originating at any node within the graph can be propagated to any node. + +Second, while the reduced graph retains its ability to propagate a message throughout the network, it has 2.8 times less edges, which may result in significantly less redundant messages propagated throughout the network. + +Note that a snapshot represents an optimally reduced graph in that it has all non-source vertices squelched at the same time. In the real network, the vertices/nodes are squelched and un-squelched at a random time resulting in a higher average number of edges. + +We can model this by introducing a timeline to the graph where each vertex selects 5 neighbors at random and squelches the rest for a random duration. When a neighbor is squelched, the incoming edge is removed. When a neighbor is un-squelched, the respective incoming edge is added back. + +Each change in the number of edges is recorded in the timeline. We simulated 120 minutes of this process. The result is shown on Figure 4. + +The network starts in a normal mode with 9,926 links. After about 5 minutes all vertices squelch their redundant neighbors, resulting in a significant reduction of links. As neighbors start to randomly squelch and un-squelch, a number of links averages at 4,210 with standard deviation 157. The reduction in links in this case is 2.4-fold. + +> ![Figure 4. Model of a number of links over time.](../img/message-routing/fig-4-links-over-time.png) +> +> _Figure 4. Model of a number of links over time._ + +Validating the Results To collect information, we instantiated a testnet with 40 nodes, 10 of which were configured as validators; each node had 20 peers. We conducted several one-hour runs of this network, both with and without the “reduce relay” feature. The results are shown in Table 1. + +The reduction in a number of messages and size is about 2.76 fold, which is within the estimated range of reduction 2.4-2.8 fold. Bandwidth savings in this case is about 528K/sec. + +| Metric | Relay Reduction disabled | Relay Reduction enabled | Reduction | +|:-------------|:-------------------------|:------------------------|:----------| +| Count | 15,628,604 | 5,653,278 | 276% | +| Size (bytes) | 2,979,290,492 | 1,077,290,776 | 276% | + +The expected bandwidth savings across the entire XRP Ledger main network from applying the relay reduction feature can be estimated using data from the model and information collected from the main network, and works out to approximately ~1MB/sec per validator. + + +## Key Takeaways + +Modeling and testing of the relay reduction feature demonstrate that it is effective at reducing the amount of proposal and validation messages can be reduced roughly by 2.5 times without affecting message propagation. + +These results are incredibly exciting and will help make the protocol more efficient. We hope to see other node operators test the relay reduction enhancement, and validate the results. + +In the meantime, we will continue research improvements in message routing, focusing especially on the routing of transaction messages. Unlike proposals and validations, which only originate from nodes configured as validators, transactions can originate at any node and that necessitates a different approach. We hope to outline the thinking and provide more details on this topic in an upcoming blog post. diff --git a/content/blog/2021/reserves-lowered.md b/content/blog/2021/reserves-lowered.md new file mode 100644 index 0000000000..7e76ff9581 --- /dev/null +++ b/content/blog/2021/reserves-lowered.md @@ -0,0 +1,41 @@ +--- +category: 2021 +date: 2021-09-21 +labels: + - Advisories +--- +# Lower Reserves Are Now In Effect + +Over the course of the past year, several members of the XRP Ledger community have advocated for lowering the reserve requirements in the network to compensate for the sustained increase in the price of XRP. On 2021-09-19, [the new reserve values went into effect](https://livenet.xrpl.org/transactions/5922A0BA30621C60B2B6DDBC3FF6B5BB509EB3685C4C3D56696A9FE4FE6D48A3/raw) after gaining support from a majority of validators. The new reserve amounts are **10 XRP** base for an account plus **2 XRP** per object owned in the ledger, down from 20 XRP base and 5 XRP per object owned. + + + +## Impacts + +Some XRP that was previously reserved is now available for use. Since the base reserve requirement has decreased from 20 to 10, accounts with a balance of at least 20 XRP now have access to the difference of 10 XRP, plus a decrease of 3 XRP per item owned (from 5 each to 2 each). For example, if your account owns 4 objects in the ledger, your reserve requirement decreased from 40 XRP (20 + 4×5) to 18 XRP (10 + 4×2). + +It is now possible to fund new accounts by sending a payment of as little as 10 XRP; previously, at least 20 XRP was required. + +The [special transaction cost](https://xrpl.org/transaction-cost.html) to [delete an account](https://xrpl.org/accounts.html#deletion-of-accounts) is based on the owner reserve, so deleting an account now requires burning only 2 XRP instead of 5 XRP. + + +## Action Recommended + +Most XRP Ledger users and integrations do not need to take action to benefit from the reduced reserve. However, if you have software with a hard-coded reserve of 20 XRP, you should consider adjusting it to use the new values, or better yet, occasionally query the reserve information from the API: + +To look up XRP reserves, see the [server_info method](https://xrpl.org/server_info.html)'s response. In particular, the `validated_ledger.reserve_base_xrp` field shows the base account reserve and the `validated_ledger.reserve_inc_xrp` shows the owner reserve (per item). You can also use the [server_state method](https://xrpl.org/server_state.html) to get the values in drops of XRP. + + +## Background + +The XRP Ledger has [reserve requirements](https://xrpl.org/reserves.html) to disincentivize spamming the ledger with data, which must be replicated throughout the network and maintained by all servers in the system. The _base reserve_ (now 10 XRP) sets the minimum XRP that must be sent to create a new account, and the _owner reserve_ (now 2 XRP per item) increases an account's reserve for each additional object the account owns in the ledger's [state data](https://xrpl.org/ledger-data-formats.html), such as Offers, trust lines and Escrows. + +The [Fee Voting](https://xrpl.org/fee-voting.html) process lets validators in the decentralized XRP Ledger network collectively adjust the reserve requirements. One reason to adjust reserve requirements is to compensate for long-term changes in the value of XRP. Fee voting can adjust reserves in either direction, but as XRP Ledger expert David Schwartz notes, [increases in the reserve are more painful for users than decreases](https://twitter.com/JoelKatz/status/1380980093858631682), so validator operators should avoid lowering the reserve if doing so is likely to require an increase later. + +The previous time the reserves changed was in [December 2013](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/), when 20 XRP was worth much less in fiat currency than it is today. The new 10 XRP reserve brings the fiat-currency cost of creating a new XRP Ledger account closer to the historical average. + +## XRP Ledger Foundation Statement + +The XRP Ledger Foundation posted this statement about the change to Twitter: + + diff --git a/content/blog/2021/ripple-lib-drops-lodash-browsers.md b/content/blog/2021/ripple-lib-drops-lodash-browsers.md new file mode 100644 index 0000000000..16c081f1d4 --- /dev/null +++ b/content/blog/2021/ripple-lib-drops-lodash-browsers.md @@ -0,0 +1,69 @@ +--- +category: 2021 +date: 2021-08-26 +labels: + - xrpl.js Release Notes +--- +# ripple-lib Drops Lodash Requirement in Browsers + +[Version 1.10.0](https://github.com/ripple/ripple-lib/releases/tag/1.10.0) of ripple-lib, the JavaScript/TypeScript library for the XRP Ledger, no longer requires a separate Lodash script to run in web browsers. This change comes alongside other continued improvements in the library, improving the experience of developing applications on the XRP Ledger. + + + +## Update Your Script Tags + +Starting with 1.10.0, ripple-lib incorporates Lodash into the browser-ready JavaScript build, so you can import just the library and get a working environment. Previously, you needed a separate script tag to import the Lodash dependency in web browsers. + +**Before:** + +```html + + +``` + +**After:** + +```html + +``` + +**Tip:** You can safely update ripple-lib to 1.10.0 even if you haven't removed the Lodash script tag. The extra script tag is now an unnecessary extra download for most cases, but it doesn't cause errors if it's still there. + +## Same Process on Node.js + +There is no change to how dependencies are managed when using ripple-lib in Node.js. + +## Other Changes + +As always, version 1.10.0 includes various minor improvements to fix bugs and improve documentation. There's also a new API method to call the [Testnet (or Devnet) faucet](https://xrpl.org/xrp-testnet-faucet.html) to get a new account pre-funded with test XRP. This method automatically selects the appropriate faucet based on which network you're already connected to. (It raises an error if you're connected to the Mainnet!) + +Example usage: + +```js +const ripple = require('ripple-lib') // Node.js only. Use a