Fixes#1168.
Before this commit, if an RPC client sent /maker/start
on an active wallet without confirmed coins, it would
raise NotEnoughCoins but this would happen *after* the
call to the setup function which resets the coinjoin
state to CJ_MAKER_RUNNING, even though the maker service
did not successfully start.
After this commit, the raise of NotEnoughCoins happens
first, preventing the update of coinjoin state.
Prior to this commit, a lock of one wallet followed by
an unlock of another, or an unlock of a new wallet, overriding
the old one, if it occurred during a running taker-side
coinjoin, would not reset the coinjoin_state to CJ_NOT_RUNNING,
resulting in an inability of the newly loaded wallet to function
correctly.
After this commit, all subservices, including the quasi-service
of taker-side coinjoin, are fully shut down whenever a wallet is
locked, or a new wallet is unlocked. This may be suboptimal (see
TODO) but is logical for now.
The main effect is to ensure that a new wallet will always start
in the correct coinjoin state (CJ_NOT_RUNNING).
Also worth noting, a running Taker will have its abort parameter
set to True on the wallet lock event, meaning that it will not
proceed to the next step on the next asynchronous message coming
from counterparties.
Fixes#1162.
Prior to this commit, the default argument [] was provided
to the bitcoind RPC listunspent call, which means only confirmed
unspent coins are returned. This is in contrast to the display
in wallet_tool, which deliberately updates listunspent_args to [0]
in order to default to showing unconfirmed coins, as users will
expect.
This commit adds the same listunspent_args = [0] in case the user
has not edited this variable in the config, for the same reason.
Fix shutdown of already open wallet on new unlock
Prior to this commit, if a JSON-RPC API client called
/unlock on a new wallet while an existing one was currently
loaded, the preexisting wallet would not have its wallet
service shut down, and thus the .lock file would not be removed,
resulting in an inability to open that wallet a second time.
After this commit, we correctly refer to the wallet service
internally such that its service does get shut down, and the
close event of the wallet occurs, removing the .lock file as
required.
Fix re-unlock of currently unlocked wallet
This behaviour was originally intended by #1136. If a wallet
is currently in an unlocked state in the daemon, but the user
loses the auth token, and tries to re-unlock, then before this
commit, the unlock operation would fail because there was an
unsuccessful attempt to open the wallet file.
After this commit, if the unlock request is applied to the wallet
with the same name as the one currently active, then the password
is authenticated by opening the wallet in read-only mode, preventing
the above issue from occurring.
Fix bug that lockwallet doesn't delete wallet_name
Before this commit, the member variable wallet_name in
the JMWalletDaemon object was not being reset to None
in a call to the lockwallet endpoint which meant that the
unlock event erroneously treated the wallet as already being
active. This corrects that error by setting walet_name to
None in lockwallet.
Fixes#1122. An RPC client can request the list
of coinjoins as shown in the file datadir/logs/yigen-statement.csv.
Authentication is not required, nor a specific wallet, as this is
a global list of all coinjoins done so far. A 404 is returned if
the file has not yet been created (no maker operations).
f899daabe6 Do not auto generate the QT UI code in setup.py (Wukong)
Pull request description:
If the user has an incompatible version of PySide2 installed on their system, the generation process might fail.
Since we have already checked in the correct version of the generated QT UI code, we don't need to run the generation process for every user in the `setup.py`
Hopefully this fixes#1087
Top commit has no ACKs.
Tree-SHA512: d1b5189369dfbdeda83250e9ebdd93d4bb14632ded5bd3a10a88362e237f548756326122755aa84a03ff74e558039adf288fc21c16a3d256486780d734edbb8f
b953d7e75d Document rpc_cookie_file and rpc_wallet_file in default config (Kristaps Kaupe)
Pull request description:
RPC cookie auth was added in #128 (Mar 2018), but never documented anywhere. This adds it to default generated `joinmarket.cfg`. Also added detailed comment about `rpc_wallet_file`, as it also sometimes confuses new users.
Top commit has no ACKs.
Tree-SHA512: 27613b1b293220c2666bd887a374d14048f604cd0e9592d5e1294e800c7d839ee6798a6d3a776c9731d828adc683990814484195d3a0f9581a996a27134578cb
Fixes#1093. This adds a POST method freeze for a wallet,
in which the utxo must be specified as a standard hex txid:n
string in the body, along with a boolean value of 'freeze', to
toggle the frozen/unfrozen state of the given utxo in the wallet.
Fixes#1123. Prior to this commit, the unlockwallet
method erroneously waited for wallet sync before continuing
and returning the credential. This was not necessary as the
WalletService method startService calls wallet syncing
asynchronously(!) in request_wallet_sync. Hence this initial
syncing step is removed, allowing the RPC call to return
immediately.
Fixes#1143 (and possibly others). Before this commit,
(index plus gap limit) addresses are imported on sync,
and addresses used by maker/taker in coinjoin are imported,
but when a deposit occurred, bumping the index, further
addresses were not imported. The effect was that it was
possible, if doing a series of deposits to multiple
external addresses in a Qt session, to end up depositing
to an address that was not yet imported. And this results
in the user needing to rescan for Core+JM to recognize the
coins.
After this commit, we ensure all 'gap limit forwards'
addresses, which are displayed as potential deposit addresses
in Joinmarket-Qt, are imported before the display.
Fixes#1120. As per the discussion in that issue, while
we can only return 'processing started' by default, and
the client must monitor progress/state to see if the maker
service has connected successfully, nevertheless if the
maker startup is immediately invalidated by the fact that
the already-synced wallet does not contain confirmed coins,
we can and should return an error message instead of a 202.
This commit does that, adding to the spec a 409-No-Coins
response type which indicates to the API client that the
setup of the maker failed for this specific reason.
Fixes#1118.
Before this commit, the json serializtion of a
WalletEntry object was incorrect and missing some
fields. This is now fixed, and the WalletDisplayResponse
in the RPC spec .yaml file correctly reflects the
fields that are returned by the JMWalletDaemon in response
to the /display request.
f05492110b Pin python-qrcode to a specific version (Kristaps Kaupe)
Pull request description:
There have been some [takeover of qr.js NPM account recently](https://github.com/zpao/qrcode.react/issues/168). Let's remove potential attack vector here by pinning `qrcode` to a specific (latest) version.
It seems that PyPI does not allow overwrite of already uploaded files, so, unless PyPI itself is hacked, this is safe, it can't be replaced with something else so easy (although using package hashes would be better, of course).
Top commit has no ACKs.
Tree-SHA512: 34aebae3a875dc780417303649b253c2d4ab40dbbe358fc47dc13913beb1f64e40e670e36fa2eb183f622cf3541cd75ba948f009370a8ffcb93c21d21bfa1262
Prior to this commit, if a user has attempted
a coinjoin with /taker/coinjoin but a problem
occurs (such as an unresponsive maker), they
are not able to abort the protocol but must wait
until the taker_finished event is triggered.
After this commit a GET request to the endpoint
defined as /wallet/walletname/taker/stop will
force-stop the coinjoin attempt (similar to
quitting the script in CLI). This will reset the
wallet daemon state to CJ_NOT_RUNNING.
Fixes#1121.
Prior to this commit, if a user
lost access to the authentication token for
a session with the wallet RPC, they would not
be able to lock the existing wallet before
authenticating again (getting a new token for
the same wallet, or a different one).
After this commit, a call to the /unlock endpoint
will succeed even if an existing wallet is currently
unlocked (whether a different one or the same one).
The existing wallet service, if present, is shut down,
if the attempt to authenticate a new wallet, with a
password is successful (otherwise nothing happens).
A test is added to make sure that this re-unlock can work.
David Parrish
Adam Gibson
Abhishek Anantharam
Dennis Reimann
Kristaps Kaupe
Manas Gandy