The recently introduced scanblocks RPC uses BIP157 block filters for quickly determining which blocks contain a specified set of output scripts. By nature this can lead to false-positive results, i.e. the filter set matches the block filter even though none of the contained txs spend or create UTXOs with the specified set of scriptPubKeys.
Can be reproduced on testnet with address tb1qcxf2gv93c26s6mqz7y6etpqdf70zmn67dualgr :
$ ./src/bitcoin-cli -testnet scanblocks start '["addr(tb1qcxf2gv93c26s6mqz7y6etpqdf70zmn67dualgr)"]'
{
"from_height": 0,
"to_height": 2375004,
"relevant_blocks": [
"000000000001bc35077dec4104e0ab1f667ae27059bd907f9a8fac55c802ae36",
"00000000000120a9c50542d73248fb7c37640c252850f0cf273134ad9febaf61",
"0000000000000082f7af3835da8b6146b0bfb243b8842f09c495fa1e74d454ed",
"0000000000000094c32651728193bfbe91f6789683b8d6ac6ae2d22ebd3cb5d3"
],
"completed": true
}
Looking closer at the first returned block 000000000001bc35077dec4104e0ab1f667ae27059bd907f9a8fac55c802ae36 (https://mempool.space/de/testnet/address/tb1qcxf2gv93c26s6mqz7y6etpqdf70zmn67dualgr), one can see that the contained single (coinbase) transaction is not related to the passed address:
$ ./src/bitcoin-cli -testnet getblock 000000000001bc35077dec4104e0ab1f667ae27059bd907f9a8fac55c802ae36 3
...
"vout": [
{
"value": 12.50000000,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 ad0050c5a24b9496e34e34410f35c735f66584ca OP_EQUALVERIFY OP_CHECKSIG",
"desc": "addr(mwHhaAQuafCYjJocy6qEzRg6sBLT6KCdaB)#shkcfhzk",
"hex": "76a914ad0050c5a24b9496e34e34410f35c735f66584ca88ac",
"address": "mwHhaAQuafCYjJocy6qEzRg6sBLT6KCdaB",
"type": "pubkeyhash"
}
}
],
...
It might make sense to introduce an option that actives a second pass phase in which the found blocks are inspected in order to filter out these false-positives.
I guess it is debatable if this can really be considered a bug (in practice it shouldn't be a problem), but at the very least we should mention the possibility of false-positives in the RPC help to not confuse users.
