There was a bug in version 0.30.1 where signing with an ed25519
key and a corrupt seed would cause the "sign" and "sign_for"
commands to return an unexpected error. That bug was fixed in
the 0.31.0 release.
These unit tests verify the fix. The error message for a corrupt
seed is also slightly improved.
* Updates many (but probably not all) locations that access base_uint
private storage.
* More calls to access base_uint through members.
* Use an iterator to write Serializer collections.
The CBigNum class is a wrapper around OpenSSL's BIGNUM implementation
to make use simpler.
Replacing the implementation with boost::multiprecision helps reduce
the size of the codebase and improves performance (benchmarks show
the new boost-based implementation is ~7x faster).
* Tweak account XRP balance and sequence if needed before preclaim.
* Limit total fees in flight to minimum reserve / account balance.
* LastLedgerSequence must be at least 2 more than the current ledger to be queued.
* Limit 10 transactions per account in the queue at a time.
* Limit queuing multiple transactions after transactions that affect authentication.
* Zero base fee transactions are treated as having a fixed fee level of 256000 instead of infinite.
* Full queue: new txn can only kick out a tx if the fee is higher than that account's average fee.
* Queued tx retry limit prevents indefinitely stuck txns.
* Return escalation factors in server_info and _state when escalated.
* Update documentation.
* Update experimental config to only include the % increase.
* Convert TxQ metric magic numbers to experimental config.
Replace Journal public data members with member function accessors
in order to make Journal lighter weight. The change makes a
Journal cheaper to pass by value.
Also add missing stream checks (e.g., calls to JLOG) to avoid
text processing that ultimately will not be stored in the log.
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.
In some cases multiplying or dividing STAmounts gave incorrect results.
This happens when:
1) The result should be rounded up
2) The STAmount represents a native value (XRP)
3) The rounded up value was less than one drop
In this case, the result was zero, instead of one drop. This could
cause funded offers to be removed as unfunded.
Include the ledger sequence number in fee change transactions to ensure
each such transaction has a unique transaction ID.
We tolerate the absence of a ledger sequence in fee change transactions so
that past fee change transactions remain parseable. Since no live amendment
transactions have yet happened, there is no need to tolerate an absent
ledger sequence there.
