This change adds a new 'verifyWalletsAreAvailable' method to the client,
which eliminates this duplicated statement:
throw new IllegalStateException("wallet is not yet available");
The commit is in response to a requested change in PR 4312:
https://github.com/bisq-network/bisq/pull/4312#pullrequestreview-435659314
This commit is for a change requested in PR 4308:
https://github.com/bisq-network/bisq/pull/4308#pullrequestreview-435055483
".toUpperCase() seems misplaced here. It would soon get repetive.
Whether the underlying logic differentiates between capitalizations
is a low-level implementation detail and would do better at the
lowest practical level."
The new method returns current buy or sell offers for a fiat ccy.
These changes need refactoring and polishing before merging, but they're
committed in this state to be safe (don't lose work). Changes include:
* New core.grpc classes
CoreOffersService
GrpcOffersService
model.OfferInfo
* CoreApi -- The new CoreOffersService is injected into CoreApi and
the old getOffers() and placeOffer() impls were moved into the
new CoreOffersService. The getOffers implementation was re-done.
Other changes are just rearranging location of core method calls.
* GrpcServer -- The new GrpcOffersService replaced the old
GetOffersService and PlaceOfferService.
* grpc.proto -- The old GetOffers and PlaceOffer services were combined
into a single Offers service, and the PlaceOffer rpc was renamed
as CreateOffer. These are the only substantive changes; the rest
is just rearranging location of the service defs in the file.
Also created a lighterweight OfferInfo proto message wrapper to
be passed between server & client (client has no access to core's
Offer and OfferPayload).
* OfferInfo -- A new wrapper around the OfferInfo proto message.
* CliMain -- The new GetOffers service stub was added.
Some (maybe too much) number and ccy formatting logic was
copied & modified from core. Some tedius string formatting
was added too (needs to be tidied up).
* License comments were also copied to several classes, and I
made a mistake in reverting changes to the wrong file.
TODO add unit tests
Remove the recently added gRPC StatusRuntimeException wrapping
logic because we want unexpected Exceptions to bubble up for now,
until CorePaymentAccountsService.java throws specific
IllegalStateExceptions with user friendly error messages.
(See CoreWalletsService.java for example.)
This reverts commit bfcc693f69.
This change was reverted because we want unexpected Exceptions
to bubble up for now, until CorePaymentAccountsService.java
throws specific IllegalStateExceptions with user friendly
error messages. (See CoreWalletsService.java for example.)
The 'getaddressbalance' and 'getfundingaddresses' methods now send
new AddressBalanceInfo proto messages instead of a formatted String
to the client. The AddressBalanceInfo message contains addressString,
balance, and # of confirmations (transaction confidence) fields.
Changes include:
* A new AddressBalanceInfo proto message
* A wrapper class for the new AddressBalanceInfo proto
* New 'getaddressbalance' and 'getfundingaddresses' signatures in server
* AddressBalanceInfo display logic in client
* Removal of balance formatting logic in server
* Refactoring of balance formatting logic in client
This change is a refactoring of the gRPC Wallets service
for the purpose of making CoreApi the entry point to
all core implementations. These changes should have been
made in PR 4295.
See https://github.com/bisq-network/bisq/pull/4295
The gRPC Wallet proto def name was changed to Wallets because
this service manages BSQ and BTC wallets, and GrpcWalletService
was changed to GrpcWalletsService for the same reason.
This PR should be reviewed/merged after PR 4308.
See https://github.com/bisq-network/bisq/pull/4308
This PR's branch was created from the PR 4308 branch.
This addresses task 4 in issue 4257.
https://github.com/bisq-network/bisq/issues/4257
This PR should be reviewed/merged after PR 4304.
https://github.com/bisq-network/bisq/pull/4304
This new gRPC PaymentAccounts service method creates a dummy
PerfectMoney payment account for the given name, number and fiat
currency code, as part of the required "simplest possible trading
API" (for demo). An implementation supporting all payment
methods is not in the scope.
Changes specific to the new rpc method implementation follow:
* New createpaymentacct method + help text was added to CliMain.
Help text formatting was also changed to make room for larger
method names and argument lists.
* The PaymentAccount proto service def was renamed PaymentAccounts
to avoid a name collision, and the new rpc CreatePaymentAccount
was made part of the newly named PaymentAccounts service def.
* New GrpcPaymentAccountsService (gRPC boilerplate) and
CorePaymentAccountsService (method implementations) classes were
added.
* The gRPC GetPaymentAccountsService stub was moved from GrpcServer
to the new GrpcPaymentAccountsService class, and
GrpcPaymentAccountsService is injected into GrpcServer.
* A new createpaymentacct unit test was added to the bats test
suite (checks for successful return status code).
Maybe bit out of scope, some small changes were made towards making
sure the entire API is defined in CoreApi, which is used as a
pass-through object to the new CorePaymentAccountsService. In the
next PR, similar refactoring will be done to make CoreApi the
pass-through object for all of the existing CoreWalletsService
methods. (CoreWalletsService will be injected into CoreApi.)
In the future, all Grpc*Service implementations will call core
services through CoreApi, for the sake of consistency.
This addresses task 2 in issue 4257
https://github.com/bisq-network/bisq/issues/4257
This new gRPC Wallet service method displays the balance and number
of confimirmations of the most recent transaction for the given BTC
wallet address.
The new method required the usual boilerplate changes to grpc.proto,
CliMain, and GrpcWalletService.
Two unit tests to check error msgs was added to cli/test.sh.
This addresses task #1 in issue https://github.com/bisq-network/bisq/issues/4257.
This new gRPC WalletService method displays the BTC wallet's list of
receiving addresses. The balance and number of confirmations
for the most recent transaction is displayed to the right of each
address. Instead of returning a gRPC data structure to the client,
the service method returns a formatted String.
If the BTC wallet has no unused addresses, one will be created and
included in the returned list, and it can be used to fund the wallet.
The new method required injection of the BtcWalletService into CoreWalletsService,
and the usual boilerplate changes to grpc.proto, CliMain, and GrpcWalletService.
Some of the next PRs (for #4257) will require some common functionality within
CoreWalletsService, so these additional changes were included:
* a private, class level formatSatoshis function
* a public getNumConfirmationsForMostRecentTransaction method
* a public getAddressBalance method
* a private getAddressEntry method
A unit test that verifies a successful return status was added to cli/test.sh.
- "Memo" field is modeled as property of the new object Transaction which is stored in persitant storage.
- Transaction object is modeled in a way that allows extension in the furure for more persisted attributes.
The routine `cleanUpAddressEntries` in TradeManager was prematurely
releasing funds associated with trades when they reach the last
step of the process (Step 4, Withdraw to External Wallet).
Usually, with a single trade active this would not be an issue
because `cleanUpAddressEntries` is called after the withdrawal,
but if you have more than one trade at Step 4 then the first
withdrawal would go though, but all the others would fail with
an error box "Missing x.xxx BTC" (the trade proceeds or deposit
amount). Alternatively, if you restart the bisq app with a
trade in Step 4, the same cleanup will occur and the attempt
to withdraw to external wallet will fail.
The change here considers any trade held by the TradeManager to
be in use and therefore will not have their associated address
entries freed up. After Step 4 has passed, the trade is no
longer held by the TradeManager, and so cleanUpAddressEntries
will at that point free up the address.
The CoreWalletService should never be running more than one wallet lock
TimerTask at any given time, and the wallet should lock at the correct time
after a user overrides a prior timeout value.
The CoreWalletService now cancels any existing lock TimerTask thread
before creating a new one, to prevent the wallet from re-locking at
unexpected times.
This change prevents error conditions created in scenarios similar to
the following:
(1) User unlocks wallet for 60s
(2) User overrides unlock timeout by calling unlockwallet "pwd" 600s
(3) After 60s, the 1st, uncanceled lock timeout expires, and wallet is
locked 4 minutes too soon.
When exporting trade history to CSV, users would expect to see
their own transaction and trade fees listed. Maker fees are
stored on the Offer, Taker fees are stored on the Trade object.
The code was not properly checking whether the user was the
Offer Maker or Taker, and as such the report was always displaying
the Taker information for Tx and Trade fee. Therefore any trades
where the user was Maker showed the wrong fees.
The column title `Maker Fee` is incorrect and misleading since
the user doing the export is not necessarily the Maker. We
rename this column to `Trade Fee` to indicate that it is the fee
the user paid for trading regardless of Maker/Taker status.
Fixes#4207
Manfred [0] pointed out that COMPENSATION_REQUEST_MIN_AMOUNT and
REIMBURSEMENT_MIN_AMOUNT should be checked for not exceeding 200k BSQ
too.
[0] 4ec6bac658..fb76fd6548 (r420249962)
Without the break statement, the execution would continue through the subsequent case clauses until it encountered a break, executing `checkArgument` calls meant for `REIMBURSEMENT_MAX_AMOUNT`. More specifically, the bug would cause a failed check in the case where `inputValueAsCoin.value <= 200000000` is false.
There is no need to decrypt and re-encrypt wallet files in the unlock
and lock wallet methods. The temporary aesKey saved in the unlock
method will used for operations on an encrypted wallet.
There is also no need to cache a tempKeyCrypterScrypt; this class
level variable was removed.
Cache the aesKey instead of the password in unlock wallet method,
avoiding extra overhead of deriving it from the temp password in the
lock method.
The KeyCrypterScrypt used in the unlock method must also be cached for
use in the manual lock method. Creating a new KeyCrypterScrypt instance
in the manual lock method would have a different random salt value,
invalidating the password used in the unlock method.
