test: add `rescan utxos` inside MiniWallet's initialization #26886

When a pre-mined blockchain is used (default behavior), it contains coinbase outputs in blocks 76-10 to the MiniWallet's default address. That's why we always* rescan_utxos() after initializing the MiniWallet, in order for the MiniWallet to account for those mature UTXOs.

The tests following this usage pattern can be seen with: git grep -n "MiniWallet(" $(git grep -le "rescan_utxos()" $(git grep -Le "self.setup_clean_chain = True"))

This PR adds rescan_utxos() inside MiniWallet's initialization to simplify usage when the MiniWallet is used with a pre-mined chain.

secondary changes

• *There are a few tests that use the pre-mined blockchain but do not rescan_utxos(), they instead generate new blocks to create mature UTXOs.

  Those were written before the rescan_utxos() method was introduced with #22955 (fac66d0a39cb0b4bc565b57087ba84dd932e9b6d) and can be seen with: git grep -n "MiniWallet(" $(git grep -Le "rescan_utxos()" $(git grep -Le "self.setup_clean_chain = True"))

  After including rescan_utxos() inside MiniWallets initilization, this blocks generation logic is not needed as the MiniWallet already accounts for enough mature UTXOs to perform the tests. Therefore the now redundant blocks generation logic is removed from those tests with the second commit.

• The rest of the MiniWallet tests use a clean chain (self.setup_clean_chain = True) and can be seen with git grep -n "MiniWallet(" $(git grep -le "self.setup_clean_chain = True")

  From those, there are a few that start from a clean chain and then create enough mature UTXOs for the MiniWallet with this kind of logic: https://github.com/bitcoin/bitcoin/blob/07c54de550035c3441f34ef6c34209666267eb38/test/functional/mempool_expiry.py#L36-L40

  Those tests are simplified in the third commit to instead utilize the mature UTXOs of the pre-mined chain.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

Concept ACK

Nice idea, seems reasonable to automatically scan for relevant UTXOs on MiniWallet creation if that's what we need to do most of the times anyways. I was thinking if it's worth it to add an option to the constructor to prevent that (so that users could e.g. pass rescan=False), but on the other hand a single additional scantxoutset RPC should never be problematic at all, especially since the UTXO set would be likely empty in those cases anyways. Will do a detailled review tomorrow.

I was thinking if it's worth it to add an option to the constructor to prevent that (so that users could e.g. pass rescan=False), but on the other hand a single additional scantxoutset RPC should never be problematic at all, especially since the UTXO set would be likely empty in those cases anyways.

Yes, the UTXO set will be empty in those cases (when a clean chain is used) as at all times (except this one) the MiniWallet is initialized at the start of the test.

Also, just a note that since #25445(fa13375aa3fcb4fd5b9e0d4c69ac31cf66c3209a) there is an additional scantxoutset RPC every time the MiniWallet is involved in block generation.

Needs rebase after ac4c79a2678670300e07b0556d34848a56f7b7c1 ?

Rebased after ac4c79a2678670300e07b0556d34848a56f7b7c1 and force-pushed to also remove the now redundant rescan_utxos() call from p2p_permissions.py

Rebased after d6fc1d6a3393c571a1691a6bda60433216643616 and forced-pushed to remove the now redundant rescan_utxos() call from mempool_dust.py

ACK cc50ef82646699f0be0e65dbd8b3a23aed57111b 🧹

Nice cleanup!

Needs rebase cc50ef82646699f0be0e65dbd8b3a23aed57111b 🚦

<details><summary>Show signature</summary>

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Needs rebase cc50ef82646699f0be0e65dbd8b3a23aed57111b 🚦
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUhk3wwAhDET3giO6sF+pFhfgZqbhyFKg2pK94RnqQvuXyu9iczaa0z82zXXe7O+
kJu06aVtKFmeZNp3iIR9821WFKSUQoHuYCEZXGKISppm2MRZ89wttPpKy1OdHxJ0
yEBpH8M+yMveucqMZ+20VgCTk7wvlJjUQsqADCYIUEdPsO6rdVXnudIKDVI5DRb9
5Az3/hJwTWyzXnKbu4CeKq4jCu5DbLFJtCWJb5hhgnnzAfhDdViGksQqzGhIn7jX
MrAMMHQbwkRYB08HdzvLpbEYbCwRFOZGYu4umt/wiBq18qsnfCQ3lsBOA/vlzljn
Ua/x3ChsoEFwvvKO72fQSYhRgS5Zj7b+HfXqhd8AWdMrKYaJKD1h6Aqb83z4xj8O
+aTwA/y2Mid4PWr47hU1VjWIhsp0rV6HizKpzLCxFPDOCfXCzczsxv0ZLBYseQfJ
NZ+SbQDsEHxG/efOApfRP+6LcS4pMtQZ3YFcoFaY++ajBmVNBmQ5ROhm4DRj/Md7
CC5I4huv
=Pv5e
-----END PGP SIGNATURE-----

</details>

Rebased to resolve merge conflicts after d0a909ae54a34ecd925c9d5064d530eaeeba46eb and forced-pushed to remove the now redundant blocks generation logic from feature_bip68_sequence.py

re-ACK 6bd098a838881ba615c01354560a70d47256f90f

ACK 6bd098a838881ba615c01354560a70d47256f90f 🕷

<details><summary>Show signature</summary>

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK 6bd098a838881ba615c01354560a70d47256f90f 🕷
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUjqPQv/Xd3MSOVVkpxX3BF+OrK9/+cR9DruoNxpuJX3cVh18y1/zWbO7qV9yaMk
y3+SD4oFhKjuaXLNWTSpcKciaT+PdgzDv7RO4bTRLg8KSlR8FMLlEn+R7jL8yDZt
WhwdGjhGIvGojmCoW3ZOMFY5ciZlYVfs+bA5gYz/pqpioeBLfoTxM9dti9hSio5a
klGpTo6EesPqLPtu5Ta+pkTmbGSSnk5QFmddOC9bl55s+QDHxhb5gaHxnDrvXPjK
dUfE/bosKhdLZIGPw08K+oKU5xhr53tG1p2utt3twonRgCEBoJjfXYe1wr1Eh+3w
DXw9A6qwD1542Q914gc+yWWGGHxeWI8vmgmOhoNUZ0lv2gsIa1JSgFFKDMAIKArH
ddPjm71z4vE6BzRlNxossjqCCeGemJ4Whyp6otmbTQkbRlluFXBHEXVDLP7akutT
E//aqnRldtuKmxIQoZiHHCh4ZEepeJYomh+5lH9xUSon6zHUKKiFQ0+9HTlPhG1X
dvXbrAxL
=qLqj
-----END PGP SIGNATURE-----

</details>