* After successfully applying a transaction to the open ledger, resubmit any held transactions from the same account.
* All held transactions will continue to be retried after consensus round.
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.
* Make LedgerConsensus object a singleton
* Protect consensus structures with their own locks
* Simplify NetworkOPs interaction with LedgerConsensus
* Log when we build and validate the same ledger
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
Subscribe to "peer_status" stream (admin only) permits
reception of "peerStatusChange" notifications.
These can include the event the peer is reporting, the peer's
new status, the peer's currently accepted ledger hash and sequence,
the peer's network time, and the range of ledgers the peer has
available for remote querying.
* Move InboundTransactions to app/ledger
* Move TransactionAcquire to app/ledger
* Move LocalTxs to app/ledger
* Move Transaction to app/misc
* Move TransactionMaster to app/ledger
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
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.
* Remove ripple::RippleMutex and ripple::RippleRecursiveMutex
and use std::mutex and std::recursive_mutex respectively.
* Use std::lock_guard instead of std::unique_lock when the
additional features of std::unique_lock are not needed.
The server's open ledger is now an instance of the OpenView
class, managed by an instance of the OpenLedger class. This
should improve the performance of operations on open ledgers
because they are no longer Ledger/SHAMap operation.
Eventually multisign will need to be enabled onto the network, at
which point compiling it in or out will no longer be an option.
In preparation, the compile guards are removed and multisign is
being enabled with a Feature.
You can locally enable a Feature using your config file. To
enable multisign with your config file add a section like this:
[features]
MultiSign
The exact spelling and capitalization of both "features" and
"MultiSign" is important. If you don't get those right multisign
will not be enabled.
There is a minor issue. The "sign_for" and "submit_multisigned"
RPC commands are only enabled if multisign is enabled. However
those commands are still shown in the help message even if
multisign is disabled. This is because the code that produces
the help message doesn't read the config file (where the Features
are kept). This problem will become irrelevant once multisign is
enabled onto the network.
* Consider ledgers incompatible based on last valid ledger
* Test against even ledgers not acquired yet
* Don't validate an incompatible ledger
* Don't switch to an incompatible ledger
* Protect against an unreasonably small quorum
* Remove ltCURRENT
* Change getOwnerInfo
* Use ReadView in TransactionSign
* Change AcceptedLedger and ProposedTransaction to use ReadView
* Change RPC::accounts
An instance of Rules provides information on the tx
processing rules in a particular ledger.
* OpenView allows rules to be set on construction.
Conflicts:
src/ripple/unity/ledger.cpp
