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.
Fixes#1215.
Prior to this commit it was possible to send a non-coinjoin transaction
while the maker service was running, over the RPC-API call direct-send.
However this was not intentional, as it is not usually safe to perform
UTXO database write actions when the effective 'lock' on write actions
is already held by a long running service/action such as yield generator
or tumbler. This commit prevents that call being successful if the
current state of the JMWalletDaemon is not CJ_NOT_RUNNING.
This commit also disables freeze actions in the same situation, and
changes the HTTP error code for these cases to 400.
Add a new helper module to calculate fidelity bonds values and stats, and a script to use it.
The goal is to give as much information as possible to the user before
committing to a fidelity bond.
Fixes#967. In this test, if the randomized fee calculated from the
tx_fees field in the config happens to be at the bottom of the range,
it's possible that the calculated feerate is very close to 1.1 sats/vB,
but this can still vary slightly due to signature sizes, resulting in a
very rare case where this test could erroneously fail.
This is fixed by bumping the lowest minfeerate by 2%.
Fixes#1294.
Before this commit, calls to query_utxo_set with default arguments
would ignore the mempool and thus return utxos which were spent in
unconfirmed transactions. Thus, takers would continue negotiation of
coinjoins with makers who sent them already-spent utxos, leading to
failure at broadcast time. This was not intended behaviour; we want
takers to reject utxos that are double spent in the mempool.
This commit changes that default argument to True so that utxo set
changes in the mempool are accounted for. It also switches the name of
the includeunconf argument, which was misleading, to include_mempool,
with appropriately updated docstring.
Finally, in this commit we also ensure that callers of this function
check, where necessary, the returned confirmations field to disallow
unconfirmed utxos where that is necessary.
PR #986 introduced two distinct balances at different levels of
the wallet tree; it serialized these balances for CLI and Qt display
but changed the RPC-API json output of the /display endpoint in a
suboptimal way. This commit fixes the json structure.
After this commit, the four levels (wallet, account, branch, entry) now
all still have balances reported under the same key as before #986, that
is, total_balance, account_balance, balance and amount, but the extra
information introduced by that PR, namely the 'available_balance' is
added as an extra key in the json dict.
Tests are added to check this structure.
Before this commit, if Joinmarket-Qt or any other long running script
was started when a new utxo had been created in the wallet, but was not
yet in a block, the transition from unconfirmed to confirmed state would
not be registered, because when confirmation happened and the event was
seen in the transaction monitor, that txid was not in the active_txs
dict. This is now fixed.
For frozen balances, display a label "FROZEN" in the status notes.
For unconfirmed balances, display a label "PENDING" in the status notes.
Both FROZEN and LOCKED balances are considered unavailable balances, while PENDING balance is considered available balance.
Because it is possible to broadcast a transaction that spends unconfirmed balance, while a user has to manually unfreeze
the balance or wait until the timelock has expired before they can use FROZEN or LOCKED balances.
Closes#1247.
This consists of an inclusion of the bond value exponent into the config
that the user can alter, and a change of that from 2 to default 1.3.
Also updates the fidelity bond documentation to account for those
changes, including the units used in ob-watcher, but not the calculation
of fidelity bond attack resistance (which remains a TODO).
Previously the `cert_msg` in the fidelity bond protocol involves a
binary public key. This is additional unnecessary complexity given
that we want other wallets to also implement the fidelity bond
protocol (see issue #993 for full discussion). So its good to move
to a certificate message which is entirely ascii.
This commit has ascii certficiate messages also be accepted as valid
along with the old certificate messages.
Fixes#1214.
Prior to this commit, if a broadcast of a transaction failed locally, or
failed after attempting remote broadcast then falling back to local via
the function jmclient.taker.Taker.handle_unbroadcast_transaction, then
the version of the on_finished_callback found in
jmclient.wallet_rpc.JMWalletDaemon incorrectly asserted that the fromtx
keyword argument must be True, thus failing to update the state of the
daemon to CJ_NOT_RUNNING.
After this commit that assertion is removed, and the coinjoin_in_process
value returned over the API is correctly False after either a
successful, or an unsuccessful, finishing of the coinjoin.
Fixes#1213.
Prior to this commit, if the YieldGeneratorService were started via a
call to /maker/start over the RPC-API, the early check of whether coins
were present in the wallet to allow starting the maker, incorrectly read
the contents of the dict returned by
jmclient.wallet.UTXOManager.get_balance_by_mixdepth, which returns
entries for mixdepths with coins which are all frozen, with a total
value of zero, even if the include_disabled keyword argument is set to
False. Thus only checking for whether the length of the returned dict
was zero was incorrect.
After this commit, we will stop early, as intended, for a wallet which
has no mixdepths with any non-frozen coins.
Fixes#1212.
Before this commit, transactions were kept monitored in
WalletService.transaction_monitor after first being seen, only if the
list of confirmed callbacks was non empty, but this meant that the logic
is process_new_tx was not executed, meaning the height field of the utxo
was never updated from INF_HEIGHT, so the utxo would continue to be seen
as having zero confirmations, even after blocks are mined.
After this commit, we add any transaction that was seen to the
active_txs dict, so that the height field, and thus the number of
confirmations reported, is correct even if the caller never registered a
confirmed callback.
`:80` needs to be provided otherwise parsing will fail with
Failed to load directory nodes: InvalidLocationStringError('3kxw6lf5vf6y26emzwgibzhrzhmhqiw6ekrek3nqfjjmhwznb2moonad.onion')
This is correct in the auto-generated configuration file, but not in the
document.
Also mention that even for UNIX sockets, it's necessary to specify `tor_control_port`.
Prior to this commit, running ob-watcher with
an onion-type message channel configured would result
in the bot attempting to connect to all the makers,
which is bad. This happened because the internal logic
of the onion message channel is that receivers of privmsgs
will be sent peer info from the directory, so that they can
immediately respond p2p if they succeed in outward connecting.
But for bots who do not intend to engage in a coinjoin interactive
protocol, like ob-watchers, this is absolutely not the desired outcome.
After this commit, a bot can specify mode "PASSIVE" in the call to
get_mchannels(), which results in the OnionMessageChannel object only
creating non-directory remote peer objects of type OnionPeerPassive,
instead of OnionPeer, which means they never try to connect to those
remote peers.
Adam Gibson
PulpCattel
Daniel
theborakompanioni
Kristaps Kaupe
dependabot[bot]
Wukong
chris-belcher
laanwj