Merge bitcoin/bitcoin#34566: feature: Use different datadirs for different signets
feeb00af8cf361ba9d2f7de0334abf875b3103d9 cli: Add -signetchallenge info on RPC auth error (ekzyis)
c47ea370dc9f7a878e8269884b25204b8e6a3ec6 doc: Update documentation for signet datadir (ekzyis)
6f8c43f9efc601b26ae221e53bb3c354ea64b618 test: Add signet datadir tests (ekzyis)
9b37d42b23be096cc4cfb457f1022e443102b650 Use different datadirs for different signets (ekzyis)
6bdcae3f768b9e8da958ecbf46fa88b42df338f5 refactor: Import signet constant and helper from kernel/signet.h (ekzyis)
Pull request description:
closes #27494
This adds support for syncing multiple signets.
Each custom signet is stored in a different datadir, using the network magic (message start) as the suffix.
The default signet is always stored without a suffix for backward compatibility, even if the default challenge is provided explicitly via `-signetchallenge`.
This builds upon #29838.
For those already familiar with #29838, here are the differences between #29838 and this that are visible to the user:
* The suffix does not use the first 4 bytes of hash160(challenge), but rather the network magic (message start) as mentioned in [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#discussion_r1557976175) and [#34566 (comment)](https://github.com/bitcoin/bitcoin/pull/34566#issuecomment-4207665792).
* If the default challenge is provided to `-signetchallenge`, [#29838](https://github.com/bitcoin/bitcoin/pull/29838) added a suffix to the datadir, whereas this PR does not. This includes backward compatibility when the default signet is used explicitly, not only implicitly, even though [the default signet consensus parameters aren't used in the explicit case](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552).[^1] A test was added for this case.
[^1]: could be something for a follow-up PR, or maybe it's intentional to not mix explicit with implicit options?
Unlike #29838, this PR does not update tests that didn't break (`rpc_bind.py`, `interface_bitcoin_cli.py`). I have found other tests where `datadir_path` is used in combination with `self.chain` (regexp: `datadir_path.*chain`). I considered it inconsistent to update some tests but not all of them. I've decided to not update all of them to keep the scope of this PR low until feedback. I can go through all tests in a follow-up PR to make sure they don't break when they are ever used with (custom) signet, however unlikely that might be.
I have done some manual testing like this:
<details>
<summary>manual testing</summary>
1. 'signet' directory is used, IBD:
```
$ bitcoind -signet
```
2. 'signet' directory is used, no IBD without `-addnode` (see [#29838 (comment)](https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2742830552)) or existing peers.dat:
```
$ bitcoind -signet -signetchallenge=512103ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430210359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c452ae
```
3. 'signet' directory is used
```
$ bitcoind -conf="signet_default.conf"
```
```
# signet_default.conf
signet=1
[signet]
signetchallenge=512103ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430210359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c452ae
```
4. 'signet_f6ac8550' directory is used:
```
$ bitcoind -conf="signet_custom.conf"
```
```
# signet_custom.conf
signet=1
[signet]
signetchallenge=0014d4528367459d54e1545b0d0a677d2a7d71d648e0
```
Tested RPC with `bitcoin-cli getblockchaininfo` with the same options (`-signet`, `-conf`, or `-signet -signetchallenge`)
</details>
I'm new to contributing to Bitcoin Core so it's entirely possible that I've missed something obvious.
ACKs for top commit:
pinheadmz:
ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9
ViniciusCestarii:
Re-ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9
sedited:
ACK feeb00af8cf361ba9d2f7de0334abf875b3103d9
Tree-SHA512: e06e5ad4f967f1c1b2d7cdfe3ad34ff4e09435012668889ea4fd817fec0fda153a3221c28846c06026dd573cbe0eec3872d569ed99614446528c5af890af2bbd M
merge-script committed
d32a515fb0bbe7ce5be723ff37e532a8220bc3ce