I might please like assist understanding the brand new -blocksxor enhancement, primarily from an admin perspective. I did see the next helpful information.
Output from bitcoind –help:
-blocksxor
Whether or not an XOR-key applies to blocksdir *.dat information. The created XOR-key
shall be zeros for an current blocksdir or when `-blocksxor=0` is
set, and random for a freshly initialized blocksdir. (default: 1)
From v28.0 launch notes:
Block information are actually XOR’d by default with a key saved within the blocksdir. Earlier releases of Bitcoin Core or earlier exterior software program will be unable to learn the blocksdir with a non-zero XOR-key. Confer with the -blocksxor assist for extra particulars. (#28052)
Feedback for this alteration are at: Pull Request #28052
Studying additional, it seems like this enhancement compensates for some AV softwares wrongly flagging blockchain storage information. It seems like this was initially reported towards chainstate information (Subject #4069), whereas this new “-blocksxor” remediation offers with misguided AV flags to the blocks knowledge information themselves.
For the brand new enhancement, it seems like a rolling random XOR obfuscation blocks listing which is then used to optionally obfuscate file contents.
My questions I might please like assist with are:
- I did not see the “rolling” nature of those keys described? When are the random XOR keys generated, and when do they “roll?” Are new keys created for every block? Does the brand new -blocksxor key-file include a number of obfuscation keys, it should?
- Additionally, how does this assist stop AV softwares from persevering with to wrongly flag these knowledge information? Does not randomly XOR(ing) endured knowledge simply “kick the can down the highway”? Finally the identical drawback could occur. Are there AV-integration checks which show out this XOR(ing) answer?
