ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Better interlinking of PayChan docs

Browse Source
This commit is contained in:
mDuo13
2017-05-16 15:16:06 -07:00
parent b547693009
commit 9b3235f803
5 changed files with 16 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
concept-amendments.html
View File

@@ -489,8 +489,8 @@ TrustSetAuth
</tbody>
</table>
<p>Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the <a href="https://interledger.org/">Interledger Protocol</a>. One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration.</p>
<p>Creates three new transaction types: <code>ChannelCreate</code>, <code>ChannelFund</code>, and <code>ChannelClaim</code>. Creates a new ledger node type, <code>Channel</code>. Defines an off-ledger data structure called a <code>Claim</code>, used in the ChannelClaim transaction. Creates new <code>rippled</code> API methods: <code>channel_authorize</code> (creates a signed Claim), <code>channel_verify</code> (verifies a signed Claim), and <code>account_channels</code> (lists Channels associated with an account).</p>
<!-- -->
<p>Creates three new transaction types:[PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger node type, <a href="reference-ledger-format.html#paychannel">PayChannel</a>. Defines an off-ledger data structure called a <code>Claim</code>, used in the ChannelClaim transaction. Creates new <code>rippled</code> API methods: <code>channel_authorize</code> (creates a signed Claim), <code>channel_verify</code> (verifies a signed Claim), and <code>account_channels</code> (lists Channels associated with an account).</p>
<p>For more information, see the <a href="tutorial-paychan.html">Payment Channels Tutorial</a>.</p>
<h2 id="shamapv2">SHAMapV2</h2>
<table>
<thead>

4
content/concept-amendments.md
View File

@@ -239,9 +239,9 @@ This Amendment requires the [Flow Amendment](#flow) to be enabled.
Creates "Payment Channels" for XRP. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the [Interledger Protocol](https://interledger.org/). One party creates a Payment Channel and sets aside some XRP in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration.
Creates three new transaction types: `ChannelCreate`, `ChannelFund`, and `ChannelClaim`. Creates a new ledger node type, `Channel`. Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: `channel_authorize` (creates a signed Claim), `channel_verify` (verifies a signed Claim), and `account_channels` (lists Channels associated with an account).
Creates three new transaction types:[PaymentChannelCreate][], [PaymentChannelClaim][], and [PaymentChannelFund][]. Creates a new ledger node type, [PayChannel](reference-ledger-format.html#paychannel). Defines an off-ledger data structure called a `Claim`, used in the ChannelClaim transaction. Creates new `rippled` API methods: `channel_authorize` (creates a signed Claim), `channel_verify` (verifies a signed Claim), and `account_channels` (lists Channels associated with an account).
<!--{# TODO: Add links to the relevant docs above when they are ready #}-->
For more information, see the [Payment Channels Tutorial](tutorial-paychan.html).
## SHAMapV2

10
content/tutorial-paychan.md
View File

@@ -20,12 +20,12 @@ The example addresses used in this tutorial are:
| | |
|--|--|
| Payer's address | rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH |
| Public key used for channel (in base58) | aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3
| Public key used for channel (in hex) | 023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6 |
| Payee's address | rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn |
| **Payer's address** | rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH |
| **Public key used for channel (in base58)** | aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3
| **Public key used for channel (in hex)** | 023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6 |
| **Payee's address** | rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn |
**Tip:** In this example, we use the public key from the payer's master key pair as the key pair for the channel. This is perfectly safe and valid. It is also perfectly safe and valid to use a different key pair, as long as only the payer knows the public and secret keys for that key pair. <!-- Editor's note: We don't have a good page to link to explain key pairs as of time of this writing. -->
**Tip:** In this example, the channel's public key is the public key from the payer's master key pair. This is perfectly safe and valid. It is also perfectly safe and valid to use a different key pair, as long as only the payer knows the public and secret keys for that key pair. <!-- Editor's note: We don't have a good page to link to explain key pairs as of time of this writing. -->
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**.

2
tool/dactyl-config.yml
View File

@@ -58,6 +58,7 @@ targets:
"tutorial-rippleapi-beginners-guide.html": https://ripple.com/build/rippleapi-beginners-guide/
"tutorial-rippled-setup.html": https://ripple.com/build/rippled-setup/
"tutorial-gateway-guide.html": https://ripple.com/build/gateway-guide/
"tutorial-paychan.html": https://ripple.com/build/payment-channels-tutorial/
"concept-accounts.html": https://ripple.com/build/accounts/
"concept-amendments.html": https://ripple.com/build/amendments/
"concept-fee-voting.html": https://ripple.com/build/fee-voting/
@@ -92,6 +93,7 @@ targets:
"img/noripple-05.png": https://ripple.com/wp-content/uploads/2015/01/noripple-05.png
"img/noripple-06.png": https://ripple.com/wp-content/uploads/2015/01/noripple-06.png
"img/key-address-rels.png": https://ripple.com/wp-content/uploads/2017/05/key-address-rels.png
"img/paychan-flow.png": https://ripple.com/wp-content/uploads/2017/05/paychan-flow.png
- name: rippled-setup
display_name: rippled Setup Guide

10
tutorial-paychan.html
View File

@@ -182,24 +182,24 @@
</thead>
<tbody>
<tr>
<td>Payer's address</td>
<td><strong>Payer's address</strong></td>
<td>rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH</td>
</tr>
<tr>
<td>Public key used for channel (in base58)</td>
<td><strong>Public key used for channel (in base58)</strong></td>
<td>aB44YfzW24VDEJQ2UuLPV2PvqcPCSoLnL7y5M1EzhdW4LnK5xMS3</td>
</tr>
<tr>
<td>Public key used for channel (in hex)</td>
<td><strong>Public key used for channel (in hex)</strong></td>
<td>023693F15967AE357D0327974AD46FE3C127113B1110D6044FD41E723689F81CC6</td>
</tr>
<tr>
<td>Payee's address</td>
<td><strong>Payee's address</strong></td>
<td>rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn</td>
</tr>
</tbody>
</table>
<p class="devportal-callout tip"><strong>Tip:</strong> In this example, we use the public key from the payer's master key pair as the key pair for the channel. This is perfectly safe and valid. It is also perfectly safe and valid to use a different key pair, as long as only the payer knows the public and secret keys for that key pair. <!-- Editor's note: We don't have a good page to link to explain key pairs as of time of this writing. --></p>
<p class="devportal-callout tip"><strong>Tip:</strong> In this example, the channel's public key is the public key from the payer's master key pair. This is perfectly safe and valid. It is also perfectly safe and valid to use a different key pair, as long as only the payer knows the public and secret keys for that key pair. <!-- Editor's note: We don't have a good page to link to explain key pairs as of time of this writing. --></p>
<p>Additionally, you'll need a <code>rippled</code> server to send transactions to. The examples in this tutorial assume a <code>rippled</code> server is running on the test machine (<code>localhost</code>) with an unencrypted JSON-RPC API endpoint on port <strong>5005</strong>.</p>
<p>To test without transferring real XRP, you can use <a href="https://ripple.com/build/ripple-test-net/">Ripple Test Net</a> 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 <code>https://api.altnet.rippletest.net:51234</code> instead of <code>http://localhost:5005/</code>.</p>
<p>You can use any amount of XRP for the payment channels. The example values in this tutorial set aside 100 XRP (<code>100000000</code> drops) in a payment channel for at least 1 day.</p>