Replace Taker.cpp with calls to the payment flow() code.
This change required a number of tweaks in the payment flow code.
These tweaks are conditionalized on whether or not offer crossing
is taking place. The flag is explicitly passed as a parameter to
the flow code.
For testing, a class was added that identifies differences in the
contents of two PaymentSandboxes. That code may be reusable in
the future.
None of the Taker offer crossing code is removed. Both versions
of the code are co-resident to support an amendment cut-over.
The code that identifies differences between Taker and Flow offer
crossing is enabled by a feature. That makes it easy to enable
or disable difference logging by changing the config file. This
approach models what was done with the payment flow code. The
differencing code should never be enabled on a production server.
Extensive offer crossing unit tests are added to examine and
verify the behavior of corner cases. The tests are currently
configured to run against both Taker and Flow offer crossing.
This gives us confidence that most cases run identically and
some of the (few) differences in behavior are documented.
Add new functionality to enforce one or more sanity checks (invariants)
on transactions. Add tests for each new invariant check. Allow
for easily adding additional invariant checks in the future.
Also Resolves
-------------
- RIPD-1426
- RIPD-1427
- RIPD-1428
- RIPD-1429
- RIPD-1430
- RIPD-1431
- RIPD-1432
Release Notes
-------------
Creates a new ammendment named "EnforceInvariants" which must be
enabled in order for these new checks to run on each transaction.
The 'type' field allows the rpc client to specify what type of ledger
entries to retrieve. The available types are:
"account"
"amendments"
"directory"
"fee"
"hashes"
"offer"
"signer_list"
"state"
"ticket"
This is a substantial refactor of the consensus code and also introduces
a basic consensus simulation and testing framework. The new generic/templated
version is in src/ripple/consensus and documents the current type requirements.
The version adapted for the RCL is in src/ripple/app/consensus. The testing
framework is in src/test/csf.
Minor behavioral changes/fixes include:
* Adjust close time offset even when not validating.
* Remove spurious proposing_ = false call at end of handleLCL.
* Remove unused functionality provided by checkLastValidation.
* Separate open and converge time
* Don't send a bow out if we're not proposing
* Prevent consensus stopping if NetworkOPs switches to disconnect mode while
consensus accepts a ledger
* Prevent a corner case in which Consensus::gotTxSet or Consensus::peerProposal
has the potential to update internal state while an dispatched accept job is
running.
* Distinguish external and internal calls to startNewRound. Only external
calls can reset the proposing_ state of consensus
* Sanity check on newly created strands
* Better loop detection
* Better tests (test every combination of path element pairs)
* Disallow any root issuer (even for xrp)
* Disallow compount element typs in path
* Issue was not reset when currency was XRP
* Add amendment
Escrow replaces the existing SusPay implementation with improved
code that also adds hashlock support to escrow payments, making
RCL ILP enabled.
The new functionality is under the `Escrow` amendment, which
supersedes and replaces the `SusPay` amendment.
This commit also deprecates the `CryptoConditions` amendment
which is replaced by the `CryptoConditionSuite` amendment which,
once enabled, will allow use of cryptoconditions others than
hashlocks.
The deferred credits table can compute a balance that's different from the
ledger balance.
Syntax:
A number written with no decimal means that number exactly. I.e. "12". A number
written with a decimal means that number has a non-zero digit at the lowest
order digit. I.e. "12.XX" means a number like "12.00000000000005"
Consider the following payment:
alice (USD) -> USD/XRP -> (XRP) Bob
Alice initially has 12.XX USD in her account.
The strand is used to debit alice the following amounts:
1) Debit alice 5
2) Debit alice 0.XX
3) Debit alice 3.XX
The next time the strand is explored, alice has a USD/XRP offer on the books,
and her account is credited:
1) Credit alice 20
When the beginning of the strand is reached, consider what happens when alice is
a limiting step. Calculate how much we can get out the step. According to the
deferred credit table this is:
12.XX - (5 + 0.XX + 3.XX)
This is also limited by alice's balance, which is large thanks to the credit she
received in the book step.
Now that the step has calculated how much we can get out, throw out the
sandbox (the one with the credit), and re-execute. However, the following error
occurs. We asked for 12.XX - (5 + 0.XX + 3.XX). However, the ledger has
calculated that alice has:
((12.XX - 5) - 0.XX) - 3.XX
That's a problem, because that number is smaller. Notice that there are two
precision losing operations in the deferred credits table:
1) The 5 + 0.XX step
2) The 12.XX - (total of debits). (Notice total of debits is < 10)
However, there is only one precision losing operation in the ledger calculation:
1) (Subtotal of 12.XX-5) - 0.XX
That means the calculation for the ledger results in a number that's smaller
than the deferred credits. Flow detects this as a re-execution error.
Add an amendment to allow gateways to set a "tick size"
for assets they issue. There are no changes unless the
amendment is enabled (since the tick size option cannot
be set).
With the amendment enabled:
AccountSet transactions 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.
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 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.
Gateways must enable a TickSize on their account for this
feature to benefit them.
The primary expected benefit is the elimination of bots
fighting over the tip of the order book. This means:
- Quicker price discovery as outpricing someone by a
microscopic amount is made impossible. Currently
bots can spend hours outbidding each other with no
significant price movement.
- A reduction in offer creation and cancellation spam.
- More offers left on the books as priority means
something when you can't outbid by a microscopic amount.
