Problem: a stack trace was being thrown during daemon startup from
BisqDaemonMain.onSetupComplete when it attempted to start a
second BisqGrpcServer and failed to bind to the already-bound port.
The first BisqGrpcServer is started in
BisqDaemonMain.onApplicationStarted much earlier in the startup process.
Solution: remove the second attempt to start the server by removing
BisqDaemonMain's implementation of onSetupComplete, and in turn remove
the now-obsolete bisqGrpcServer field as well.
This change also eliminates the BisqGrpcServer.blockUntilShutdown
method, which in turn called the underlying grpc server's
awaitTermination method. As the comment there explained, this was
thought to be necessary because grpc "does not use daemon threads by
default", but this is actually incorrect. According to the grpc Javadoc
at [1], "Grpc uses non-daemon Threads by default and thus a Server will
continue to run even after the main thread has terminated."
[1]: https://git.io/JePjn
The :grpc module will soon be renamed to :daemon. These two modules
represent two separate and equal modes of running bisq, either as a
desktop GUI or as a daemon. They are both applications, and one should
not depend on the other as it would be illogical and confusing to model
things that way. The reason for the current dependency from :desktop to
:grpc is because :grpc is the home of BisqGrpcServer. This change moves
this class up to :core, in a new bisq.core.grpc package, such that both
the :desktop and :daemon applications can pull it in cleanly.
The CoreApi 'facade' that BisqGrpcServer uses to abstract away bisq
internals has been moved from bisq.core to bisq.core.grpc as well and
for the same reasons detailed in 8b30c22d6.
This change also renames the Java package for generated grpc types from
bisq.grpc.protobuf to bisq.core.grpc (the same new package that
BisqGrpcServer and CoreApi now live in). Again, this is for reasons of
cohesion: BisqGrpcServer is the only user of these grpc-generated types,
and they should logically live in the same package (even if they
physically live in separate source dirs at the build level).
There are two structural / organizational reasons for this move:
1. References from one package to another should always be upward or
lateral, never downward, as the latter causes package cycles (aka
'tangles') which damage the suppleness and understandability of a large
codebase. Prior to this change the high-level bisq.core.CoreModule
class imported many classes from child packages like
bisq.core.{btc,dao,user,util}, etc. By moving CoreModule down into the
'.app' package, it can reference all these other packages as siblings
instead of doing so as a parent.
2. the bisq.core.desktop and bisq.core.app packages are the only
locations that reference the CoreModule class. By moving the class
into bisq.core.app, greater cohesion is acheived, again making the
codebase that much easier to read and understand.
The previous commit introduces the BisqGrpcServer as a proof of concept,
but it is not yet ready for production use. This commit removes the
`--desktopWithGrpcApi` option that starts the gRPC server until such
time that it is production-ready.
This change also removes the `--desktopWithHttpApi` option for starting
an HTTP API server. The option has been in place for some time, but it
was 'false advertising' in the sense that nothing actually happened if
the user specified it, because there is in fact no HTTP API
implementation to be started.
Note that when the gRPC API option is reintroduced, it will be renamed
to `--rpcserver` or similar, following the convention in Bitcoin Core.
This commit introduces a new `grpc` module including the following key
types:
- BisqGrpcServer: The API implementation itself, along with generated
gRPC Response/Reploy types defined in grpc/src/main/proto/grpc.proto.
- BisqGrpcServerMain: A 'headless' / daemon-like entry point for
running a Bisq node without the JavaFX desktop UI.
- BisqGrpcClient: A simple, repl-style client for the API that allows
the user to exercise the various endpoints as seen in the example
below.
In the `desktop` module, the BisqAppMain class has been modified to
start a BisqGrpcServer instance if the `--desktopWithGrpcApi` option has
been set to `true`.
In the `core` module, a new `CoreApi` class has been introduced
providing a kind of comprehensive facade for all Bisq functionality to
be exposed via the RPC API.
How to explore the proof of concept:
1. Run the main() method in BisqAppMain providing
`--desktopWithGrpcApi=true` as a program argument or alternatively, run
the main() method in BisqGrpcServerMain, where no special option is
required. In either case, you'll notice the following entry in the log
output:
INFO bisq.grpc.BisqGrpcServer: Server started, listening on 8888
2. Now run the main() method in BisqGrpcClient. Once it has started up
you are connected to the gRPC server started in step 1 above. To
exercise the API, type `getVersion` via stdin and hit return. You
should see the following response:
INFO bisq.grpc.BisqGrpcClient - 1.2.4
Likewise, you can type `getBalance` and you'll see the following
response:
INFO bisq.grpc.BisqGrpcClient - 0.00 BTC
and so forth for each of the implemented endpoints. For a list of
implemented endpoints, see BisqGrpcServer.start().
Note once again that the code here is merely a proof of concept and
should not be considered complete or production-ready in any way. In a
subsequent commit, the `--desktopWithGrpcApi` option will be disabled in
order to avoid any potential production use.
The content of this commit is the result of squashing a number of
commits originally authored by chimp1984 in the `chimp1984` fork's `grpc`
branch.
Co-authored-by: Chris Beams <chris@beams.io>
After further testing, I realized I introduced a bug in commit
4f4b0f6ce9 because apparently the
ArrayList.contains() method does not properly work for
BlockChainExplorer object - to fix this I implemented a new
contains() method that uses string comparison instead
* Upgrade mempool.space to full block explorer functionality
* Add mempool.space Tor V2 block explorer
* If no valid Bitcoin block explorer is set, use the 1st block explorer
According to issue #3641, the label "Bankgiro number", as it was
hardcoded in BankUtil.java, should not be used in Sweden.
The label "Kontonummer" is the correct one to be used in Sweden and
Norway.
Account number validation is implemented to Norwegian accounts in
AccountNrValidator.java.
There is no validation implemented to Swedish accounts, so nothing
to change there.
If account validation for Sweden is needed, a different method would
be needed.
Fixes#3641
* Add 2 new columns to vote result
Add threshold and quorum column.
Combine name and link column.
Add sorting function for accepted column.
Adjust column width.
* Fix sorting functions
* Improve column sorting
We got a report where a "tx already known" message caused a failed
trade but the deposit tx was valid.
To avoid such false positives we only handle reject messages which
we consider clearly critical.
Use a LinkedHashMap in place of a List, for the caching CurrencyUtil
fields 'allSortedFiatCurrencies' & 'allSortedCryptoCurrencies', using
the same iteration order as before. In this way, we can avoid a linear
search in the lookup methods getFiatCurrency & getCryptoCurrency.
In particular, this speeds up the activation of TradesChartsView (and to
a lesser extent OfferBookChartView), which make a lot of calls to
CurrencyUtil.getTradeCurrency in the fillTradeCurrencies/updateChartData
methods respectively.
At mediation we require a min. payout to the losing party to keep
incentive for the trader to accept the mediated payout. For Refund
agent cases we do not have that restriction.
According to https://github.com/bisq-network/proposals/issues/155
For buyer:
Default: 15%
Min. 15% for Altcoin, 15% for Fiat
Max. 50% for Altcoin, 50% for Fiat
Absolute min. deposit in BTC: 0.006 BTC (currently 40 USD)
For Seller:
Fixed: 15%
Absolute min. deposit in BTC: 0.006 BTC (currently 40 USD)
These are mostly injected objects that are now redundant, such as some
CoinFormatter and Preferences fields.
Also do some additional minor tidying of TradesChartsViewModel.
