* Each peer has a "sane/insane/unknown" status
* Status updated based on peer ledger sequence
* Status reported in peer json
* Only sane peers preferred for historical ledgers
* Overlay endpoints only accepted from known sane peers
* Untrusted proposals not relayed from insane peers
* Untrusted validations not relayed from insane peers
* Transactions from insane peers are not processed
* Periodically drop outbound connections to bad peers
* Bad peers get bootcache valence of zero
Peer "sanity" is based on the ledger sequence number they are on. We
quickly become able to assess this based on current trusted validations.
We quarrantine rogue messages and disconnect bad outbound connections to
help maintain the configured number of good outbound connections.
In some corner cases, an incorrect resume marker could be
returned, preventing the complete enumeration of account
transactions.
* Robust markers via improved paging support
* New unit tests
* Cleanup
The analysis of differences between locally built ledgers and consensus
ledgers is now more intelligent. Differences in these values will be
categorized:
- Operation results
- Transaction ordering
- Generated metadata
* Support PreviousTxnID until the switchover
* Implement "No Ripple" for issue_iou and redeem_iou.
* Do not utilize issue_iou and redeem_iou from legacy code
* Rename 0.27.x legacy files to account for VS build process
* Misc. cleanups
* Set transaction valid in hash router correctly
* Properly account for root nodes in walkLedger
* If loaded ledger is insane, log details
* Extra logging while loading replay ledger
* Don't test unsigned transactions expecting them to succeed
* Don't be too noisy about signature failures
In some code paths, we bump the SHAMap sequence number
before we unshare. This forces SHAMapTreeNode to be
copied. By making the ledger immutable we cause the
unsharing to occur earlier, eliminating the copies.
This creates a new InboundTransactions object that handles transaction sets,
removing this responsibility from the consensus object. The main benefit is
that many inbound transaction operations no longer require the master lock.
Improve logic to decide which peers to query, when to add more peers, and
when to re-query existing peers.
Certain checks that determine if a transaction is malformed can be performed
without needing to look up accounts or access the ledger.
Perform those checks as early as possible to optimize transaction processing.
* Performance motivated.
* Several of these called size() which is O(N) in gcc-4.8.
* Remove container copy from LedgerConsensusImp::playbackProposals().
* Addresses RIPD-284.
* Don't acquire the master lock where it's not needed
* InfoSub tracks RT and validated accounts separately
* Correctly remove accounts from the InfoSub
* Brings the soci subtree into rippled.
* Validator, peerfinder, and SHAMapStore use new soci backend.
* Optional postgresql backend for soci (if POSTGRESQL_ROOT env var is set).
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.
