Use ReimbursementConsensus.get[Min|Max]ReimbursementRequestAmount in
place of CompensationConsensus.get[Min|Max]CompensationRequestAmount,
which was erroneously copied (it appears) from the very similar
CompensationValidator class.
This ensures the correct upper bound (currently 80,000 BSQ, starting at
10,000 BSQ and doubled in cycles 12, 13 & 14) is placed on reimbursement
requests, instead of the erroneous 100,000 BSQ upper bound for
compensation requests.
This is a feature that will not be included in api v1, but partial
support is added in this change to the server. CLI will pass a
default triggerPrice of 0 (unused) with the createoffer command.
When fully implemented, an optional trigger-price param will be
added to the CLI's createoffer method, and the value will only be
visible to offer owners. New enableoffer and disableoffer
methods will also need to be added.
The confirmation details include amount, recipient address and txId.
Includes a link to open txId details in the user's external block explorer.
@m52go reworded the BSQ conf explanation note.
Added "don't show again" checkbox.
- Injected OfferFilter into CoreOffersService and CoreTradesService.
The filter constrains 'getoffer(s)' results to offers an api user
can take, as the first part of ongoing protection tools / api
integration.
- Created a new CoreContext singleton.
Initially, lets Core*Services know if the user is using the api --
isApiUser=true if the current thread's name is "BisqDaemonMain" or
the name contains "grpc". We do this anticipating future :desktop
dependencies on the core api, and we don't pass hardcoded
isApiUser=true params to lower level domain objects.
We cannot check BisqDaemonMain.class.getSimpleName() because :core
cannot have a circular dependency on :daemon, but there is probably a
better way to do this than depending on the thread name set in
BisqDaemonMain#configUserThread().
- Added @Singleton annotation to all Core*Service classes.
- Fix bug locating index of method name in String[] args.
- Make createoffer method's security-deposit param format consistent with UI's.
When creating an offer, the CLI should take "15.0", not "0.15" as
a 15% security deposit. This is consistent with the UI, and the
CLI's mkt-price-margin input format.
