-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Proposed 0.90.0-b3 #2328
Conversation
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.
Jenkins Build SummaryBuilt from this commit Built at 20180112 - 22:58:27 Test Results
|
@nbougalis Please include #2294 once @ximinez gives approval. The original version of this PR is already in this PR as fbfb4bd Then again, as it stands it has the essential fixes. The things in PR 2294 can be deferred until the next push to develop. |
Includes the following PRs: #2192, #2239, #2256, #2286, #2289, #2290, #2291, #2292, #2293, #2294, #2305, #2307, #2312 and #2319.