* Minimum factor 256*500, don't multiply by base fee
* Change autofill fee behavior to pay the open ledger fee.
** Experimental options: x-assume-tx - assume <int> more transactions in
the open queue when computing escalated fee, x-queue-okay - if true
and escalated fee is over limit, try with load fee.
* Port of 75af4ed.
* Use std::mutex instead of std::recursive_mutex
* Remove unnecessary type alias
* Use std::set instead of ripple::hash_map
* Don't reinvent virtual functions
The Owner count could decrease while evaluating a strand, causing
different behavior in forward passes and reverses passes. The fix treats
a decreased owner count like a deferred credit.
In some situations, deferred credits could cause an XRP balance to be
calculated as negative, triggering some asserts.
When XRP is used as a bridge currency, a path could be falsely marked as
dry. This happens when the XRP/XXX offer recursively checks the XXX/XRP
offer and the XXX/XRP offer could not satisfy the request in a single
call.
With a single strand and limit quality the old payment code incorrectly
computed with multiquailty set to true. This could cause the total
quality to go below the requested quality even if there was liquidity
available above the requested quality value.
* Revert 0efb929898
* Advisory delete setting of 0 (never) does not affect history fetching
The previous commit addressing RIPD-1112 could interact with
advisory delete and cause some history not to be acquired even
configured to acquire. This reverts that commit and provides
a better fix.
The advisory delete setting protects ledgers from being
removed by online delete by exempting them until they are
approved for purge by administrative command. However, not
connecting this with history acquisition could cause new
ledgers in the protected range not to be acquired if the
server loses sync.
With this change, the default advisory delete setting, zero (never)
causes the regular server history setting to control the acquisition
of history. Setting advisory delete to a value greater than zero,
if advisory delete is enabled, will cause the server to fetch and
maintain history back to that point.
This should produce sane behavior across server restarts, losses of
sync, and so on. You can no longer use the "hack" of setting
advisory delete to zero to tell the server to fetch and keep as much
history as possible, but you can achieve the same effect by setting
it to one.
* 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.
Before this change, the deferred credits algorithm took the current
balance and subtracted the recorded credits. Conceptually, this is the
same as taking the original balance, adding all the credits,
subtracting all the debits, and subtracting all the credits. The new
algorithm records the original balance and subtracts the debits. This
prevents errors that occur when the original balance and the recorded
credits have large differences in magnitude.
Additionally, XRP credits were recorded incorrectly in the deferred
credits table (the line was between the sender and receiver, rather than
the root account).
Calculate the number of file descriptors that are needed during
execution based on the configuration file, with a hard floor
of 1024, adjusting the limit if possible. Refuse to run if enough
fds are not available.
Additionally, allow administrators to limit the number of incoming
connections a configured port will accept. By default no limit is
imposed.
Payments do not remove unfunded and expired offers when a payment
fails. However, offer crossing is now using the payment engine and needs
to know what offers were found in a removable state, even on failure.
A computation like: `amount_remaining = amount_wanted - amount_got`, can
leave `amount_remaining == 0` without `amount_wanted == amount_got`.
This happens if the amounts differ by less than the smallest
representable value. Fix BookStep to handle this case.
Trusted master public keys can be listed under either [validators] or
[validator_keys] config sections. All keys listed under [validators] are
added to permanent trusted keys list regardless of key type.
A master public key is moved from permanent key list to manifest cache
when one of its manifests is received. This allows rippled operators to
list all trusted keys under the [validators] config section.
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.
The IP address used to perform pathfinding operations is now charged an
additional resource increment for each source currency in the path set.
* NOTE: This charge is a local resource charge, not a transaction fee
charge.
