La información del error también puede presentar el problema de que «la primera parte proviene de un error antiguo y la segunda, de uno nuevo». Bitcoin Core Draft #36792 quiere aclarar dos rutas de validación: al detectar un bloque posiblemente dañado, primero registra la información original de Invalid y luego la sustituye por un error explícito de corrupción; si al actualizar el disco ya se ha producido un error fatal, conserva el error original en adelante y evita notificarlo repetidamente. A mi juicio, la calidad del diagnóstico depende de que el error señale el mismo fallo; conservar más texto no siempre aporta más claridad. El texto original también indica que para probar uno de los fallos de disco hace falta inyectar un fallo. Se trata de un ajuste del manejo de errores del cliente $BTC que está pendiente de revisión, no de una constatación de que el dispositivo de un usuario esté dañado.