tapENABLE_TESTING is removed from checks, and feature enablement
is the sole method for activating features. Unit tests are updated
to enable required features in the construction of the Env.
Tickets are put on a feature switch instead of a build macro.
* Remove the ability to construct an empty transaction by type, only
to then have to add fields to it. Instead, offer a constructor that
accepts a transaction type and a lambda that can insert fields into
the STTx during construction.
* Remove now obsolete boost::optional transaction ID.
This is designed for use by proxies in front of rippled. Configured IPs
can forward identifying user data in HTTP headers, including
user name and origin IP. If the user name exists, then resource limits
are lifted for that session. However, administrative commands are still
reserved only for administrative sessions.
* Expire validations faster based on when we first saw them.
* Never jump to a ledger prior to the latest fully-valid ledger
* Drop validations with signing times too far in the future immediately
Very small payment could fail when STAmount::mulRound underflowed
and returned zero, when it should have rounded up to the smallest
representable value.
Since a non-default STAccount is now guaranteed to always be
160 bits, it was possible to reduce the number of methods that
it provides.
In the process of narrowing the STAccount interface it became
reasonable to remove some methods that duplicated functionality.
A few classes offered both a value() and a getValue() method.
The getValue() method is removed from those classes.
If someone attempts to construct an STAccount with something
other than 160 bits the constructor now throws.
Since an STAccount now enforces that it always stores exactly
160 bits, we use a fixed-sized uint160 for the storage, replacing
a variable sized STBlob.
In order to leave the ledger and wire formats unaffected, the
STAccount still serializes and deserializes itself as though
it were variable length.
The first few transactions are added to the open ledger at
the base fee (ie. 10 drops). Once enough transactions are
added, the required fee will jump dramatically. If additional
transactions are added, the fee will grow exponentially.
Transactions that don't have a high enough fee to be applied to
the ledger are added to the queue in order from highest fee to
lowest. Whenever a new ledger is accepted as validated, transactions
are first applied from the queue to the open ledger in fee order
until either all transactions are applied or the fee again jumps
too high for the remaining transactions.
Current implementation is restricted to one transaction in the
queue per account. Some groundwork has been laid to expand in
the future.
Note that this fee logic escalates independently of the load-based
fee logic (ie. LoadFeeTrack). Submitted transactions must meet
the load fee to be considered for the queue, and must meet both
fees to be put into open ledger.
* Remove cxx14 compatibility layer from ripple
* Update travis to clang 3.6 and drop gcc 4.8
* Remove unneeded beast CXX14 defines
* Do not run clang build with gdb with travis
* Update circle ci to clang 3.6 & gcc-5
* Don't run rippled in gdb, clang builds crash gdb
* Staticly link libstdc++, boost, ssl, & protobuf
* Support builds on ubuntu 15.10
o Remove warning written to log by sign_for command.
o The sign_for RPC command previously only worked in the
"json sign_for" form. The command now works as a straight
"sign_for". The "offline" parameter also works.
o Don't autofill Fee or Paths when signing offline.
The digest for a transaction (its transaction ID, or tid) is
computed once upon constructed when the STTx is deserialized.
Subsequent calls to retrieve the digest use the cached value.
Any code which modifies the STTx and then attempts to
retrieve the digest will terminate the process with a
logic error contract violation.
* Nested types removed
* All STTx are contained as const
(Except in transaction sign, which must modify)
* tid in STTx is computed once on deserialization
* All checks flow through ripple::checkValidity, which transparently caches result flags.
* All external transaction submission code paths use checkValidity.
* SF_SIGGOOD flag no longer appears outside of HashRouter / checkValidity.
* Validity can be forced in known or trusted scenarios.
* Sanely handled specified ledger in account_tx
* Reject un-validated ledger in account_tx
* Wait to publish a ledger until it's indexed
* Add unit test for PendingSaves
