If a user has many UTXOs but wants to spend just one, they would have
to freeze all the UTXOs one-by-one except for one, then after sending
do the same again unfreezing all UTXOs one-by-one. This new command
drastically speeds up this process.
This commit fixes an issue regarding a wrong taker state caused by
initiating a taker operation when no `max_cj_fee` value is present.
Before this change the taker state switches to `running` indefinitely.
After this change the config check is made before updating the state.
Use sats/kilo-vbyte
Use words for large numbers
Improve unit consistency
Improve newline consistency
Improve comment consistency
Improve capitalization consistency
Improve section consistency
Fixes#1170.
Prior to this commit, an attempt to spend using
the direct-send endpoint in the RPC API would
cause a backend crash because the NoFundsException
was not being caught.
This is now fixed.
Adds code to validate bech32m encoded taproot addresses
and scriptPubKeys. The underlying functions are in
python-bitcointx upcoming version 1.1.3.
Adds tests at both the basic address validation layer,
and also at the layer of sending transactions to
taproot outputs.
Fixes#1166.
Fixes#1173.
Prior to this commit, in tests, we were calling
JMWalletDaemon.stopService at exit of the python script,
outside the pytest context, leading to various errors because
the test framework had gone through tear down.
After this commit, no attempt to call stopService is made
at exit (this is not necessary, we already call wallet close
and there is no other persistence necessary).
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.
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).
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.
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.
This commit changes the underlying functions used in
jmbitcoin from the private and public key primitives
in coincurve and replaces them with equivalent
primitives CKey and CPubKey from python-bitcointx,
this removes the need to install coincurve and its
own bundled libsecp256k1 dynamic library.
Note that an additional pubkey_tweak_mul function
is exposed with ctypes from python-bitcointx's
bundled libsecp256k1 library.
Fixes#1043.
Prior to this commit, only keys/scripts/addresses
inside the scope of the current wallet script_map
(the keys cached by sync, according to persisted
index in wallet file, including gap limit) would
allow a successful signing operation, otherwise
an assertion was raised.
After this commit, signing can be done with any
arbitrary height index in the wallet (assuming a
valid path for this wallet).
Some of the return codes for the endpoints in
the RPC API were incorrect, these are fixed.
They are also checked in the tests.
Additionally, an extra test of the maker start/
stop function is added (though it tests only
state updates, not actual service start).
Fixes#1091.
Before this commit, if the unconfirmed transaction
event triggered the taker_finished callback in the
RPC-started coinjoin, the value of fromtx is
'unconfirmed' and not False, hence an assertion error
was raised unless the confirmed event came first
(which is only likely to happen on regtest). This
crashed the jmwalletd daemon backend.
After this commit, the assertion check is only that
the value is not True, which it must not be as long
as we only accept single-join schedules.
Prior to this commit, the sendtomany.py script
would sometimes fail based on the output of the
RPC call gettxout returning only a script, and not
an address. After this commit, the validation will
still work correctly in these cases using the
chosen cryptoengine to convert from script to address.
Also notably, the return value of utxo set does
not include an 'address' key any more.
Tests are updated to reflect this.
Previously, the default config file generated by JM causes an error due
to not having `socks5_host` and `socks5_port`, which are commented out
since `socks5` is disabled by default. This commit makes those fields
optional when `socks5` is not set to `true` in the config. It also
makes `socks5` default to `false` if it is not specified in the config
for a given IRC server.
Prior to this commit, it was possible for a modified
taker client to get a maker to participate in a join
tx with a size less than their minsize, which could
burn up to an amount of the txfee contribution to
miner fees.
After this commit, the maker stops the coinjoin
coordination when the too-small coinjoin size is seen,
as intended.
Additionally, a check is now in place in the function
`Maker.verify_unsigned_transaction` that the earned
amount is positive, which otherwise could raise an
Exception (but should now be impossible in any case).
Also, changed the default txfee_contibution to zero
as it is of no value to have a nonzero amount.
Also return added for unrecognized orderid, for clearer
error messages.
chris-belcher
Kristaps Kaupe
Thebora Kompanioni
Adam Gibson
5F43CCDF
Dennis Reimann
Manas Gandy
Mark Lopez
Wukong
Daniel McNally
xanoni
Adam Gibson
unofficial bisq contributor