Der Bitcoin-Kern v0.14.0scheint viel schneller zu sein als frühere Versionen, bis zu dem Punkt, an dem die Synchronisierung der gesamten Blockchain jetzt eher IO-gebunden als CPU-gebunden zu sein scheint: Beim Ausführen topsah ich früher, dass meine CPU mit voller Kapazität lief (was darauf hinweist, dass Netzwerk-IO war nicht der limitierende Faktor). Dies ist anscheinend nicht mehr der Fall, und die Geschwindigkeit der Netzwerk-IO scheint ein relevanter Faktor für die Zeit zu sein, die zum Synchronisieren einer vollständigen Blockchain benötigt wird ...
Jetzt müssen wir immer neue Hardware einrichten oder ein neues Betriebssystem ausprobieren, und ausnahmslos befinden wir uns in der Position des Erstellens und Installierens, bitcoindgefolgt von einer Blockchain-Synchronisierung. Jetzt, da die Netzwerkgeschwindigkeit wichtig ist, wäre es sehr sinnvoll, die Blockchain-Daten von einem anderen vollständigen Knoten zu beziehen, den wir zufällig im selben LAN betreiben, anstatt die Daten extern von einer zufälligen Peer-Verbindung abzurufen. Also meine Frage ist:
Angenommen, ich habe einen anderen vollständigen Knoten, der im selben LAN läuft, wie richte ich die Konfigurationsdatei des neuen Knotens ein, um sicherzustellen, dass er eine Verbindung zu diesem lokalen Knoten herstellt, um von der erhöhten Netzwerkgeschwindigkeit zu profitieren? (Diese Frage setzt voraus, dass beide Knoten IPv4 sind). Wie ändere ich diese Einstellungen, wenn der laufende vollständige Knoten auf Tor ist, während der neue Knoten IPv4 ist, oder wenn der laufende Knoten IPv4 ist und der neue Knoten auf Tor ist?
BEARBEITEN: Nach den Vorschlägen aus dem Kommentar habe ich versucht, die Zeile hinzuzufügen:
addnode=192.168.0.2:8333
in der Konfigurationsdatei des neuen (ipv4)-Knotens, wobei 192.168.0.2die lokale IP des eingerichteten (Tor)-Knotens ist. Meine Tor-Knoten-Konfigurationsdatei lautet wie folgt:
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
Ich habe auch sichergestellt, dass meine Firewall auf dem Tornode-Server richtig eingerichtet ist
$ sudo ufw allow 8333
Mein Tor-Knoten lehnt jedoch die Verbindungsanfrage ab, wie aus dem Debug des neuen Knotens ersichtlich ist:
2017-03-31 13:21:50 connect() to 192.168.0.2:8333 failed after select(): Connection refused (111)
Ok, verstanden, es scheint, dass Sie die Zeile bind=127.0.0.1:8333aus der Konfigurationsdatei entfernen müssen, und (überraschenderweise) können Sie die Einstellung onlynet=onionbeibehalten (Sie können immer noch eine Verbindung über IPv4 im LAN herstellen). Der vorhandene Tor-Knoten kann also wie folgt konfiguriert werden:
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
und der neue lokale IPv4-Knoten kann wie folgt konfiguriert werden:
txindex=1
debug=mempool
daemon=1
connect=192.168.0.xxx:8333
Mit diesen Einstellungen funktioniert der Tor-Knoten wie gewohnt nur mit Tor-Verbindungen (eingehend und ausgehend), mit Ausnahme der lokalen IPv4-Verbindung vom neuen Knoten.
杜興怡
Pieter Wuille
Sven Williams