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.
Without bugfix, method would try to encrypt the wallet using using the
old password argument immediately after encrypting the wallet with
a new password.
Like the change in commits 163061a and 9164579, removeWalletPassword
now throws an IllegalStateException with an appropriate message if
the wallet password cannot be removed.
Also deletes unused StatusApi enums.
Like the change in commit 163061a, setWalletPassword now throws an
IllegalStateException with an appropriate message if the wallet password
cannot be set.
Also deletes unused StatusApi enums.
And throw an IllegalStateException with an appropriate message if the
wallet is not available or still locked.
This change also eliminates the NullPointerException that would
sometimes be thrown when calling #getAvailableBalance after the wallet
has become available but before the balance has become available.
Previously, each wallet-related method was implemented with its own grpc
service. There is no need to do this, as a grpc service may declare
multiple rpc methods. This commit refactors everything wallet-related
into a single GrpcWalletService and also extracts a CoreWalletService
from CoreApi in order to avoid the latter becoming overly large.
Ideally, there would be no need for an abstraction in bisq.grpc called
CoreWalletService; we would ideally use such a service implemented in
bisq.core. The closest we have is WalletsManager, but it is not designed
to be used the way we are using it here in the grpc context. Rather than
making changes directly to core (which can be very risky), we will
rather make them here in this layer, designing exactly the "core wallet
service" we need, and can then later see about folding it into the
actual core.
This change removes non-idiomatic gRPC *Reply proto message fields.
The client should not receive success/fail values from server methods
with a void return type, nor an optional error_message from any server
method. This change improves error handling by wrapping an appropriate
gRPC Status with a meaningful error description in a StatusRuntimeException,
and placing it in the server's response StreamObserver. User error
messages are mapped to general purpose gRPC Status codes in a new ApiStatus
enum class. (Maybe ApiStatus should be renamed to CoreApiStatus.)
Add a missing bsqWalletService.isEncrypted() check and optional AES key
argument to the signMessage(..) call in ProofOfBurnService, analogous to
the BitcoinJ call to sign with an EC key in MyBlindVoteListService.
This fixes#3836.
Implemented lockwallet, unlockwallet, removewalletpassword, and
setwalletpassword methods with basic error handling.
Also added basic error handling to existing getbalance method,
and removed unused BalancePresentation from CoreAPI.
TODO: update help text
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.
This omission is currently not disruptive, since the next case clause only contains a break. Also converted a few `return false` to breaks, to align with the rest of the switch statement.
We add a second button (displayed as first) to the preferences UI for
resync from latest resources. We add a warning to the resync from
genesis as it takes very long time and causes heavy network load for
seeds.
The resync button at the stateMonitor does now a resync from resources,
not from genesis.
We add handling of the UnconfirmedBsqChangeOutputList file as well.
In Filemanager we add a check if file exists.
There is no actual requirement for this method, so removing it. It also
helps improve the implementation by removing the need for the static
'instance' field.
