ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 03:35:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix residual ripple.com/build/ links

Browse Source
This commit is contained in:
mDuo13
2019-07-26 11:04:02 -07:00
parent f911bf2064
commit acd096e607
10 changed files with 15 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/consensus-network/amendments/known-amendments.md
View File

@@ -481,7 +481,7 @@ Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixe
|:-----------------------------------------------------------------|:----------|
| DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 | Vetoed |
This amendment is currently enabled on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/). In production, Ripple expects to enable similar functionality with the [Escrow](escrow-object.html) amendment instead.
This amendment was replaced by the [Escrow](escrow-object.html) amendment.
## Tickets

2
content/concepts/payment-system-basics/transaction-basics/transaction-cost.md
View File

@@ -44,7 +44,7 @@ This divides transactions into roughly three categories:
## Local Load Cost
Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](get-started-with-the-rippled-api.html), the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) unless its `Fee` value meets the requirements of a majority of servers.
Each `rippled` server maintains a cost threshold based on its current load. If you submit a transaction with a `Fee` value that is lower than current load-based transaction cost of the `rippled` server, that server neither applies nor relays the transaction. (**Note:** If you submit a transaction through an [admin connection](get-started-with-the-rippled-api.html), the server applies and relays the transaction as long as the transaction meets the un-scaled minimum transaction cost.) A transaction is very unlikely to survive [the consensus process](consensus.html) unless its `Fee` value meets the requirements of a majority of servers.
## Open Ledger Cost

2
content/concepts/payment-types/escrow.md
View File

@@ -61,7 +61,7 @@ The diagram shows three different cases for three possible combinations of the e
## Availability of Escrow
Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [XRP Ledger Test Net](xrp-test-net-faucet.html) by the name "Suspended Payments" (SusPay) in 2016.
When testing in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:

2
content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md
View File

@@ -132,7 +132,7 @@ When you subscribe to a particular stream, you receive periodic responses on tha
## Ledger Stream
The `ledger` stream only sends `ledgerClosed` messages when [the consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) declares a new validated ledger. The message identifies the ledger and provides some information about its contents.
The `ledger` stream only sends `ledgerClosed` messages when [the consensus process](consensus.html) declares a new validated ledger. The message identifies the ledger and provides some information about its contents.
```
{

4
content/tutorials/get-started/get-started-with-rippleapi-for-javascript.md
View File

@@ -167,7 +167,7 @@ The one argument to the constructor is an options object, which has [a variety o
- The example `server` setting uses a secure WebSocket connection to connect to one of the public servers that Ripple (the company) operates.
- If you don't include the `server` option, RippleAPI runs in [offline mode](rippleapi-reference.html#offline-functionality) instead, which only provides methods that don't need network connectivity.
- You can specify a [Ripple Test Net](https://ripple.com/build/ripple-test-net/) server instead to connect to the parallel-world Test Network instead of the production XRP Ledger.
- You can specify a [XRP Ledger Test Net](xrp-test-net-faucet.html) server instead to connect to the parallel-world Test Network instead of the production XRP Ledger.
- If you [run your own `rippled`](install-rippled.html), you can instruct it to connect to your local server. For example, you might say `server: 'ws://localhost:5005'` instead.
@@ -231,7 +231,7 @@ The `catch` method ends this Promise chain. The callback provided here runs if a
# Waiting for Validation
One of the biggest challenges in using the XRP Ledger (or any decentralized system) is knowing the final, immutable transaction results. Even if you [follow the best practices](reliable-transaction-submission.html) you still have to wait for the [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) to finally accept or reject your transaction. The following example code demonstrates how to wait for the final outcome of a transaction:
One of the biggest challenges in using the XRP Ledger (or any decentralized system) is knowing the final, immutable transaction results. Even if you [follow the best practices](reliable-transaction-submission.html) you still have to wait for the [consensus process](consensus.html) to finally accept or reject your transaction. The following example code demonstrates how to wait for the final outcome of a transaction:
```
{% include '_code-samples/rippleapi_quickstart/submit-and-verify.js' %}

6
content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.md
View File

