7e96cdd4949c15723ce1a150a1cc02dd5a402622 Add transaction history to home panel (edouard)
Pull request description:
ACKs for top commit:
edouardparis:
Self-ACK 7e96cdd4949c15723ce1a150a1cc02dd5a402622
Tree-SHA512: 98802d141073683ee09efe9e79ad28f9daba2145fdddf395c1b1758dc5f1c5763b483e1ca3d8ff35ce508138cf23989d8d3ed30c7d5044d311614b9fbe476b00
b4f6bbd8ffa722c48725fc724ca6cb1a4cf0b116 Add a README, finally. (Antoine Poinsot)
2663d970c77c7c13da8f39c3059123ef231b1787 Add a CONTRIBUTING.md (Antoine Poinsot)
f5ff0fad362a20d97d4ccc7fc5926bbfab50ec3a daemon: 'revaultd' name usage leftovers (Antoine Poinsot)
Pull request description:
Starting the documentation effort with those two main files. I'll address both a dedicated document about building the software and another dedicated document about recovering from descriptor backup in a follow-up.
ACKs for top commit:
darosior:
self-ACK b4f6bbd8ffa722c48725fc724ca6cb1a4cf0b116
Tree-SHA512: 58172527d6c09b718f9b15989fe976ceb4c20192bd8dfc7ee2cc9c683f8add19ef184869e1ab285c3d025b5ed6d69c6e9f3eaf5fc3f8e9a29ba632c0e3cae2d9
ee466798bd30fe9de0bc0f447b5a2ebe32b4ade1 gui: change project and crate name for liana (edouard)
Pull request description:
close#98
ACKs for top commit:
edouardparis:
Self-ACK ee466798bd30fe9de0bc0f447b5a2ebe32b4ade1
Tree-SHA512: 904c56b212821ef4d3d735f2cfd240b4ac5d3b1887a1335014dc007d438f84c6de04a1d2f3ef2abb579a473a210ee4b1606dbbc7175faf0a96e78f7896b18add
968a7d17a02bc776c38274fc9e61235163c22442 daemon: rename Minisafe to Liana (Antoine Poinsot)
Pull request description:
We decided on a new name for this project. Farewell Minisafe, "not a Bitcoin vault".
To avoid conflicts with ongoing work in the GUI i have only made the change on the daemon for now.
Fixes#91
ACKs for top commit:
edouardparis:
utACK 968a7d17a02bc776c38274fc9e61235163c22442
Tree-SHA512: e0d9324423b650bf4c8ec3084fb0002b2eb9b29e028f6f7c7be2062c10cc8ea3a2c3186689700495a0bfbd5c7cb75b549fffa06604bdd182c589aad3bbf61e0d
4bd65213e2561453f7c1fee16acccdd128296406 commands: swap the outpoints and destinations arguments to createspend (Antoine Poinsot)
838daa0c93ad72adde9b5c502796f87571fb5efd commands: set the BIP32 derivation in PSBT for change outputs (Antoine Poinsot)
dbf17681a432791f58ef4cdbb3fb2ebfa4ba0742 commands: signal for opt-in RBF in Spend transactions (Antoine Poinsot)
Pull request description:
It was missing a few things, see the linked issues for details.
Fixes#90.
Fixes#76.
Fixes#33.
ACKs for top commit:
darosior:
self-ACK 4bd65213e2561453f7c1fee16acccdd128296406
Tree-SHA512: f7122d48afa764b68993df7e66043900408ec64aa9181a87495168476d424a19dbf6adac3885df7a0d0865f0c47b17faea246f4abcbd7c908baf26fc8d0d6269
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.
94d8ea6d600479d00e08992aaf153e136e5198fa qa: test "next derivation index" update from onchain usage (Antoine Poinsot)
b31673de327bc968c4046267ef5d0433b80ddd7e poller: update our internal derivation index also from the chain (Antoine Poinsot)
42d2ffeec12edb22a789d92d8f83c8b535fc0477 db: more flexible interface for updating our next derivation indexes. (Antoine Poinsot)
Pull request description:
Currently, we wouldn't update our "next derivation index" to derive receive/change addresses if we noticed an address from a higher derivation index was used onchain. See #81. This fixes it.
Note that it can be tempting to set it with some leeway (for instance if we notice index `n` was used, we set our next derivation index to `n + 10`) since other wallets probably have generated addresses for more addresses than were actually used onchain.
However, i think it could have cascading effects in a multisig situation: A would use `n`, B would set its to `n + 10` and use `n + 11`, C would set its to `n + 21` and use `n + 22`. This is clear that we could end up very far indeed down the derivation tree without having used most indexes.
A functional test is included, demonstrating the behaviour after a rescan where we lost the database (and therefore knowledge of the previous "next derivation index"). It is in a separate commit to help reviewers attest it would fail on master and pass on this branch.
ACKs for top commit:
darosior:
self-ACK 94d8ea6d600479d00e08992aaf153e136e5198fa
Tree-SHA512: 67a44ac28dae391c23dd5143e9d560678e1928eddbfd2fc7ed721e02227151a8ea9571a867b6dd0e93f25ebe59adbdf846a8851c63a89144a818de870723b5da
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).
32f3bdeb16b66878e23ba71a6f2c401c5d1f601a bitcoind: check the rescan was successful, retry at most 10 times (Antoine Poinsot)
337f422283e3392b6cea94df6211fd6c736772ef bitcoind: add the timestamp to the 'listdescriptors' entry (Antoine Poinsot)
3c75e2e944638fdfe7ae6986aee9af83e0e2a532 bitcoind: disable retry logic for noreply requests (Antoine Poinsot)
55cf21fa2aa7a66d998061684630a32cfb972a35 qa: unflake the getinfo RPC functional test (Antoine Poinsot)
96b634b69c3b059c0711a35bac580ffcbf34af57 bitcoind: make the rescan starting interface failible (Antoine Poinsot)
85cd261fcd50e87ad8c3b6a5443e7e38266ff655 bitcoin: remove the BitcoinError enum, use String as error instead (Antoine Poinsot)
9b253e7ea71e3da38922e35a9fdc182e85a15bcd bitcoind: rescan with a range, handle spurious error when rescanning (Antoine Poinsot)
ff753fecca5c1c77c44a4627a565e580aefc9446 bitcoind: get more info from 'listdescriptors' (Antoine Poinsot)
4a7fd1af2999622af7e6421c0bea611688150cae commands: check if the Bitcoin backend is already rescanning (Antoine Poinsot)
8a22f5e8c944447572bad60fa7e187058483ed47 qa: functional tests for block chain rescans (Antoine Poinsot)
925df283a62af32d816bcf2e0b2d20c7f08a3a31 bitcoin: check for ongoing rescans in the poller (Antoine Poinsot)
073cdd0a89c8688b2cdad73666b71a79d9f81ae1 commands: add a 'rescan_progress' field to 'getinfo' (Antoine Poinsot)
7866ff46cfcf02f75f0d5fd996434ef647940882 commands: add a new 'startrescan' command (Antoine Poinsot)
7e83bfad55504e758e2380ba76e48ce7f868b837 db: the interface to store the state of an ongoing rescan (Antoine Poinsot)
bd4de0b87a0db999ead08de335566df462251ca6 bitcoin: interface for rescanning the chain on the Bitcoin backend (Antoine Poinsot)
c32f714a2ed12135f07a2dd77951b15c3f0fcfe5 bitcoind: add a 'noreply' client (Antoine Poinsot)
45d601282fd4e722ad8558243c4b8c9c1ad11345 bitcoind: only sleep on error if there is >0 retries (Antoine Poinsot)
51ff7d6734db353e0aab65c45d322c45d7e3aa8b bitcoind: a utility to find a block height by block timestamp (Antoine Poinsot)
6323ae0d0fb2726e95a97ceda52b133027297719 bitcoind: add time and MTP to BlockStats (Antoine Poinsot)
80803c78a4579641b604c110e411556588ebdf24 bitcoind: handle missing previousblockhash from getblockheader (Antoine Poinsot)
Pull request description:
This implements the ability for a user to rescan the block chain from an earlier timestamp to find transactions the wallet isn't currently aware of.
The main difficulty arises with the fact there are two rescans to be performed:
1. The block chain rescan on the Bitcoin backend. For the bitcoind implementation this means we need to rescan the bitcoind watchonly wallet down to the given timestamp (or height). We can imagine for an indexer backend such as an Electrum backend it could be almost instant.
2. The update of our state with the new state of the Bitcoin backend. In the poller we scan blocks linearly, we will never scan a block that we already scanned and that includes blocks anterior to the first block we scanned. In order to implement this rescan of past blocks after a Bitcoin backend rescan was performed we reused our current chain reorganization logic: we rewind our state down to the first block that was rescanned by the backend. This is overkill (we don't need to erase existing information), but sufficient for now.
The implementation is not as robust as it could be. Notably, in order to rescan the chain on the bitcoind implementation of the backend i use a trick to not make the connection block for the entire duration of the rescan when calling `importdescriptors`: i introduce a new client that has a timeout of 1 second and that ignores the response as well as timeout errors. Obviously this is problematic since it makes it more complicated to know whether the call actually succeeded.
~~A more robust solution would be to use `rescanblockchain` which starts the rescan without blocking but~~
1. We should be storing a height in the database, not a timestamp
2. The timestamp of the descriptors in the bitcoind watchonly wallet wouldn't be updated
EDIT: i'm dumb, `rescanblockchain` does block too!
I'm happy to have feedback on this. I think the current implementation is fine for now but eventually we should move to using `rescanblockchain` and get rid of the "noreply" client hack.
Also, some functional tests for edge cases we could encounter are included but happy to have some more suggestions.
Fixes#28.
ACKs for top commit:
darosior:
ACK 32f3bdeb16b66878e23ba71a6f2c401c5d1f601a
Tree-SHA512: adca6345329f60d23ed85f0f6abc8f445b10d0c24b5a555a852d0507822598abc7de78742381b1a47b54820f97b037bb4d1ddd0e0b600921ef16c5128ba84950
