3ce9d4f7ab
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