Me gustaría que me ayudaran a entender la nueva -bloquesxor mejora, principalmente desde una perspectiva administrativa. Vi la siguiente información útil.
Salida de bitcoind –ayuda:
-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)
De las notas de la versión v28.0:
Los archivos de bloque ahora reciben XOR de forma predeterminada con una clave almacenada en el directorio de bloques. Las versiones anteriores de Bitcoin Core o el software program externo anterior no podrán leer el directorio de bloques con una clave XOR distinta de cero. Consulte la ayuda de -blocksxor para obtener más detalles. (#28052)
Los comentarios para este cambio están en: Solicitud de extracción n.° 28052
Siguiendo leyendo, parece que esta mejora compensa el hecho de que algunos softwares antivirus marquen erróneamente los archivos de almacenamiento de blockchain. Parece que esto se informó originalmente en archivos chainstate (Número 4069), mientras que esta nueva solución “-blocksxor” se ocupa de indicadores AV erróneos en los propios archivos de datos de los bloques. Para la nueva mejora, suena como un directorio de bloques de ofuscación XOR aleatorio y continuo que luego se usa para ofuscar opcionalmente el contenido del archivo.
Mis preguntas con las que me gustaría recibir ayuda son:
- ¿No vi descrita la naturaleza “rodante” de estas teclas? ¿Cuándo se generan las claves XOR aleatorias y cuándo “ruedan”? ¿Se crean nuevas claves para cada bloque? ¿El nuevo archivo de claves -blocksxor contiene múltiples claves de ofuscación?
- Además, ¿cómo ayuda esto a evitar que los softwares AV sigan marcando erróneamente estos archivos de datos? ¿No es el XOR(ing) aleatorio de datos persistentes simplemente “patear la lata en el camino”? Al ultimate puede ocurrir el mismo problema. ¿Existen pruebas de integración AV que demuestren esta solución XOR(ing)?