@@ -1,6 +1,6 @@
# Connect Your rippled to the XRP Test Net
Ripple has created the [XRP Test Network](https://ripple.com/build/xrp-test-net/) to provide a testing platform for the XRP Ledger. XRP Test Net funds are not real funds and are intended for testing only. You can connect your `rippled` server to the XRP Test Net to test out and understand `rippled` functionality before connecting to the production XRP Ledger Network. You can also use the XRP Test Net to verify that your own code interacts correctly with `rippled`.
Ripple has created the [XRP Test Network](parallel-networks.html) to provide a testing platform for the XRP Ledger. XRP Test Net funds are not real funds and are intended for testing only. You can connect your `rippled` server to the XRP Test Net to test out and understand `rippled` functionality before connecting to the production XRP Ledger Network. You can also use the XRP Test Net to verify that your own code interacts correctly with `rippled`.
**Note:** The XRP Test Net ledger and balances are reset on a regular basis.
@@ -49,6 +49,10 @@ To connect your `rippled` server to the XRP Test Net, set the following configur
$ ./rippled server_info | grep seq
## See Also
- [Parallel Networks](parallel-networks.html)
- [XRP Test Net Faucet](xrp-test-net-faucet.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
View File

@@ -17,7 +17,7 @@ Outside of the XRP Ledger, Grand Payments sends an invoice to BoxSend SG with th
To send a Check with this tutorial, you need the following:
- The **address** and **secret key** of a funded account to send the Check from.
- You can use the [XRP Ledger Test Net Faucet](https://ripple.com/build/xrp-test-net/) to get a funded address and secret with 10,000 Test Net XRP.
- You can use the [XRP Ledger Test Net Faucet](xrp-test-net-faucet.html) to get a funded address and secret with 10,000 Test Net XRP.
- The **address** of a funded account to receive the Check.
- A secure way to sign transactions, such as [RippleAPI][] or your own [`rippled` server](install-rippled.html).
- A client library that can connect to a `rippled` server, such as [RippleAPI][] or any HTTP or WebSocket library.

2
content/tutorials/use-complex-payment-types/use-payment-channels.md
View File

@@ -19,7 +19,7 @@ The example addresses used in this tutorial are:
Additionally, you'll need a `rippled` server to send transactions to. The examples in this tutorial assume a `rippled` server is running on the test machine (`localhost`) with an unencrypted JSON-RPC API endpoint on port **5005**.
To test without transferring real XRP, you can use [Ripple Test Net](https://ripple.com/build/ripple-test-net/) addresses with Test Net XRP. If you do use the Ripple Test Net, you can use the Test Net servers' JSON-RPC API by connecting to `https://api.altnet.rippletest.net:51234` instead of `http://localhost:5005/`.
To test without transferring real XRP, you can use [XRP Ledger Test Net](xrp-test-net-faucet.html) addresses with Test Net XRP. If you do use the Test Net, you can use the Test Net servers' JSON-RPC API by connecting to `https://api.altnet.rippletest.net:51234` instead of `http://localhost:5005/`.
You can use any amount of XRP for the payment channels. The example values in this tutorial set aside 100 XRP (`100000000` drops) in a payment channel for at least 1 day.

2
content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
View File

@@ -17,7 +17,7 @@ These types of errors can potentially lead to serious problems. For example, an
## Background
The XRP Ledger protocol provides a ledger shared across all servers in the network. Through a [process of consensus and validation](https://ripple.com/build/ripple-ledger-consensus-process/), the network agrees on the order in which transactions are applied to (or omitted from) the ledger.
The XRP Ledger protocol provides a ledger shared across all servers in the network. Through a [process of consensus and validation](consensus.html), the network agrees on the order in which transactions are applied to (or omitted from) the ledger.
Well-formed transactions submitted to trusted XRP Ledger servers are usually validated or rejected in a matter of seconds. There are cases, however, in which a well-formed transaction is neither validated nor rejected this quickly. One specific case can occur if the global [transaction cost](transaction-cost.html) increases after an application sends a transaction. If the transaction cost increases above what has been specified in the transaction, the transaction is not included in the next validated ledger. If at some later date the global transaction cost decreases, the transaction could be included in a later ledger. If the transaction does not specify an expiration, there is no limit to how much later this can occur.

2
content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md
View File

@@ -58,7 +58,7 @@ XRP is held in _accounts_ (also referred to as _wallets_ or _addresses_ ) on th
<!-- STYLE_OVERRIDE: hot wallet, warm wallet, cold wallet, wallet -->
To follow Ripple's recommended best practices, Alpha Exchange should create at least two new accounts on the XRP Ledger. To minimize the risks associated with a compromised secret key, Ripple recommends creating [_cold_, _hot_, and _warm_ accounts](https://ripple.com/build/issuing-operational-addresses/) (these are sometimes referred to, respectively, as cold, hot, and warm wallets). The hot/warm/cold model is intended to balance security and convenience. Exchanges listing XRP should create the following accounts:
To follow Ripple's recommended best practices, Alpha Exchange should create at least two new accounts on the XRP Ledger. To minimize the risks associated with a compromised secret key, Ripple recommends creating [_cold_, _hot_, and _warm_ accounts](issuing-and-operational-addresses.html) (these are sometimes referred to, respectively, as cold, hot, and warm wallets). The hot/warm/cold model is intended to balance security and convenience. Exchanges listing XRP should create the following accounts:
* A [_cold wallet_](issuing-and-operational-addresses.html#issuing-address) to securely hold the majority of XRP and customers' funds. For exchanges, this is also the address to which its users send [deposits](#deposit-xrp-into-exchange). To provide optimal security, this account's secret key should be offline.