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.
With the addition of multisigning there are a variety of reasons
a signature may fail. We now return a more descriptive message
for the reason certain signature checks fail.
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
* 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.
* 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.
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.
* 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
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.
With this changeset two-level multisigning is removed from the
codebase and replaced with single-level multisigning.
Additionally, SignerLists in the ledger are prepared for the
possibility of multiple SignerLists per account. This was done
by adding a defaulted 32-bit SignerListID to each SignerList.
The SignerListIndex calculation incorporates the SignerListID.
There are three known missing elements:
1. Multisigned transactions should require higher fees than
regular (single-signed) transaction. That's not yet
implemented.
2. It should be possible to disable the master key on an account
if that account is multisign enabled (has a signer list).
That's not yet implemented.
3. Documentation about multisigning needs to be improved.
Multisigning is still compiled out of the code base. To enable
multisigning for a stand-alone rippled, change the
RIPPLE_ENABLE_MULTI_SIGN macro (in BeastConfig.h) to "1" and
rebuild.
This commit also addresses:
o RIPD-912: Remove multisign APIs from STObject, and
o RIPD-944: Replace common_transactor with jtx at call sites.
All AccountID functionality is removed from RippleAddress and
replaced with free functions. The AccountID to string conversion
cache is factored out as an explicit type with an instance in
the Application object. New base58 conversion functions are used,
with no dependence on OpenSSL.
All types and free functions related to AccountID are consolidated
into one header file. Routines to operate on "tokens" are also
introduced and consolidated into a single header file.
A token one of the cryptographic primitives used in Ripple:
Secret Seed
Server Public Key
Server Secret Key
Account ID
Account Public Key
Account Private Key
and these deprecated primitives:
Account Family Seed
Account Family Generator
These routines replace existing code to compute SHA512-Half hashes.
The new code accumulates serialized data into a hashing context
instead of allocating a buffer, for improved performance.
Removes the base_uint constructor that took a string. Replaces
that functionality with two free functions named from_hex_text<>.
Use of from_hex_text<> looks like this:
auto v = from_hex_text<uint256>("AAA555");
static_assert (std::is_same<decltype(v), uint256>::value, "Huh!");
from_hex_text<> only operates on base_uint types. At the moment the
list of those types include:
o uint128,
o uint160,
o uint256,
o Directory,
o Account,
o Currency, and
o NodeID.
Using from_hex_text<> with any other types will not compile due to
an enable_if.
* Implement subtraction as addition to the additive inverse
* Do not allow comparison with, addition to or subtraction from integers
* Remove unused functions
* Convert member functions to free functions
* Isolate unit-test specific code into the unit test
This commit provides support for 2-level multi-signing of
transactions. The ability is usually compiled out, since other
aspects of multi-signing are not yet complete.
Here are the missing parts:
o Full support for Tickets in transactions.
o Variable fees based on the number of signers,
o Multiple SignerLists with access control flags on accounts,
o Enable / disable operations based on access control flags,
o Enable / disable all of multi-signing based on an amendment,
o Integration tests, and
o Documentation.
Add support for the SignerListSet transaction as a step toward
multi-sign support.
As part of the SignerListSet implementation, add InnerObjectFormat
templates (similar to TxFormats and LedgerFormats) and enforce them
in STObject, STArray, and STParsedJSON.
* Cleanups and reduction of copying
* Add STArray::back, operator[], push_back(&&)
* Add make_stvar
* Rework STParsedJSON
* Fix code and unit tests that use STParsedJSON
* STTx move constructor
The STAmount class includes a number of functions which serve as thin
wrappers, which are unused or used only in one place, or which break
encapsulation by exposing internal implemenation details. Removing
such functions simplifies the interface of the class and ensures
consistency.
* getSNValue and getNValue are now free functions
* canonicalizeRound is no longer exposed
* Removed addRound and subRound
* Removed overloads of multiply, mulRound, divide and divRound
This introduces the STVar container, capable of holding any STBase-derived
class and implementing a "small string" optimization. STObject is changed
to store std::vector<STVar> instead of boost::ptr_vector<STBase>. This
eliminates a significant number of needless dynamic memory allocations and
deallocations during transaction processing when ledger entries are
deserialized. It comes at the expense of larger overall storage requirements
for STObject.
Recognize a new JSON parameter `key_type` in handlers for wallet_propose
and sign/submit. In addition to letting the caller to specify either of
secp256k1 or ed25519, its presence prohibits the (now-deprecated) use of
heuristically polymorphic parameters for secret data -- the `passphrase`
parameter to wallet_propose will be not be considered as an encoded seed
value (for which `seed` and `seed_hex` should be used), and the `secret`
parameter to sign and submit will be obsoleted entirely by the same trio
above.
* Use constants instead of literals for JSON parameter names.
* Move KeyType to its own unit and add string conversions.
* RippleAddress
* Pass the entire message, rather than a hash, to accountPrivateSign()
and accountPublicVerify().
* Recognize a 33-byte value beginning with 0xED as an Ed25519 key when
signing and verifying (for accounts only).
* Add keyFromSeed() to generate an Ed25519 secret key from a seed.
* Add getSeedFromRPC() to extract the seed from JSON parameters for an
RPC call.
* Add generateKeysFromSeed() to produce a key pair of either type from
a seed.
* Extend Ledger tests to cover both key types.
* Remove unused members
* SerialIter holds only a pointer and offset now
* Use free functions for some Serializer members
* Use SerialIter in some places instead of Serializer
An alternative to the unity build, the classic build compiles each
translation unit individually. This adds more modules to the classic build:
* Remove unity header app.h
* Add missing includes as needed
* Remove obsolete NodeStore backend code
* Add app/, core/, crypto/, json/, net/, overlay/, peerfinder/ to classic build
The SConstruct is modified to provide a new family of targets, ending with
the suffix ".nounity", which compile individual translation units instead of
some of the unity translation units ("classic" builds). Two modules updated
for this treatment are ripple/basics/ and ripple/protocol/, with plans to
update more in the future. A consequence is longer build times in some cases.
A benefit of classic builds is that missing includes can be identified
through compiler errors.
