To allow a wallet to be created directly from an extended master root
key (xprv), we move the derivation from seed to extended key to the
loader instead of the address manager itself.
We can now get rid of our incorrect dust calculation which did not
give exact values for segwit outputs as it was based on spending a
P2PKH output instead.
To make sure we don't create any manual DB transactions, we refactor the
txToOutputs method to use walletdb.Update and the new
walletdb.ErrDryRunRollBack error for making sure a rollback is issued.
To make sure we don't create any manual DB transactions, we refactor the
ImportAccountDryRun method to use walletdb.Update and the new
walletdb.ErrDryRunRollBack error for making sure a rollback is issued.
Let the method `addRelevantTx` use `InsertTxCheckIfExists` to insert a relevant
transaction. If the transaction has already been recorded, the method call
`addRelevantTx` will return early and not proceed with duplicating work of
checking every output and duplicating the tx notification to the notification
server.
This method returns the first N external and internal addresses, which
can be presented to users to confirm whether the account has been
imported correctly.
Simnet was previously left out as it didn't have defined HD versions for
some of our key scopes. To allow testing importing accounts into simnet
wallets, we fall back to use the mainnet HD versions.
This commit also addresses an issue with simnet wallets that would arise
whenever ScopedKeyManager.AccountProperties was invoked:
`failed to retrieve account public key: unsupported net SimNet`
Now that we're able to fund transactions from multiple accounts within
different key scopes, we extend our transaction creation methods to
accept a key scope parameter as well, to determine the correct account
to select inputs from.
Following the previous commit, some external hardware signers require a
master key fingerprint to be present within the PSBT input derivation
paths so that the signer can recognize which inputs are relevant and
must be signed.
Watch-only accounts are usually backed by an external hardware signer,
some of which require derivation paths to be populated for each relevant
input to sign.
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.
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.
