Previously, addresses that belong to a watch-only account would have a
derivation path using the internal account number used to identify
accounts within the databse, rather than the actual account number based
on the account's master public key child index. This wasn't an issue
before as only one account would exist within the wallet, the 0 account,
which is also the default. To ensure users of the DerivationPath struct
can arrive at addresses correctly, we introduce a new field
InternalAccount to denote the internal account number and repurpose the
existing Account field to its actual meaning.
This error would be seen when an old wallet that has yet to update is
performing the latest wtxmgr migration. It's possible for the locked
outputs bucket to not exist if outputs haven't been locked before, so we
should its deletion correctly.
We create a more generic copy of the dropwtxmgr command's functionality
and export it as the DropTransactionHistory function.
It removes all transaction history from the given wallet to force a
full chain rescan. Optionally the user-defined transaction labels can be
preserved.
Because of an incorrect test, it wasn't discovered that the scriptSig
field was being set on the unsigned TX inputs for a nested SegWit input.
This commit fixes the bug and also refactors the test so it would have
caught this specific bug.
To fix a bug where specifying multiple UTXOs that are by themselves
large enough to satisfy the output amount would lead to the rest of them
being added to fees, we need to provide the transaction author with a
constant list of UTXOs. If we didn't, the author would only consider one
input and calculate the change based on that alone. But since we'd add
all inputs to the PSBT, the rest of the amounts would go to fees.
To make it easy to show the user what change output was created (if any)
during the funding process, we return its index (or -1 if no change
output was created).
We would previously request spend notifications for all transaction
outputs, leading to irrelevant transactions being found in the wallet's
transaction store.
In this commit, we fix a 3 year old bug in dust calculation. Before this
commit, the target fee of the transaction to be crafted would be used to
determine dust. If the target fee is very high, then this would cause
over all higher fees, as we'd base that dust computation off of that fee
rate, rather than the min relay fee.
To fix this, we always use the min relay fee at all times when computing
dust.
