This is a new command dedicated to the recovery usecase. For now it's
dead simple: sweep all coins that are available through the recovery
path to a given address.
0306773cdca15009d3bf2c6eb0c3ebd8e7fb7989 daemon: log and exit 1 on startup error, don't panic (Antoine Poinsot)
13b2b8eef4dd5deafe04b2330b469067afd0b12c bitcoind: immediately set the default retry limit (Antoine Poinsot)
b0ef121e91209e1c69ddefa0765d7a93d1dfb569 bitcoind: accurate connection sanity checks at startup (Antoine Poinsot)
Pull request description:
We were not properly treating warming up errors when bitcoind was starting up. Also, better to just log as error and `exit` with `1` instead of panic'ing on a daemon startup error.
See the commit messages for details.
Fixes#134Fixes#163
ACKs for top commit:
edouardparis:
ACK 0306773cdca15009d3bf2c6eb0c3ebd8e7fb7989
Tree-SHA512: e14a72456104682ccff30d88e21303447065d371aed7279461595795eb938ba823578f05cc47704d996dbe570d12f467b91a88d58363511864e6a1f10eb76004
We were previously adding it later on to fail early on startup error.
This didn't handle well "warming up" errors.
Now that it was reachable and listening to requests already, we can just
use the real retry limit from the get-go.
The current checks were only testing whether a bitcoind was at all
reachable. We need to make sure it is also listening to requests (and
not warming up) in order for the assumptions made later on (we panic on
requests if we retried for too long) to hold.
This makes the startup sanity checks also wait for bitcoind to get out
of warming up mode.
3224f08ba083e384f55abb690770d8dd09f8ea3d daemon: update rust-miniscript to 0.9 (Antoine Poinsot)
Pull request description:
This also updates the multipaths descriptor patch to the review PR https://github.com/rust-bitcoin/rust-miniscript/pull/470 (rebased on 0.9)
Fixes#123.
ACKs for top commit:
darosior:
self-ACK 3224f08ba083e384f55abb690770d8dd09f8ea3d -- trivial.
Tree-SHA512: 03c8b181e96df8d73953cefadfbb090049859f01e6c8d03cf8417ad4d46795dc295b097f8df6c0f683fb9da03b78f39e824cb7768376d1d5718bdce177edcb6d
a4e66566886901f28e383e67f06de2215e3ebc42 daemon: remove / correct some TODOs (Antoine Poinsot)
628ed3d0ed3997a64d8d0d92206842ef5445e2fa descriptors: remove TODO in assertions, explain instead (Antoine Poinsot)
62067f0030795143cbec87dcc1d5db0e5265c5c5 qa: remove needless import in fixtures (Antoine Poinsot)
Pull request description:
Small things i noticed while working on #148.
ACKs for top commit:
darosior:
ACK a4e66566886901f28e383e67f06de2215e3ebc42
Tree-SHA512: 0d6b6b95a99744cd92b9ecd30d9678ff27c7223238a31c3e9093899caa11889d40cfe4c7d855c07c378ca127ca900269980d179aeb02478f04e3eaa1e20e1721
The outpoints argument could eventually be made optional in order to
introduce some automated coin selection. So it makes more sense for it
to be after a required parameter, the destinations.
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).
Give the range to 'importdescriptors' when re-importing a descriptor for
rescanning. This is because the range must include the range of the
descriptor being updated.
Secondly, it is possible that the combination of our timeout-to-1s hack
and our retry logic trigger an edge case: we would retry after
successfully triggering a rescan, and therefore panic on a "a rescan is
already ongoing" error. Instead check before starting that we aren't
rescanning already, and assume that such an error after triggering the
rescan is because we succeeded. That's racy but only reasonably so (as
long as we don't crash, which isn't the case here).
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.
The query we are going to use to rescan, 'importdescriptors' will block
until the rescan is finished. Stopping the connection through a timeout
immediately after triggering the rescan is a workaround to make it
asynchronous.
Eventually we should probably use 'rescanblockchain' but then it
wouldn't update the timestamps of the descriptors in the watchonly
wallet...
We are passed a timestamp and we want to know down to what height we
should rescan / roll back. That's helpful for it. It was a bit tricky
although it's a simple binary search.. So to make sure i got it right i
made it a standalone function in a utils/ module to be able to unit test
it.
See the TODO, it's theoretically not precisely entirely correct. But
it's good enough for now.
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.
