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.
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.
Adam Gibson
Luke
Carl Dong
Kristaps Kaupe
hellodarkness
theborakompanioni
nyxnor
PulpCattel
Daniel
dependabot[bot]
Wukong
chris-belcher