Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed 0.90.0-b3 #2328

Merged
merged 22 commits into from
Jan 16, 2018
Merged

Proposed 0.90.0-b3 #2328

merged 22 commits into from
Jan 16, 2018

Conversation

nbougalis
Copy link
Contributor

Includes the following PRs: #2192, #2239, #2256, #2286, #2289, #2290, #2291, #2292, #2293, #2294, #2305, #2307, #2312 and #2319.

mtrippled and others added 20 commits December 14, 2017 16:04
Do not dispatch a transaction received from a peer for
processing, if it has already been dispatched within the
past ten seconds.

Increase the number of transaction handlers that can be in
flight in the job queue and decrease the relative cost for
peers to share transaction and ledger data.

Additionally, make better use of resources by adjusting the
number of threads we initialize, by reverting commit
68b8ffd.
Profiling and research indicates that the SQLite query planner executed
our existing SQL queries sub-optimally by not using the index efficiently.

Restructuring the SQL query works around this issue and allows queries
to be executed efficiently and without unnecessary delay.
In connection with Ripple's decentralization strategy, the example
validators.txt file is being updated, and the [validators] field,
which contained a static list of trusted validators, is being
replaced with two new fields:

- The [validator_list_keys] field which contains the keys that can be
  used to sign its recommended validator list.
- The [validator_list_sites] field which specifies the URLs where
  dynamic validator list can be found.

The initial configuration links to Ripple's default validator list,
which is located at https://vl.ripple.com.

To read more about Ripple's decentralization strategy, please visit
the Ripple Dev Blog:

https://ripple.com/dev-blog/decentralization-strategy-update/
* Null json values can be objects or arrays.
* json arrays are now interpreted as batch commands.
* json objects are single commands.
* null jsons are ambiguous as to whether they are single or batch
  commands and should be avoided.
The quorum is now calculated automatically and does not need to be
manually specified.
* Check message queue before shutting down unit tests
* Logging should be on if not quiet
The DepositAuth feature allows an account to require that
it signs for any funds that are deposited to the account.
For the time being this limits the account to accepting
only XRP, although there are plans to allow IOU payments
in the future.

The lsfDepositAuth protections are not extended to offers.
If an account creates an offer it is in effect saying, “I
will accept funds from anyone who takes this offer.”
Therefore, the typical user of the lsfDepositAuth flag
will choose never to create any offers.  But they can if
they so choose.

The DepositAuth feature leaves a small gap in its
protections.  An XRP payment is allowed to a destination
account with the lsfDepositAuth flag set if:

- The Destination XRP balance is less than or equal to
  the base reserve and

- The value of the XRP Payment is less than or equal to
  the base reserve.

This exception is intended to make it impossible for an
account to wedge itself by spending all of its XRP on fees
and leave itself unable to pay the fee to get more XRP.

This commit

- adds featureDepositAuth,

- adds the lsfDepositAuth flag,

- adds support for lsfDepositAuth in SetAccount.cpp

- adds support in Payment.cpp for rejecting payments that
  don't meet the lsfDepositAuth requirements,

- adds unit tests for Payment transactions to an an account
  with lsfDepositAuth set.

- adds Escrow and PayChan support for lsfDepositAuth along
  with as unit tests.
* Use the Visual Studio 2017 image
* Update to rippled_deps17.01
In some cases this script did not detect properly that the subprocess is already terminated. The "append" loop afterwards caused memory to fill up and the script to fail eventually.
@ripplelabs-jenkins
Copy link
Collaborator

ripplelabs-jenkins commented Jan 10, 2018

Jenkins Build Summary

Built from this commit

Built at 20180112 - 22:58:27

Test Results

Build Type Result Status
coverage 975 cases, 0 failed, t: 611s PASS ✅
clang.debug.unity 975 cases, 0 failed, t: 386s PASS ✅
clang.debug.nounity 973 cases, 0 failed, t: 424s PASS ✅
gcc.debug.unity 975 cases, 0 failed, t: 432s PASS ✅
gcc.debug.nounity 973 cases, 0 failed, t: 441s PASS ✅
clang.release.unity 974 cases, 0 failed, t: 470s PASS ✅
gcc.release.unity 974 cases, 0 failed, t: 503s PASS ✅

@mtrippled
Copy link
Collaborator

mtrippled commented Jan 13, 2018

@nbougalis Please include #2294 once @ximinez gives approval. The original version of this PR is already in this PR as fbfb4bd
However, since then unit tests for the peer traffic limits have been put in, as well as performance counters for transaction queue overflows and peer disconnects.

Then again, as it stands it has the essential fixes. The things in PR 2294 can be deferred until the next push to develop.

@nbougalis nbougalis merged commit 49b5c42 into XRPLF:develop Jan 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants