Cryptoconditions provide a mechanism to describe a signed message such
that multiple actors in a distributed system can all verify the same
signed message and agree on whether it matches the description. This
provides a useful primitive for event-based systems that are distributed
on the Internet since we can describe events in a standard deterministic
manner (represented by signed messages) and therefore define generic
authenticated event handlers.
The cryptoconditions specification implemented is available at:
https://tools.ietf.org/html/draft-thomas-crypto-conditions-01
* 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
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.
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.
port of js test, account_objects-test.js
- bob account setup and rpc invoke
- error tests; no account, non-existant account, bad seed, validation
- combined unstepped testcase then stepped with limit/marker
Details
-------
* covers existing account_offers-test.js
* adds new coverage for results limiting and some
negative tests (bad input)
* fix bug in json value copying logic for bad seed/account error
case
* using new BEAST_EXPECT macros
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.
