From cf8438fe1d532f937881d7a92edffe772e3b209e Mon Sep 17 00:00:00 2001 From: Crypto Brad Garlinghouse Date: Fri, 12 Mar 2021 15:14:54 +0300 Subject: [PATCH] Remove obsolete URLs and references to Ripple --- docs/consensus.md | 2 +- src/ripple/app/misc/FeeEscalation.md | 12 +- src/ripple/app/paths/Pathfinder.cpp | 3 +- src/ripple/app/paths/README.md | 137 ---------------- src/ripple/app/tx/README.md | 211 ------------------------- src/ripple/app/tx/impl/Escrow.cpp | 8 +- src/ripple/app/tx/impl/Payment.cpp | 2 - src/ripple/app/tx/impl/Payment.h | 2 - src/ripple/basics/chrono.h | 2 +- src/ripple/net/ShardDownloader.md | 6 +- src/ripple/nodestore/README.md | 6 +- src/ripple/protocol/impl/PublicKey.cpp | 2 +- src/test/core/Config_test.cpp | 2 +- src/test/jtx/Env.h | 2 +- 14 files changed, 22 insertions(+), 375 deletions(-) delete mode 100644 src/ripple/app/paths/README.md delete mode 100644 src/ripple/app/tx/README.md diff --git a/docs/consensus.md b/docs/consensus.md index 1423786b0..c811b6f37 100644 --- a/docs/consensus.md +++ b/docs/consensus.md @@ -4,7 +4,7 @@ Consensus is the task of reaching agreement within a distributed system in the presence of faulty or even malicious participants. This document outlines the -[Ripple Consensus Algorithm](https://ripple.com/files/ripple/consensus/whitepaper.pdf) +[XRP Ledger Consensus Algorithm](https://arxiv.org/abs/1802.07242) as implemented in [rippled](https://github.com/ripple/rippled), but focuses on its utility as a generic consensus algorithm independent of the detailed mechanics of the Ripple Consensus Ledger. Most notably, the algorithm diff --git a/src/ripple/app/misc/FeeEscalation.md b/src/ripple/app/misc/FeeEscalation.md index 4e1951931..034d59a41 100644 --- a/src/ripple/app/misc/FeeEscalation.md +++ b/src/ripple/app/misc/FeeEscalation.md @@ -188,9 +188,9 @@ lower) fee to get into the same position as a reference transaction. For consensus to be considered healthy, the consensus process must take less than 5 seconds. This time limit was chosen based on observed past -behavior of the ripple network. Note that this is not necessarily the -time between ledger closings, as consensus usually starts some amount -of time after a ledger opens. +behavior of the network. Note that this is not necessarily the time between +ledger closings, as consensus usually starts some amount of time after +a ledger opens. ### Other Constants @@ -213,7 +213,7 @@ than what the default would allow. This exact value was chosen experimentally, and can easily change in the future. * *Transaction queue size limit*. The limit is computed based on the base fee transaction limit per ledger, so that the queue can grow -automatically as the ripple network's performance improves, allowing +automatically as the network's performance improves, allowing more transactions per second, and thus more transactions per ledger to process successfully. The limit of 20 ledgers was used to provide a balance between resource (specifically memory) usage, and giving @@ -291,7 +291,7 @@ Result format: } ``` -### [`server_info`](https://ripple.com/build/rippled-apis/#server-info) command +### [`server_info`](https://xrpl.org/server_info.html) command **The fields listed here are still experimental, and may change without warning.** @@ -313,7 +313,7 @@ need to overcome `load_factor_fee_escalation`, though if it does not, it is more likely to be queued than immediately processed into the open ledger. -### [`server_state`](https://ripple.com/build/rippled-apis/#server-state) command +### [`server_state`](https://xrpl.org/server_state.html) command **The fields listed here are still experimental, and may change without warning.** diff --git a/src/ripple/app/paths/Pathfinder.cpp b/src/ripple/app/paths/Pathfinder.cpp index f6908e29a..b11d45c31 100644 --- a/src/ripple/app/paths/Pathfinder.cpp +++ b/src/ripple/app/paths/Pathfinder.cpp @@ -444,8 +444,7 @@ Pathfinder::computePathRanks(int maxPaths) static bool isDefaultPath(STPath const& path) { - // TODO(tom): default paths can consist of more than just an account: - // https://forum.ripple.com/viewtopic.php?f=2&t=8206&start=10#p57713 + // FIXME: default paths can consist of more than just an account: // // JoelKatz writes: // So the test for whether a path is a default path is incorrect. I'm not diff --git a/src/ripple/app/paths/README.md b/src/ripple/app/paths/README.md deleted file mode 100644 index 938744129..000000000 --- a/src/ripple/app/paths/README.md +++ /dev/null @@ -1,137 +0,0 @@ -Theory of Pathfinding -===================== - -It's a hard problem - an exponential problem - and there is a limited amount of time until the ledger changes. - -Search for the best path, but it's impossible to guarantee the result is the best unless the ledger is small. - -Also, the current state of the ledger can't be definitively known. We only know the state of past ledgers. - -By the time a transaction is processed, liquidity may be taken or added. This is why payments support a maximum cost. - -People are given estimates so they can make a decision as to whether the overall cost is good enough for them. - -This is the **rippled** implementation; there are many other possible implementations! - -**rippled** uses a variety of search techniques: - -1. Hebbian learning. - * Reuse found liquidity. - * Good liquidity is often reusable. - * When searching, limit our search to the rippled cache. -2. Six degrees of separation. - * If sending value through individual's account, expect no path to have more than six hops. - * According to [Facebook studies](https://www.facebook.com/notes/facebook-data-team/anatomy-of-facebook/10150388519243859) as of late 2011, its users are separated by fewer than five steps. - * By using XRP for bridging the most complicated path expected is usually: - * source -> gateway -> XRP -> gateway -> destination -3. Pareto principle. - * Good liquidity is often reusable. - * Concentrate on the most liquid gateways to serve almost everybody. - * People who chose to use illiquid gateways get the service level implied by their choice of poor liquidity. -4. Monte Carlo methods. - * Learn new paths. - * Search outside the **rippled** cache. - * Distributed learning. - * Every rippled node searches their own cache for best liquidity and then the good results get propagated to the network. - * Whenever somebody makes a payment, the nodes involved go to the rippled cache; since payments appear in every ledger in the network, this liquidity information now appears in every rippled cache. - - -Life of a Payment -====================== - -Overview ----------- - -Making a payment in the ripple network is about finding the cheapest path between source and destination. - -There are various stages: - -An issue is a balance in some specific currency. An issuer is someone who "creates" a currency by creating an issue. - -For tx processing, people submit a tx to a rippled node, which attempts to apply the tx locally first, and if succeesful, distributes it to other nodes. - -When someone accepts payment they list their specific payment terms, "what must happen before the payment goes off." That can be done completely in the Ripple Network. Normally a payment on the Ripple net can be completely settled there. When the ledger closes, the terms are met, or they are not met. - -For a bridge payment, based on a previous promise it will deliver payment off-network. A bridge promises to execute the final leg of a payment, but there's the possibility of default. If you want to trust a bridge for a specific pathfinding request, you need to include it in the request. - -In contrast, a gateway is in the business of redeeming value on the Ripple Network for value off the Ripnet. A gateway is in the business of issuing balances. - -Bitstamp is a gateway - you send 'em cash, they give you a ripple balance and vice versa. There's no promise or forwarding for a transaction. - -A bridge is a facility that allows payments to be made from the Ripnet to off the Ripnet. - -Suppose I'm on the Ripple network and want to send value to the bitcoin network. See: https://ripple.com/wiki/Outbound_Bridge_Payments -https://ripple.com/wiki/Services_API - - -Two types of paths: -1. I have X amount of cash I wish to send to someone - how much will they receive? - * not yet implemented in pathfinding, or at least in the RPC API. - * TODO: find if this is implemented and either document it or file a JIRA. -2. I need to deliver X amount of cash to someone - how much will it cost me? - -Here's a transaction: -https://ripple.com/wiki/Transaction_Format#Payment_.280.29 - -Not implemented: bridge types. - - - -High level of a payment ------------------------ - -1. I make a request for path finding to a rippled. -2. That rippled "continuously" returns solutions until I "stop". -3. You create a transaction which includes the path set that you got from the quote. -4. You sign it. -5. You submit it to one or more rippleds. -6. Those rippled validates it, and forwards it if it;s valid. - * valid means "not malformed" and "can claim a fee" - the sending account has enough to cover the transaction fee. -7. At ledger closing time, the transaction is applied by the transaction engine and the result is stored by changing the ledger and storing the tx metadata in that ledger. - -If you're sending and receiving XRP you don't need a path. -If the union of the default paths are sufficient, you don't need a path set (see below about default paths). -The idea behind path sets is to provide sufficient liquidity in the face of a changing ledger. - -If you can compute a path already yourself or know one, you don't need to do steps 1 or 2. - - -1. Finding liquidity - "path finding" - * finding paths (exactly "path finding") - * filtering by liquidity. - * take a selection of paths that should satisfy the transaction's conditions. - * This routine is called RippleCalc::rippleCalc. - -2. Build a payment transaction containing the path set. - * a path set is a group of paths that a transaction is supposed to use for liquidity - * default paths are not included - * zero hop path: a default path is "source directly to destination". - * one hop paths - because they can be derived from the source and destination currency. - * A payment transaction includes the following fields - * the source account - * the destination account - * destination amount - * contains an amount and a currency - * if currency not XRP, must have a specified issuer. - * If you specify an issuer then you MUST deliver that issuance to the destination. - * If you specify the issuer as the destination account, then they will receive any of the issuances they trust. - * maximum source amount - maximum amount to debit the sender. - * This field is optional. - * if not specified, defaults to the destination amount with the sender as issuer. - * contains an amount and a currency - * if currency not XRP, must have a specified issuer. - * specifying the sender as issuer allows any of the sender's issuance to be spent. - * specifying a specific issuer allows only that specific issuance to be sent. - * path set. - * Optional. - * Might contain "invalid" paths or even "gibberish" for an untrusted server. - * An untrusted server could provide proof that their paths are actually valid. - * That would NOT prove that this is the cheapest path. - * The client needs to talk to multiple untrusted servers, get proofs and then pick the best path. - * It's much easier to validate a proof of a path than to find one, because you need a lot of information to find one. - * In the future we might allow one server to validate a path offered by another server. - -3. Executing a payment - * very little time, can't afford to do a search. - * that's why we do the path building before the payment is due. - * The routine used to compute liquidity and ledger change is also called RippleCalc::rippleCalc. diff --git a/src/ripple/app/tx/README.md b/src/ripple/app/tx/README.md deleted file mode 100644 index f5d94e128..000000000 --- a/src/ripple/app/tx/README.md +++ /dev/null @@ -1,211 +0,0 @@ - -# Transactors # - -## Introduction ## - -Each separate kind of transaction is handled by it's own Transactor. -The Transactor base class provides functionality that is common to -all derived Transactors. The Transactor base class also gives derived -classes the ability to replace portions of the default implementation. - - -# Details on Specific Transactors # - -## AddWallet ## - -## Change ## - -## Offers ## - -### CreateOffer ### - -### CancelOffer ### - -## Payment ## - -## SetAccount ## - -## SetRegularKey ## - -## SetSignerList ## - -In order to enhance the flexibility of Ripple and provide support for enhanced -security of accounts, native support for "multi-signature" or "multi-sign" -accounts is required. - -Transactions on an account which is designated as multi-sign can be authorized -either by using the master or regular keys (unless those are disabled) or by -being signed by a certain number (a quorum) of pre-authorized accounts. - -Some technical details, including tables indicating some of the Ripple -commands and ledger entries to be used for implementing multi-signature, are -currently listed on the [wiki](https://ripple.com/wiki/Multisign) but will -eventually be migrated into this document as well. - -For accounts which are designated as multi-sign, there must be a list which -specifies which accounts are authorized to sign and the quorum threshold. - - - Each authorized account has a weight. The sum of the weights of the signers is used to determine whether a given set of signatures is sufficient for a quorum. - - - The quorum threshold indicates the minimum required weight that the sum of the weights of all signatures must have before a transaction can be authorized. - -### Verification of Multiple Signatures During TX Processing -The current approach to adding multi-signature support is to require that a -transaction is to be signed outside the Ripple network and only submitted -after the quorum has been reached. - -This reduces the implementation footprint and the load imposed on the network, -and mirrors the way transaction signing is currently handled. It will require -some messaging mechanism outside the Ripple network to disseminate the proposed -transaction to the authorized signers and to allow them to apply signatures. - -Supporting in-ledger voting should be considered, but it has both advantages -and disadvantages. - -One of the advantages is increased transparency - transactions are visible as -are the "votes" (the authorized accounts signing the transaction) on the -ledger. However, transactions may also languish for a long time in the ledger, -never reaching a quorum and consuming network resources. - -### Signature Format -We should not develop a new format for multi-sign signatures. Instead every -signer should extract and sign the transaction as they normally would if this -were a regular transaction. The resulting signature will be stored as a triple -of { signing-account, signer-public-key, signature } in an array of signatures -associated with this transaction. - -The advantage of this is that we can reuse the existing signing and -verification code, and leverage the work that will go towards implementing -support for the Ed25519 elliptic curve. - -### Fees ### -Multi-signature transactions impose a heavier load on the network and should -claim higher fees. - -The fee structure is not yet decided, but an escalating fee structure is laid -out and discussed on the [wiki](https://ripple.com/wiki/Multisign). This -might need to be revisited and designed in light of discussions about changing -how fees are handled. - -### Proposed Transaction Cancellation ### -A transaction that has been proposed against a multi-sign account using a -ticket can be positively canceled if a quorum of authorized signers sign and -issue a transaction that consumes that ticket. - -### Implementation ### - -Any account can have one SignerList attached to it. A SignerList contains the -following elements: - - - A list of from 1 to a protocol-defined maximum of 8 signers. Each signer in the array consists of: - - The signer's 160-bit account ID and - - The signer's 16-bit weight (used to calculate whether a quorum is met). - - And, for the entire list, a single 32-bit quorum value. - -Giving the signers different weights allows an account to organize signers so -some are more important than others. A signer with a larger weight has more -significance in achieving the quorum. - -A multi-signed transaction is validated like this: - - - Each signer of the transaction has their signature validated. - - The weights of all valid signers are summed. - - If the sum of the weights equals or exceeds the quorum value then the entire transaction is considered signed. If the sum is below the quorum, then the signature fails with a tefBAD_QUORUM. - - -By making the signer weights 16 bits and the quorum value 32 bits we avoid -concerns about overflows and still have plenty of resolution. - -This transactor allows two operations: - - - Create (or replace) a signer list for the target account. - - Remove any signer list from the target account. - -The data for a transaction creating or replacing a signer list has this -general form: - - { - "TransactionType": "SignerListSet", - "Account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd", - "SignerQuorum": 7, - "SignerEntries": [ - { - "SignerEntry": { - "Account": "rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA", - "SignerWeight": 4 - } - }, - { - "SignerEntry": { - "Account": "rPcNzota6B8YBokhYtcTNqQVCngtbnWfux", - "SignerWeight": 3 - } - } - ] - } - -The data for a transaction that removes any signer list has this form: - - { - "TransactionType": "SignerListSet", - "Account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd", - "SignerQuorum": 0 - } - -## SetTrust ## - -## Tickets ## - -Currently transactions on the Ripple network require the use of sequence -numbers and sequence numbers must monotonically increase. Since the sequence -number is part of the transaction, it is "covered" by the signature that -authorizes the transaction, which means that the sequence number would have -to be decided at the time of transaction issuance. This would mean that -multi-signature transactions could only be processed in strict "first-in, -first-out" order which is not practical. - -Tickets can be used in lieu of sequence number. A ticket is a special token -which, through a transaction, can be issued by any account and can be -configured with an optional expiry date and an optional associated account. - -### Specifics ### - -The expiry date can be used to constrain the validity of the ticket. If -specified, the ticket will be considered invalid and unusable if the closing -time of the last *validated* ledger is greater than or equal to the expiration -time of the ticket. - -The associated account can be used to specify an account, other than the -issuing account, that is allowed to "consume" the ticket. Consuming a ticket -means to use the ticket in a transaction that is accepted by the network and -makes its way into a validated ledger. If not present, the ticket can only be -consumed by the issuing account. - -*Corner Case:* It is possible that two or more transactions reference the same -ticket and that both go into the same consensus set. During final application -of transactions from the consensus set at most one of these transactions may -succeed; others must fail with the indication that the ticket has been consumed. - -*Reserve:* While a ticket is outstanding, it should count against the reserve -of the *issuer*. - -##### Issuance -We should decide whether, in the case of multi-signature accounts, any single -authorized signer can issue a ticket on the multi-signature accounts' behalf. -This approach has both advantages and disadvantages. - -Advantages include: - -+ Simpler logic for tickets and reduced data - no need to store or consider an associated account. -+ Owner reserves for issued tickets count against the multi-signature account instead of the account of the signer proposing a transaction. -+ Cleaner meta-data: easier to follow who issued a ticket and how many tickets are outstanding and associated with a particular account. - -Disadvantages are: - -+ Any single authorized signer can issue multiple tickets, each counting against the account's reserve. -+ Special-case logic for authorizing tickets on multi-sign accounts. - -I believe that the disadvantages outweigh the advantages, but debate is welcome. - - -### CreateTicket ### diff --git a/src/ripple/app/tx/impl/Escrow.cpp b/src/ripple/app/tx/impl/Escrow.cpp index e033c989a..1dbc6d5a5 100644 --- a/src/ripple/app/tx/impl/Escrow.cpp +++ b/src/ripple/app/tx/impl/Escrow.cpp @@ -58,22 +58,22 @@ namespace ripple { expiration time, the XRP can only be returned to the sender. For more details on escrow, including examples, diagrams and more please - visit https://ripple.com/build/escrow/#escrow + visit https://xrpl.org/escrow.html For details on specific transactions, including fields and validation rules please see: `EscrowCreate` -------------- - See: https://ripple.com/build/transactions/#escrowcreate + See: https://xrpl.org/escrowcreate.html `EscrowFinish` -------------- - See: https://ripple.com/build/transactions/#escrowfinish + See: https://xrpl.org/escrowfinish.html `EscrowCancel` -------------- - See: https://ripple.com/build/transactions/#escrowcancel + See: https://xrpl.org/escrowcancel.html */ //------------------------------------------------------------------------------ diff --git a/src/ripple/app/tx/impl/Payment.cpp b/src/ripple/app/tx/impl/Payment.cpp index 55fffca93..50045da8d 100644 --- a/src/ripple/app/tx/impl/Payment.cpp +++ b/src/ripple/app/tx/impl/Payment.cpp @@ -28,8 +28,6 @@ namespace ripple { -// See https://ripple.com/wiki/Transaction_Format#Payment_.280.29 - TxConsequences Payment::makeTxConsequences(PreflightContext const& ctx) { diff --git a/src/ripple/app/tx/impl/Payment.h b/src/ripple/app/tx/impl/Payment.h index 9c2f35472..1d4711198 100644 --- a/src/ripple/app/tx/impl/Payment.h +++ b/src/ripple/app/tx/impl/Payment.h @@ -27,8 +27,6 @@ namespace ripple { -// See https://ripple.com/wiki/Transaction_Format#Payment_.280.29 - class Payment : public Transactor { /* The largest number of paths we allow */ diff --git a/src/ripple/basics/chrono.h b/src/ripple/basics/chrono.h index e0403bed7..f50d765d5 100644 --- a/src/ripple/basics/chrono.h +++ b/src/ripple/basics/chrono.h @@ -40,7 +40,7 @@ using days = std::chrono::duration< using weeks = std::chrono:: duration>>; -/** Clock for measuring Ripple Network Time. +/** Clock for measuring the network time. The epoch is January 1, 2000 epoch_offset = days(10957); // 2000-01-01 diff --git a/src/ripple/net/ShardDownloader.md b/src/ripple/net/ShardDownloader.md index 96938acb1..ded58bbe2 100644 --- a/src/ripple/net/ShardDownloader.md +++ b/src/ripple/net/ShardDownloader.md @@ -208,9 +208,9 @@ used instead. ```dosini # This is the persistent datastore for shards. It is important for the health -# of the ripple network that rippled operators shard as much as practical. -# NuDB requires SSD storage. Helpful information can be found here -# https://ripple.com/build/history-sharding +# of the network that rippled operators shard as much as practical. +# NuDB requires SSD storage. Helpful information can be found on +# https://xrpl.org/history-sharding.html [shard_db] type=NuDB path=/var/lib/rippled/db/shards/nudb diff --git a/src/ripple/nodestore/README.md b/src/ripple/nodestore/README.md index 6e8b5e004..7b004f67a 100644 --- a/src/ripple/nodestore/README.md +++ b/src/ripple/nodestore/README.md @@ -275,9 +275,9 @@ and several paths for historical storage: ```dosini # This is the persistent datastore for shards. It is important for the health -# of the ripple network that rippled operators shard as much as practical. -# NuDB requires SSD storage. Helpful information can be found here -# https://ripple.com/build/history-sharding +# of the network that server operators shard as much as practical. +# NuDB requires SSD storage. Helpful information can be found on +# https://xrpl.org/history-sharding.html [shard_db] type=NuDB diff --git a/src/ripple/protocol/impl/PublicKey.cpp b/src/ripple/protocol/impl/PublicKey.cpp index e1c6c5fd3..9fed78088 100644 --- a/src/ripple/protocol/impl/PublicKey.cpp +++ b/src/ripple/protocol/impl/PublicKey.cpp @@ -106,7 +106,7 @@ sliceToHex(Slice const& slice) @param strict_param whether to enforce strictly canonical semantics @note For more details please see: - https://ripple.com/wiki/Transaction_Malleability + https://xrpl.org/transaction-malleability.html https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623 https://github.com/sipa/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c */ diff --git a/src/test/core/Config_test.cpp b/src/test/core/Config_test.cpp index ca0d677be..09685d32c 100644 --- a/src/test/core/Config_test.cpp +++ b/src/test/core/Config_test.cpp @@ -68,7 +68,7 @@ medium # This is primary persistent datastore for rippled. This includes transaction # metadata, account states, and ledger headers. Helpful information can be -# found here: https://ripple.com/wiki/NodeBackEnd +# found on https://xrpl.org/capacity-planning.html#node-db-type # delete old ledgers while maintaining at least 2000. Do not require an # external administrative command to initiate deletion. [node_db] diff --git a/src/test/jtx/Env.h b/src/test/jtx/Env.h index 529a6b739..23d6dca4e 100644 --- a/src/test/jtx/Env.h +++ b/src/test/jtx/Env.h @@ -254,7 +254,7 @@ public: return *bundle_.timeKeeper; } - /** Returns the current Ripple Network Time + /** Returns the current network time @note This is manually advanced when ledgers close or by callers.