AccountSet set/clear, asfDefaultRipple = 8
AccountRoot flag, lsfDefaultRipple = 0x00800000
In trustCreate, set no ripple flag if appropriate.
If an account does not have the default ripple flag set,
new ripple lines created as a result of its offers being
taken or people creating trust lines to it have no ripple
set by that account's side automatically
Trust lines can be deleted if the no ripple flag matches
its default setting based on the account's default ripple
setting.
Fix default no-rippling in integration tests.
Changes made to support autobridging and improve the offer-crossing and
pathfinding logic result in transaction-breaking changes which cause
incompatibilities between 0.27 and 0.28 builds of RippleD.
This patch simplifies deployment of 0.28 on the Ripple network by allowing
RippleD to emulate the 0.27 semantics while the last closed ledger closed
before March 30, 2015 at 13:00:00 PDT, after which time the new 0.28
semantics will become active.
The transaction-breaking changes addressed in this commit are:
3ccbd7c9b2b203db27a4
This adds a limit of 1,000 passes to the payment engine. It protects against
possible cases where the execution of a pass fails to exhaust the liquidity
that made the pass possible or cases where two passes alternate providing
liquidity for each other.
* Compute the effective recipient.
* Make sure the effective recipient exists.
* Prohibit paths to the recipient, if not the effective recipient.
* Treat paths to the effective recipient as complete.
* Don't find looped paths.
* Use the effective recipient for getPathsOut weight.
* When starting up, we no longer rely just on the standard
system RNG to generate entropy: we attempt to squeeze some
from the execution state, and to recover any entropy that
we had previously stored.
* When shutting down, if sufficient entropy has been accumulated
attempt to store it for future use.
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.
Instead of tracking recently-requested entries from inbound
ledgers by node ID, track by hash. This allows state and
transaction entries to be tracked in the same set.
LedgerMaster::getLedgerBySeq should return a validated
ledger (rather than the the open or closed ledger) for
a sequence number for which it has a fully-validated ledger.
When fetchNodeFromDB discovers a missing node in the database it
must reset the ledger sequence to 0. By treating this as a logically
const operation, even though not physically const, many other member
functions can be made const, including compare.
Inbound and outbound peer connections always use HTTP handshakes to
negotiate connections, instead of the deprecated TMHello protocol
message.
rippled versions 0.27.0 and later support both optional HTTP handshakes
and legacy TMHello messages, so always using HTTP handshakes should not
cause disruption. However, versions before 0.27.0 will no longer be
able to participate in the overlay network - support for handshaking
via the TMHello message is removed.
