Conexión de nodos completos dentro de una LAN para acelerar la sincronización de blockchain

El núcleo de Bitcoin v0.14.0parece ser mucho más rápido que las versiones anteriores, hasta el punto en que la sincronización de la cadena de bloques completa ahora parece estar vinculada a E/S en lugar de a la CPU: cuando ejecutaba top, solía ver mi CPU funcionando a plena capacidad (lo que indica que la E/S de la red no fue el factor limitante). Parece que este ya no es el caso, y la velocidad de la red IO parece ser un factor relevante en el tiempo que lleva sincronizar una cadena de bloques completa...

Ahora siempre tenemos hardware nuevo para configurar, o algún sistema operativo nuevo para probar e invariablemente nos encontramos en la posición de construir e instalar bitcoindseguido de una sincronización de cadena de bloques. Ahora que la velocidad de la red es importante, tendría mucho sentido intentar obtener los datos de la cadena de bloques de otro nodo completo que estemos ejecutando en la misma LAN, en lugar de obtener los datos externamente desde una conexión de pares aleatoria. Entonces mi pregunta es:

Suponiendo que tengo otro nodo completo ejecutándose en la misma LAN, ¿cómo configuro el archivo de configuración del nuevo nodo para asegurarme de que se conecta a este nodo local para beneficiarme de la mayor velocidad de la red? (Esta pregunta suponiendo que ambos nodos son IPv4). ¿Cómo cambio esta configuración si el nodo completo en ejecución está en Tor mientras que el nuevo nodo es IPv4, o cuando el nodo en ejecución es IPv4 y el nuevo nodo está en Tor?

EDITAR: siguiendo las sugerencias del comentario, he intentado agregar la línea:

addnode=192.168.0.2:8333

en el archivo de configuración del nuevo nodo (ipv4) donde 192.168.0.2está la ip local del nodo establecido (tor). Mi archivo de configuración de nodo tor es el siguiente:

txindex=1
debug=mempool
daemon=1
#onlynet=onion # commented out to allow local ipv4 connection
onion=127.0.0.1:9050
port=8333
listen=1
bind=127.0.0.1:8333
externalip=<myexternaltoraddress>.onion
seednode=<seed1>.onion
...
banscore=10000
bantime=11

También me aseguré de que mi firewall en el servidor del nodo tor esté configurado correctamente

$ sudo ufw allow 8333

Sin embargo, mi nodo tor rechaza la solicitud de conexión, como se puede ver en la depuración del nuevo nodo:

2017-03-31 13:21:50 connect() to 192.168.0.2:8333 failed after select(): Connection refused (111)
El cli arg 'conectar' (alternativa a addnode) parece posible para esta situación? descrito en dot-conf aquí en.bitcoin.it/wiki/…
@sven Si ha encontrado una respuesta aceptable usted mismo, debe publicarla como respuesta, no editarla en su pregunta. En este punto, no está claro lo que todavía estás pidiendo.
@pieter gracias ha modificado en consecuencia.

Respuestas (1)

Ok, lo tengo, parece que necesita eliminar la línea bind=127.0.0.1:8333del archivo de configuración y (sorprendentemente) puede mantener la configuración onlynet=onion(todavía puede conectarse a través de ipv4 en la LAN). Entonces, el nodo Tor existente se puede configurar de la siguiente manera:

txindex=1
debug=mempool
daemon=1
onlynet=onion
onion=127.0.0.1:9050
port=8333
listen=1
externalip=<myexternaltoraddress>.onion
seednode=<seed1>.onion
[...]
seednode=<seedk>.onion
banscore=10000
bantime=11

y el nuevo nodo ipv4 local se puede configurar de la siguiente manera:

txindex=1
debug=mempool
daemon=1
connect=192.168.0.xxx:8333

Con esta configuración, el nodo Tor funciona normalmente con conexiones Tor solamente (entrantes y salientes) con la excepción de la conexión ipv4 local del nuevo nodo.

bind= controla las conexiones entrantes. Si se vincula a localhost, solo puede aceptar conexiones entrantes. onlynet= controla la selección de conexiones salientes.
@pieter, gracias, experimentaré nuevamente a la luz del comentario.