He escrito un código para conectarme a la red, recibir inventarios y solicitar datos. Lo que estoy notando es que mi nodo local nunca me envía mensajes de inventario con bloques a menos que solicite bloques específicamente.
Entonces, si hago una llamada getblocks con un hash de parada cero, obtendré todos los bloques hasta la punta, pero nunca ningún mensaje de inventario después de eso. ¿Es necesario algún tipo de señalización para decirle al nodo al que estoy conectado que quiero que me envíen mensajes de bloqueo de inventario cuando se encuentren nuevos bloques?
Me estoy conectando con la versión de protocolo 70002, relaybool es 1, nodeservices es 1.
No veo otras menciones de este problema, así que me pregunto si hay un problema de negociación que no se detecta o algún otro problema.
No hay una puntuación de prohibición visible, la conexión es de localhost, recibo un verack y se transmiten mensajes de inventario de tx normales. Esto sucede independientemente de si se usa -whitelist. Nunca recibo actualizaciones de inventario de bloques o mensajes de bloques no solicitados a menos que solicite bloques a través de getblocks. Después de haber recuperado bloques hasta que no comience la transmisión de sugerencias.
Actualización: el código no tiene problemas para sincronizarse con una instancia de núcleo de bitcoin en otra computadora, pero la instancia de núcleo de bitcoin local nunca enviará inventarios de bloques ni responderá a solicitudes de encabezados. El problema solo ocurre en conexiones iniciadas de localhost a localhost.
Debe emitir un getdata en la última entrada en el invs devuelto. Esto se usa como desencadenante de que ha procesado la respuesta, y el resto se enviará automáticamente.
Tenga en cuenta que desde la versión 0.10, Bitcoin Core ya no usa el ciclo getdata/inv/getdata/block para sincronizar, sino getheaders/headers (para sincronizar encabezados). Luego, los bloques reales se recuperan de forma asíncrona de diferentes pares después de que se descubren los encabezados.
El directorio de bloques de Bitcoind estaba dañado. (0.11.0)
Después de pruebas exhaustivas, resultó que el directorio de bloques de bitcoind estaba corrupto de alguna manera, y aunque todo indicaba que estaba en la punta de la cadena correcta, no estaba sirviendo bloques a los pares sin una solicitud explícita de getblocks. Ignoraría las solicitudes de getheaders y no retransmitiría los inventarios de bloques. Una resincronización completa resolvió el problema.
La clave fue darse cuenta de que el mismo código podía conectarse a nodos externos sin problemas, y que durante los volcados de wireshark, el nodo local nunca transmitía bloques a la red.
Matty B
Matty B