* 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.
Passing in objects, arrays or non-string objects previously generated
nondescript errors. Improve the error messages returned to clients.
Add unit tests to ensure that incorrect inputs are reliably detected
and generate descriptive and accurate errors.
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.
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.
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.
* Add Validations.LedgerSeq and .InitialSeq fields.
* Clean up logging.
* Lower online delete minimum for standalone mode.
* Unit tests of online_delete.
The Journal API is affected. There are two uses for the
Journal::Severity enum:
o It is used to declare a threshold which log messages must meet
in order to be logged.
o It declares the current logging level which will be compared
to the threshold.
Those uses that affect the threshold are now named threshold()
rather than severity() to make the uses easier to distinguish.
Additionally, Journal no longer carries a Severity variable.
All handling of the threshold() is now delegated to the
Journal::Sink.
Sinks are no longer constructed with a default threshold of
kWarning; their threshold must be passed in on construction.
The caller of the account_info RPC command can optionally
specify that they want the account's SignerList returned by
adding the argument:
"signer_lists": "true"
The returned SignerList is in an array. This leaves us room to
support multiple signer lists on an account in the future without
changing the syntax of the result.
The command-line version of account_info does not support the new
option.
The RippleAddress class was used to represent a number of fundamentally
different types: account public keys, account secret keys, node public
keys, node secret keys, seeds and generators.
The class is replaced by the following types:
* PublicKey for account and node public keys
* SecretKey for account and node private keys
* Generator for generating secp256k1 accounts
* Seed for account, node and generator seeds
The new code removes the ability to specify domain names
in the [validators] configuration block, and no longer
supports the [validators_site] option.
More details on the supported configurations are available
under doc/rippled-example.cfg.
* A new, unified interface for generating random numbers and
filling buffers supporting any engine that fits the
UniformRandomNumberGenerator concept;
* Automatically seeded replacement for rand using the fast
xorshift+ PRNG engine;
* A CSPRNG engine that can be used with the new framework
when needing to to generate cryptographically secure
randomness.
* Unit test cleanups to work with new engine.
