Daniela Brozzoni

At the moment even in a no-cosigs deployment once you use some inputs for a spend that it's unvaulting, you can't use them for another spend

Either properly test or deny deployments with an high CSV

1

At the moment we aren't testing spends with an higher CSV because calling `generatetoaddress` with a too high number of blocks causes: ``` > rn.spend_vaults_anyhow([vaultA, vaultB]) test_misc.py:403: _ _ _...

See https://github.com/revault/revaultd/pull/218#discussion_r653979415

Handle user sending to CPFP/deposit addresses at spend creation

1

#### If the user decides to send funds to the same address as the change, we should merge the two outputs Example: Vault is 10 BTC User wants to send...

Servers will be a hidden server, which means that there's no "last hop" that can see/manipulate our messages, and tor is already encrypted. This would also greatly improve the ceremony/installer...

The error should include more details, so in the installer it's easier to understand what's going wrong See https://github.com/revault/revault-gui/pull/123#discussion_r656177099

Check if it's possible to import a spend without the CPFP output

1

Opening this issue as a reminder, I should double-check that importing a spend without the cpfp output is not possible

This PR still needs: - [x] tests - [ ] `ChainGraph::::from_block(block)` (I might just open a different PR as I suppose it's an easier one to implement and might get...

`wallet_esplora_async` returns error 429 while scanning

13

**Describe the bug** Running `wallet_esplora_async` we panic due to `blockstream.info` replying with error code 429 to us (too many requests) **To Reproduce** `cargo run` in `bdk/example-crates/wallet_esplora_async` produces the following: ```...