This combines two enhancements to the ledger_data RPC
command and related commands.
The ledger_data RPC command will now return the ledger header
in the first query (the one with no marker specified).
Also, ledger_data and related commands will now provide the
ledger header in binary if binary output is specified.
Modified existing ledgerdata unit test to cover new functionality.
When started with "--start", put all known, non-vetoed
amendments in the genesis ledger. This avoids the need
to wait 256 ledgers before amendments are enabled when
testing with a fresh ledger.
This will allow code that looks at the ledger header to know what version the
SHAMap uses. This is helpful for code that rebuilds ledger binary structures
from the leaves.
Add an amendment to allow gateways to set a "tick size"
for assets they issue. There are no changes unless the
amendment is enabled (since the tick size option cannot
be set).
With the amendment enabled:
AccountSet transactions may set a "TickSize" parameter.
Legal values are 0 and 3-15 inclusive. Zero removes the
setting. 3-15 allow that many decimal digits of precision
in the pricing of offers for assets issued by this account.
For asset pairs with XRP, the tick size imposed, if any,
is the tick size of the issuer of the non-XRP asset. For
asset pairs without XRP, the tick size imposed, if any,
is the smaller of the two issuer's configured tick sizes.
The tick size is imposed by rounding the offer quality
down to nearest tick and recomputing the non-critical
side of the offer. For a buy, the amount offered is
rounded down. For a sell, the amount charged is rounded up.
Gateways must enable a TickSize on their account for this
feature to benefit them.
The primary expected benefit is the elimination of bots
fighting over the tip of the order book. This means:
- Quicker price discovery as outpricing someone by a
microscopic amount is made impossible. Currently
bots can spend hours outbidding each other with no
significant price movement.
- A reduction in offer creation and cancellation spam.
- More offers left on the books as priority means
something when you can't outbid by a microscopic amount.
* 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
A conditional suspended payment is a suspended payment where
completion of the payment is contingent upon the fulfillment
of a condition defined by the sender during creation of the
suspended payment.
This commit also introduces the "CryptoConditions" amendment
which controls whether cryptoconditions will be supported
in suspended payments. The existing "SusPay" amendment can
be used to enable suspended payments without enabling the
cryptoconditions code.
* Remove extraneous passing of transaction set hashes
* Remove recentPositions_. InboundTXs does the job now
* Move responsibility for sending "have TX set" out of consensus
If the mantissas of two non-native amounts differ by less than 10, then
subtracting them leaves a result of zero. This can cause situations
where `a>b`, yet `a-b == 0`.
One consequence of this is unfunded offers were incorrectly left in
order books. The code would check if the offer would be
consumed (`amount in offer > amount needed`), assume it wouldn't be,
yet when `amount needed` was subtracted from `amount in offer` the
result was zero and the offer was unfunded. This unfunded offer
incorrectly remained on the order book.
This patch fixes this bug.
The XRPEndpointStep bypassed the logic in deferred credits and
incorrectly counted funds acquired during a payment as available for
use in the payment. It also incorrectly used the current ownerCount when
calculating the reserve instead of the owner count as it was at the
beginning of the payment (reducing the owner count is analogous to
acquiring funds during a payment.)
All cases that still used the old RPF code now use new-style pathfinding.
This includes unit tests, RPF requests with a ledger specified, and RPF
requests in standalone mode.
Create SetRegularKey test to replace existing js test. Copy and simplify
some existing test logic from Env_test.cpp and MultiSign.test.cpp. Add
coverage for tfUniversalMask tx flag error case.
Replace the sparsely used strCopy function with Slice. Change some of
the SHAMap interface to use Slice instead of Blob, which should
eliminate a copy.
* If an account has any transactions in the transaction queue, submitting
a transaction that covers the differences to the open ledger fee level
for prior queued transactions plus itself will cause all those
transactions to be applied to the open ledger.
* tel failures in `TxQ::accept` will leave tx in the queue to retry later.
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.
* Updates both server_info and server_state
* Adds "load_factor_server", which reports the server-only portion of the
load (if appropriate) so clients can decide an appropriate fee to pay if
the open ledger fee is higher than they're willing to pay.
=== Release Notes ===
==== Updated Features ====
Both `server_info` and `server_state` report the escalated ledger fee in
the `load_factor` result parameter. If appropriate, `load_factor_server`
reports the server-only portion of the load so clients can submit a fee
between those two values to get into the queue.
* 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.
* Standardize names of LedgerConsensusImp members
* Rework visitStoredProposals
* Clean up mapComplete
* Move status helpers out of LedgerConsensusImp
* Move applyTransaction out of LedgerConsensusUmp
* Clean up applyTransactions
cmake support in rippled. Currently supports:
* unity/nounity debug/release
* running protobuf
* sanitizer builds
* optional release build with assert turned on
* `target` variable to easily set compiler/debug/unity
(i.e. -Dtarget=gcc.debug.nounity)
* gcc/clang/visual studio/xcode
* linux/mac/win
* gcc 4 ABI, when needed
* ninja builds
* check openssl for acceptably recent release
* static builds
TBD:
* jemalloc support
* count
Notes:
* Use the -G"Visual Studio 14 2015 Win64" generator on Windows. Without
this a 32-bit project will be created. There is no way to set the
generator or force a 64-bit build in CMakeLists.txt (setting
CMAKE_GENERATOR_PLATFORM won't work). The best solution may be to
wrap cmake with a script.
* It is not possible to generate a visual studio project on linux or
mac. The visual studio generator is only available on windows.
* The visual studio project can be _either_ unity or
non-unity (selected at generation time). It does not appear possible
to disable compilation based on configuration.
* Language is _much_ worse than python, poor documentation and "quirky"
language support (for example, generator expressions can only be used
in limited contexts and seem to work differently based on
context (set_property can set multiple values, add_compile_options
can not/or is buggy)
* Could not call out to `sed` because cmake messed with the regular
expression before calling the external command. I did not see a way
around this.
* Makefile generators want to be single target. It wants a separate
directory for each target type. I saw some mentions on the web for
ways around this bug haven't look into it. The visual studio project
does support debug/release configurations in the same project (but
not unity/non-unity).
Log thread name and exception type on unhandled exceptions and use a
terminate handler to get a stack trace that includes the function that
thows the exception.
The Ripple protocol represent transfer rates and trust line
qualities as fractions of one billion. For example, a transfer
rate of 1% is represented as 1010000000.
Previously, such rates where represented either as std::uint32_t
or std::uint64_t. Other, nominally related types, also used an
integral representation and could be unintentionally substituted.
The new Rate class addresses this by providing a simple, type
safe alternative which also helps make the code self-documenting
since arithmetic operations now can be clearly understood to
involve the scaling of an amount by a rate.
