Prior to this commit, the test of the reception of a notification via
the websocket would fail intermittently because the notification was
being sent without waiting for the setup of the websocket connection to
complete.
After this commit, we fire the notification event only after the setup
and authentication check of the new websocket connection is complete.
This commit creates a new endpoint /getinfo which currently returns only
the version of Joinmarket (JM_CORE_VERSION) running in the backend
joinmarketd. In future commits the returned dict may add more
information, for example the current block height of the connected
Bitcoin Core node.
Additionally, this commit fixes the response type of the
/rescanblockchain endpoint as defined in the OpenAPI spec.
Prior to this commit, an attempt to change the gap limit used in wallet
syncing, by setting gaplimit in the config via configset, would fail,
since gaplimit was only being read from command line options. After this
commit, the value of gaplimit in the POLICY section of the config,
defaulting to 6, will be read and used in Wallet object creation, either
via the createwallet or recoverwallet endpoints, or via the wallet
opening operation in the unlockwallet endpoint. This can be used in
combination with the rescanblockchain endpoint to allow discovery of
funds in addresses beyond the default gap.
Fixes#1483.
Prior to this commit, running the RPC API server using Klein failed
due to a recent change in Werkzeug 2.3+, preventing any endpoint from
returning anything but a 405 error. See
https://github.com/twisted/klein/pull/575.
After this commit we pin to 2.2.0 until such time as updated versions of
werkzeug/Klein are reviewed by us.
Fixes#1082:
This commit allows recovery of a wallet from a seedphrase
with a new endpoint wallet/recover. 4 parameters are passed in,
the same three as for wallet/create but also a bip39 seedphrase
as the fourth argument.
This commit also adds a rescanblockchain RPC call and status:
This adds a new endpoint /rescanblockchain which is (Core) wallet specific
(due to underlying JM architecture). This action is spawned in a thread,
since the bitcoind RPC call is blocking and can take a very long time.
To monitor the status of the rescan, an extra field `rescanning` is
added to the /session endpoint.
Also adds test of rpc wallet recovery
This allows running tests that do not require, e.g., bitcoind, without having to run these setup fixtures at all.
Signed-off-by: PulpCattel <PulpCattel@users.noreply.github.com>
This may or may not fix#1057 and other test failures. Since the network
delay in receiving the message is unknown (but expected to be very
small, usually), we keep trying to receive notification of the
transaction message in the websocket test 10 times for a total of 2
seconds (on the assumption that if it takes longer than that, something
else is wrong).
Prior to this commit, p2wsh inputs from fidelity bonds resulted in
miscalculation of transaction fees, even in cases where the exact set of
inputs were known (such as a direct send).
In this commit we change the estimation to a model in which the caller
of jmbitcoin.secp256k1_transaction.estimate_tx_size must specify a list
of types, one for each input to the transaction, and the same for
outputs. In some cases, the caller of the function uses the default
script type of the wallet, but in other cases where the caller can know
the exact types of each utxo used as input, and each destination used as
output, they are specified explicitly. In particular, the use of
fidelity bond outputs as input to transactions can be accounted for.
Currently this is only done in direct send payments; coinjoins still
fall back to assuming all inputs the same type (note that it is not
possible to use fidelity bond utxos as inputs to coinjoins).
Note also that the burn destination calculation in direct send is
removed, since it is not used, so the maintenance burden is best
avoided.
Fixes#510.
Prior to this commit, if the call to
jmclient.BitcoinCoreInterface.get_current_blockheight() failed and
returned None, the function jmclient.WalletService.sync_unspent() would
simply ignore the failure and the wallet syncing process would complete,
without ever resetting and updating the wallet's utxo set, resulting in
a situation where users saw out of date utxo sets in their wallets (and
concomitant spending failures).
After this commit, if that blockheight access call fails 5 times, we
instead abandon the attempt to sync the wallet, and shut down the
application.
also, use tx_fees_factor for randomized max mempoolminfee and
make sure that tx_fees_factor is equal or greater than zero.
Co-authored-by: Kristaps Kaupe <kristaps@blogiem.lv>
Prior to this commit, the 'testflag' was set for the Taker object that
was created in running the tumbler via the RPC API. This flag prevents
the function client_protocol.JMTakerClientProtocol.stallMonitor from
running (which is useful in certain cases), which was not intended.
After this commit, this flag is not set, so that when a transaction
fails to go through, the stallMonitor will wake up after some time and
retry the transaction, as should occur.
roshii
Adam Gibson
Kristaps Kaupe
dependabot[bot]
PulpCattel
Luke
Carl Dong
hellodarkness
theborakompanioni
nyxnor