Add V2 implementation of payments:

Add a new algorithm for finding the liquidity in a payment path. There
is still a reverse and forward pass, but the forward pass starts at the
limiting step rather than the payment source. This insures the limiting
step is completely consumed rather than potentially leaving a 'dust'
amount in the forward pass.

Each step in a payment is either a book step, a direct step (account to
account step), or an xrp endpoint. Each step in the existing
implementation is a triple, where each element in the triple is either
an account of a book, for a total of eight step types.

Since accounts are considered in pairs, rather than triples, transfer
fees are handled differently. In V1 of payments, in the payment path
A -> gw ->B, if A redeems to gw, and gw issues to B, a transfer fee is
changed. In the new code, a transfer fee is changed even if A issues to
gw.
This commit is contained in:
seelabs
2015-11-15 13:20:26 -05:00
parent f3e93bbbeb
commit 122a5cdf89
44 changed files with 4654 additions and 223 deletions

View File

@@ -29,6 +29,11 @@
#include <ripple/app/paths/PathState.cpp>
#include <ripple/app/paths/RippleCalc.cpp>
#include <ripple/app/paths/RippleLineCache.cpp>
#include <ripple/app/paths/Flow.cpp>
#include <ripple/app/paths/impl/PaySteps.cpp>
#include <ripple/app/paths/impl/DirectStep.cpp>
#include <ripple/app/paths/impl/BookStep.cpp>
#include <ripple/app/paths/impl/XRPEndpointStep.cpp>
#include <ripple/app/paths/cursor/AdvanceNode.cpp>
#include <ripple/app/paths/cursor/DeliverNodeForward.cpp>