- "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.
In bisq-network/bisq/pull/4223 a fix was made to the QRCode display
of amount needed to fund an offer. This accidentally introduced a
bug whereby if the user overpaid the funding, then the QRCode would
throw an error `Coin must be positive`. This is due to a race
condition in OfferDataModel which was setting a property first
to a negative amount before checking if it was negative and if so
then setting it to zero. The fix here is to check for negative
before setting the property so that any listeners do not get an
event (negative) followed by another event (zero).
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.
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.
Add a link to a StackOverflow answer showing how to configure IDEA to
automatically check and enforce the format of the commit message.
More specifically, the 50-character limit for the commit title and
72-character limit for the commit body.
- Polish whitespace and newlines; wrap comments at 90 chars
- Use package-private vs protected visibility when exposing
BitcoinFeeRateProvider constants for testing
- Document that 'maxBlocks' is dead code, but do not remove it yet, as
it would disrupt the process of getting this fix out quickly because
it would require operators to change the way they start their
pricenodes.
The API endpoint for fee estimations has been changed to one that delivers more accurate fee estimations.
This is a temporary solution, until a more decentralized approach is found.
Fixes projects/issues/27
This commit factors out a run() method in CliMain that either returns
(void) or throws an exception. This eliminates the need to call
System.exit in so many places as were previously. Indeed, now there is
only one place where System.exit is called.
It also removes the duplication of printing "Error: ..." to stderr when
something goes wrong by doing this once in the global catch clause in
the main 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.
