Moved GetOnlinePakKey to the scriptpubkey manager; the other blinding
stuff remains in the CWallet. At some point after the rebase we should
consider whether there's a better separation to be had between the PAK
related stuff now that we have wallet boxes.
This is the start of some nontrivial wallet refactoring by achow. See
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Class-Structure-Changes
for a high-level design.
This PR moves some stuff out of CWallet into a dummy "box" LegacyScriptPubKeyMan
which is (currently) very tightly coulped to CWallet. Because of the coupling there
are currently null-checks that cannot fail, things which assume non-nullness which
will eventually be wrong, and a plethora of currently-equivalent ways to get from
a CWallet to a provider or back.
Our approach is basically to ignore the refactoring; leave the blinding key stuff
in CWallet and have it call into the wallet's provider when we are obtaining the
underlying keys.
Later, probably in a post-rebase PR, we should rethink how we manage blinding keys
to more closely match Core's "all keys go into providers" model.
I'm sorry, this should have been a few commits, but it got away from me
as the scope of this refactoring was not immediately obvious. It essentially
just moves code around so hopefully is not too hard to review. --asp
This restricts the `bumpfee` RPC, when given a feerate target, to unblinded
transactions, because this is the only way I could figure out quickly to
allow adding inputs to an already-created transaction. It appears to be the
strategy used by the `fundrawtransaction` RPC which has similar behaviour.
This should be fixed in a followup PR.
asp: the point of this PR was to completely decouple libbitcoin_server from
bitcoin_tool; it removes $(LIBBITCOIN_SERVER) from the `elements_wallet_LDADD`.
I put this back in because our additional code related to pegin claiming makes
heavy use of methods from libbitcoin_server.
If we want to morally accept this PR then we need to do a nontrivial refactoring.
