It would be possible for users to create a descriptor with xpubs without
an origin set. In fact, not many are used to origins and it's a very
likely mistake. Signers need this information in order to be able to
sign. So they could potentially create a wallet and potentially never be
able to sign for one or multiple keys.
Fix this by requiring an origin for all keys in the descriptor.
We only allow to create "legacy" multisigs for now (that is, what fits
in a CHECKMULTISIG, ie k-of-n with n<=20). See
https://github.com/wizardsardine/liana/issues/53 for discussions around
this.
We are a bit more laxist on parsing, where any miniscript that
corresponds to a multisig policy will be accepted.
Note this makes the helper inferring the CSV value from semantic policy
incorrect, but this is fix in a later commit as part of a complete
refactor of this logic.
Instead of only incrementing it, allow to be able to set it to any
value. This will be useful for instance to set the derivation to the
latest used onchain, if another wallet is much further down the
derivation tree than we are (or after a rescan).
We'll need to store in persistent storage if a rescan was requested by a
user, and if so from what date.
For the SQLite implementation we introduce a rescan_timestamp to the
wallet table.
It seems that internally bitcoind might temporarily not have a pprev
pointer for a block. This will result in the optional
"previousblockhash" field to be null and would previously make us crash.
Handle that gracefully.
In config, expect to be given a multipath descriptor that contains a
derivation path for both receive and change addresses, but only for
those.
Instead of 'xpub/*', start using 'xpub/0/*' and 'xpub/1/*'.
When creating the watchonly wallet on bitcoind import both the receive
and change descriptors.
When polling, check for coins on both descriptors.
Our bitcoind watchonly wallet could, maybe, have other descriptors that
were imported. Sounds pretty unlikely since we use a dedicated wallet
but hey.
More importantly, we'll need to know the parent descriptor of the coin
in order to recognize it as newly received or change.
This also updates the indirect rust-bitcoin dependency to 0.29.
Major changes are in the descriptors management:
- The rust-miniscript descriptors don't support raw hashes
within the pk_h() fragments, so we don't need all the boutique
management for this.
- The key translator API changed.
- We now take a u16 for the timelock instead of our previous
checks. This was inspired by the new rust-bitcoin Sequence
type.
- We now take a path instead of just a derivation index in
DerivedKey. We might use paths after all...
As for rust-bitcoin it's just a few nits:
- No more 'global' field on PSBTs (yay)
- Couple more trait derivation on types
- Some APIs were renamed.
Hence add a 'spend_block_height' field to the 'coin' column in the
SQLite implementation. This also contains a couple cleanups, as well as
a fix (we were still checking if the blockheight was > 1).
I initially wanted to have a bridge table between the 'coins' and
'spend_transactions' table as we do in revaultd. But let's not optimize
to early, we'll see if/when we need it.
This also implements a simple JSONRPC server sanity check
And introduces a new tmp_dir() test utility, that i didn't have the courage to split from this commit
So we can have unit tests without a dummy bitcoind thread, as we
currently do for the startup test.
This commit also implements sanity checks for the two existing commands
using this mechanism.
