Bitcoin ABC, cuando Fed Bitcoin Core Chain se sincroniza con el 1 de agosto a las 6:23 a.m. de 2017, luego se congela

Instalé Bitcoin ABC, configuré bitcoin.conf para que apunte a una copia de mi directorio de Bitcoin Core y dejé que se sincronice con la red. Todo iba bien hasta que se congeló en la bifurcación (1 de agosto de 2017, 6:23 a. m.). El cliente responde, pero mi progreso no se mueve y el "Tiempo restante estimado hasta la sincronización" permanece en "calculando..." Al principio pensé que tenía algún tipo de error de red, pero ese no parece ser el caso. Tengo 8 conexiones activas. ¿Por qué no se moverá más allá de este punto, descargando las transacciones posteriores a la bifurcación?

Bitcoin ABC, v0.16.2.0-unk en Ubuntu 17.10 (Mate).

¿Qué quiere decir con "alimentarlo con mi cadena de Bitcoin Core"? ¿Copiaste la carpeta de bloques de Bitcoin Core? ¿O copiaste todo el directorio de datos? ¿O lo está conectando solo a una instancia de Bitcoin Core? De cualquier manera, ese momento es el momento de la bifurcación, por lo que los bloques de Bitcoin ya no serán válidos para Bitcoin ABC y deberán sincronizarse fuera de la red de Bitcoin Cash.
Copié todo el directorio, excepto que le di una billetera vacía, que luego conecté solo a una instancia de Bitcoin ABC que se ejecutaba en otra máquina. Mi pregunta es por qué no continúa después de la bifurcación, sincronizándose fuera de la red Bitcoin Cash.

Respuestas (1)

También copió todo el estado de la cadena, lo que confundirá al nodo y hará que no pueda continuar con la sincronización porque el estado de la cadena dice que la cadena Bitcoin Cash no es válida y las cosas del nodo que la cadena está usando actualmente tampoco lo son. Puede solucionar esto eliminando el estado de cadena, en cuyo caso comenzará a reindexarse.

Sin embargo, es posible que esto no solucione todos sus problemas porque la cadena de Bitcoin todavía está en el disco y aún indexará y verificará eso. Por lo tanto, es posible que deba eliminar algunos de los archivos blk*.dat y rev*.dat (los de mayor número) para que vuelva a un estado anterior a la bifurcación y luego sincronice Bitcoin Cash desde ese punto en adelante.


Los detalles son que copiamos el .bitcoindirectorio, pero eliminamos el .bitcoin/chainstatedirectorio. Si ejecuta el cliente ahora, se congelará nuevamente cuando llegue a los blk*.datarchivos que están más allá de la bifurcación. Al ejecutarlo mientras también se ejecuta:

watch -n 1 'sudo lsof -c bitcoin | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | sed -E "s/^.+$/& `date`/" | tee -a recent.blk'

y

watch tail recent.blk,

Pude encontrar que los archivos que deben eliminarse son .bitcoin/blocks/{blk,rev}00953.daty superiores. Es decir, mantenga 00000 a 00952. Luego, cuando volví a ejecutar el cliente, funcionó. Después de la bifurcación, se sincronizó con la red. Puede ahorrarse ejecutarlo dos veces simplemente eliminando el directorio chainstate/ y los archivos relevantes en bloques/. Cuando ejecute el cliente, dirá: "Error al cargar la base de datos de bloques, ¿desea reconstruir ahora?" Responda "Sí", y luego dirá "Reindexando los bloques en el disco", seguido de "Sincronizando los encabezados (478436)". Ese último número es el número de bloques hasta blk00000.dat, blk00952.daty justo precede a la bifurcación en 478558.

Entonces, mi primer paso es eliminar el directorio "chainstate", ¿correcto? Entonces, si tengo que hacerlo, ¿cómo puedo saber cuántos archivos blk/rev eliminar del final? El objetivo de este ejercicio era evitar volver a descargar toda la cadena de bloques.
Eliminé "chainstate" y está sincronizando encabezados nuevamente, desde el principio. Va a tomar algún tiempo.
Sí, primero elimine el directorio chainstate. Para los archivos blk*.dat y rev*.dat, mire los tamaños de los archivos blk*.dat con el número más alto. Divida ese tamaño por 1 MB. Eso le dice al menos cuántos bloques hay en ese archivo. Luego elimine los archivos comenzando desde el número más alto hasta que haya pasado la cantidad de bloques desde el punto de bifurcación. Elimine la misma cantidad de archivos rev*.dat.
Bueno, gracias. Hay un directorio llamado "índice" en el directorio "bloques". ¿Tendré que hacer algo con eso?
No. Cuando elimine los archivos, deberá volver a indexarlos y esa carpeta se borrará y se reescribirá.
Mientras vuelvo a sincronizar después de haber eliminado el directorio chainstate, estoy ejecutando watch -n 20 'sudo lsof | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | tee -a recent.blk'De esa manera, obtengo una lista de archivos de bloque y rev que se han abierto, enumerados en recent.blk, y puedo ver cuál se abrió en último lugar. Cuando esto esté hecho, y si es necesario, lo eliminaré de ahí en adelante.
Además del directorio chainstate, tuve que eliminar los archivos blocks/{blk,dev}*.dat desde el #00953 en adelante (así que siga hasta el #00952). Después de reindexar, ahora está sincronizando encabezados por tercera vez, y este parece ser el más lento de los tres. Tomará días. Y solo asumo que esta vez progresará más allá de la bifurcación. Realmente creo que debería haber hecho DL'd toda la cadena de bloques nuevamente, desde el principio.