The most notable change is rust-bitcoin's change in the serialization of
transaction with no input. It now accounts for the segwit marker even
for those. The base tx weight in coin selection had to be adapted to
handle this.
See https://gnusha.org/bitcoin-rust/2024-01-04.log for details.
Comparing the address itself includes the network, but an
unchecked signet address will have its network set as testnet
by `assume_checked` and so change addresses will not be
matched.
This adds an extraneous DEFAULT compared to the schema in freshly
created databases, but anything else (altering the column in an
SQLite-friendly way after setting all NULL values to 0) would be way too
involved.
We detect and store immature deposits (cause otherwise we won't go
through them again with listsinceblock), but mark them as such and
unconfirmed.
We only mark them as confirmed once they've matured. It's a bit clumsy
but it's not as if most of our users had coinbase deposits.
We need to keep track of such coins to:
- Track their maturation
- Avoid using them (for instance in coin selection)
Reorg handling for coinbase deposits that become immature is not
implemented (yet). That's reasonable because:
1. It would be very unlikely that we'd move back, so it's most likely
gonna be mature again immediately.
2. If there's a reorg of more than 100 blocks we've got bigger problems.
Rust-bitcoin, that we use through rust-miniscript, has seen plenty of
breaking changes in the latest version. I've tried to keep the necessary
changes here minimal, still it had to be a single commit to keep it
hygienic. But i'll try to summarize the main things here. Tobin also
wrote a guide about the release at
https://rust-bitcoin.org/blog/release-0.30.0/.
The most verbose change in this commit is probably due to the `Address`
type overhaul. It's overengineered if you ask me but hey here we are. I
tried to keep network validation in commands, and otherwise passing
around unchecked addresses (to avoid having to pass around a global
state between our various components).
Another non-obvious change was changes in hash types upstream and the
removal of `ToHex`, forcing us to get the hex representation of a txid
through its `Display` implementation. It is however displayed backward
in this case ("little-endian" if you will), and we need a regular hex
encoding for some queries to the database. We needed to make sure we
didn't implement any silent bug here.
The rest (Script type changes, PSBT serialization updates, ..) is
probably self-explanatory.
Since this is our first modification to the database schema since the
first release of the software this also introduces migration logic for
existing databases.
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.
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.
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.
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).
