Avoid custom overflow code; simply use 128-bit math to
maintain precision and return a saturated 64-bit value
as the final result.
Disallow use of negative values in the `fee_mult_max`
and `fee_div_max` fields. This change could potentially
cause submissions with negative values that would have
previously succeeded to now fail.
The existing configuration includes 512 and 1024 bit DH
parameters and supports ciphers such as RC4 and 3DES and
hash algorithms like SHA-1 which are no longer considered
secure.
Going forward, use only 2048-bit DH parameters and define
a new default set of modern ciphers to use:
HIGH:!aNULL:!MD5:!DSS:!SHA1:!3DES:!RC4:!EXPORT:!DSS
Additionally, allow administrators who wish to have different
settings to configure custom global and per-port ciphers suites
in the configuration file using the `ssl_ciphers` directive.
* Force jtx to request/receive the 2.0 API
* Force the JSON and WebSocket tests to use 2.0 API
* This specifically allows the Websocket to create 2.0 json/ripple
and get back a 2.0 response.
* Add test for malformed json2
* Add check for parse failure
* Add check for params to be in array form.
* Correct type-o discovered in tests due to stricter checking.
* Add API version to the WSClient & JSONRPCClient test
* Update source.dox with more headers
* Make HTTP(S) requests on websocket ports reply with Status page
* Fix isWebsocketUpgrade to compare case insensitive
* Make websocket upgrades with no websocket protocols configured report error
* Create unit test for unauthorized requests and the status page
Payment channels permit off-ledger checkpoints of XRP payments flowing
in a single direction. A channel sequesters the owner's XRP in its own
ledger entry. The owner can authorize the recipient to claim up to a
give balance by giving the receiver a signed message (off-ledger). The
recipient can use this signed message to claim any unpaid balance while
the channel remains open. The owner can top off the line as needed. If
the channel has not paid out all its funds, the owner must wait out a
delay to close the channel to give the recipient a chance to supply any
claims. The recipient can close the channel at any time. Any transaction
that touches the channel after the expiration time will close the
channel. The total amount paid increases monotonically as newer claims
are issued. When the channel is closed any remaining balance is returned
to the owner. Channels are intended to permit intermittent off-ledger
settlement of ILP trust lines as balances get substantial. For
bidirectional channels, a payment channel can be used in each direction.
* Account-related queue stats (RIPD-1205). Boolean "queue" parameter to
account_info only if requesting the open ledger.
* Account for the TxQ when autofilling sequence in sign-and-submit (RIPD-1206)
* Tweak TxQ::accept edge case when choosing which tx to try next.
* Labels for experimental "x_" submit parameters use correct separator.
=== Release Notes ===
==== New features ====
When requesting `account_info` for the open ledger, include the `queue :
true` to get extra information about any queued transactions for this
account. (RIPD-1205).
==== Bug fixes ====
When using sign-and-submit mode to autofill a transaction's sequence
number, the logic will not reuse a sequence number that is in the queue
for this account. (RIPD-1206).
Labels for experimental "x_queue_okay" and "x_assume_tx" parameters to
`sign` and `submit` updated to use correct separator.
* Minimum factor 256*500, don't multiply by base fee
* Change autofill fee behavior to pay the open ledger fee.
** Experimental options: x-assume-tx - assume <int> more transactions in
the open queue when computing escalated fee, x-queue-okay - if true
and escalated fee is over limit, try with load fee.
* Port of 75af4ed.
Passing in objects, arrays or non-string objects previously generated
nondescript errors. Improve the error messages returned to clients.
Add unit tests to ensure that incorrect inputs are reliably detected
and generate descriptive and accurate errors.
There was a bug in version 0.30.1 where signing with an ed25519
key and a corrupt seed would cause the "sign" and "sign_for"
commands to return an unexpected error. That bug was fixed in
the 0.31.0 release.
These unit tests verify the fix. The error message for a corrupt
seed is also slightly improved.
Replace Journal public data members with member function accessors
in order to make Journal lighter weight. The change makes a
Journal cheaper to pass by value.
Also add missing stream checks (e.g., calls to JLOG) to avoid
text processing that ultimately will not be stored in the log.
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.
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.
The existing delivered_amount logic will erroneously report
unavailable for ledgers that aren't in the network's live
chain because it is based solely on ledger sequence number.
This adds a check based on the ledger close time to permit
the code to give correct results in standalone mode and on
test networks.
* 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.
o The sign_for RPC command automatically fills in an empty
"SigningPubKey" field if the field is missing.
o The sign_for command returns the Signers list inside the
tx_json. This re-establishes symmetry with the
submit_multisigned command. It also means the returned
tx_blob might be useful, since it contains the multisignature.
o The sign_for command also now allows the inclusion of a Signers
array field in the input tx_json. If a Signers array is present,
the new signature is incorporated into the passed array. This
supports a model where multisignatures are accumulated serially.
o Syntax hints are improved.
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.
