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.
Prior to this commit, the tumbler algorithm assumed that destination
mixdepths of INTERNAL transactions were incremented by 1, but the
underlying taker code uses (mod maxmixdepth) logic always. This commit
takes the decision to make the usage of the wallet "purely" cyclic, that
is, not only the Taker object but also the tumbler algorithm now always
treat the wallet as a cycle. This is not problematic in a tumbler
algorith (or any other schedule generation algorithm), as long as we use
the strict rule of "always exit each mixdepth with a sweep", which the
tumbler always did and this commit does not change.
Also, and importantly, several much more detailed tests of the tumbler
schedule generation have been added.
Fixes#1314.
Prior to this commit, an attempt to start a maker bot which only
contained coins that were expired timelocked utxos (i.e. spendable),
in the RPC would result in the maker service starting but failing to
create offers. Instead, we want the maker service to not start as there
are no coins actually available for it.
Kristaps Kaupe
Adam Gibson
PulpCattel
Luke
Carl Dong
hellodarkness
theborakompanioni
nyxnor
Daniel