I would please like help understanding the new -blocksxor enhancement, mainly from an admin perspective. I did see the following useful info.
Output from bitcoind –help:
-blocksxor
Whether an XOR-key applies to blocksdir *.dat files. The created XOR-key
will be zeros for an existing blocksdir or when `-blocksxor=0` is
set, and random for a freshly initialized blocksdir. (default: 1)
From v28.0 release notes:
Block files are now XOR’d by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key. Refer to the -blocksxor help for more details. (#28052)
Comments for this change are at: Pull Request #28052
Reading further, it sounds like this enhancement compensates for some AV softwares wrongly flagging blockchain storage files. It sounds like this was originally reported against chainstate files (Issue #4069), whereas this new “-blocksxor” remediation deals with erroneous AV flags to the blocks data files themselves.
For the new enhancement, it sounds like a rolling random XOR obfuscation blocks directory which is then used to optionally obfuscate file contents.
My questions I’d please like help with are:
- I didn’t see the “rolling” nature of these keys described? When are the random XOR keys generated, and when do they “roll?” Are new keys created for each block? Does the new -blocksxor key-file contain multiple obfuscation keys, it must?
- Also, how does this help prevent AV softwares from continuing to wrongly flag these data files? Doesn’t randomly XOR(ing) persisted data just “kick the can down the road”? Eventually the same problem may happen. Are there AV-integration tests which prove out this XOR(ing) solution?
