Regtest automatisierte Peer-Erkennung

Ich möchte die Peer-Erkennung im Regtest-Modus des Bitcoin-Kerns testen, der in Docker ausgeführt wird. Ich habe jedoch im Quellcode von Bitcoin Core festgestellt, dass vor dem Antworten auf eine getaddr-Nachricht überprüft wird, ob die Adresse routbar ist. Also erstelle ich zuerst ein Netzwerk mit routingfähigen Adressen (IsRFC6598):

docker network create -d bridge --subnet 100.64.0.0/10 bridge_sharedrange

Dann starte ich vier Docker-Maschinen mit installiertem Bitcoin (und unter Verwendung des Netzwerks bridge_sharedrange mit unterschiedlichen /16-Adressen). Der Bitcoin-Daemon wird dann in allen diesen vier Maschinen gestartet mit:

bitcoind -regtest -daemon

Das Ausführen von ifconfig auf diesen Knoten zeigt, dass sie auf 100.64.0.2, 100.65.0.2, 100.66.0.2, 100.67.0.2 ausgeführt werden. Von der ersten Maschine (100.64.0.2) führe ich dann den Befehl aus:

bitcoin-cli addnode 100.65.0.2 add

Von der dritten Maschine (100.66.0.2) führe ich dann den Befehl aus:

bitcoin-cli addnode 100.65.0.2 add

Im Grunde genommen hat der Knoten mit der Adresse 100.65.0.2 jetzt zwei Peers (überprüft mit bitcoin-cli getpeerinfo). Das würde ich jetzt erwarten

  • 100.64.0.2 hat von 100.66.0.2 erfahren &
  • 100.66.0.2 hat von 100.64.0.2 erfahren

Aber das ist nicht der Fall. Sie kennen nur 100.65.0.2. Ist das normales Verhalten? Ich habe auf https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#Command_Line_Provided_Addresses gelesen, dass es möglicherweise mit dem Zeitstempel der Adresse zu tun hat, aber ich bin mir nicht sicher, ob dies die Ursache sein kann und wie das umgangen werden kann.

Übrigens habe ich auch mit getestet

bitcoind -regtest -daemon -discover=1

Update : Es scheint, dass diese Funktion zum Erkennen lokaler LAN-Knoten diskutiert wird: https://github.com/bitcoin/bitcoin/issues/3802 , aber ich würde denken, dass die WAN-Regeln für meine Situation gelten, da ich RFC6598-Adressen verwende mein Testaufbau.

Antworten (1)

Bitcoin Core sendet nicht sofort addrmit jeder neuen Verbindung, die es erhält, eine neue Nachricht an die Knoten. Im Durchschnitt erfolgen diese Sendungen alle 30 Sekunden, aber sie könnten früher oder später erfolgen, da die Verzögerung einer Poisson-Verteilung folgt. Sie sollten einige Minuten warten, bevor Sie es erneut überprüfen. Nur weil sie die Adresse kennen, heißt das nicht, dass sich die Knoten tatsächlich mit ihnen verbinden werden.

Welche Überprüfungen führt ein Knoten durch, um sich für die Verbindung mit einem anderen Knoten zu entscheiden, oder ist dies völlig zufällig? Ich denke, es hat sowohl mit dem Schutz vor dem Sybil-Angriff ( en.bitcoin.it/wiki/Weaknesses ) als auch mit der Tatsache zu tun , dass nicht alle Adressen einen gültigen Zeitstempel haben ( en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery ) . Ich habe jedoch versucht, den Knoten eine andere /16-Adresse zu geben, und das Problem bleibt bestehen (auch nach 30 Minuten Wartezeit).
Die Nodes werden zufällig ausgewählt und dürfen die hier geprüften Bedingungen nicht erfüllen: github.com/bitcoin/bitcoin/blob/master/src/addrman.cpp#L33
Interessant, das führte mich zu Informationen über den Eclipse-Angriff. medium.com/mit-security-seminar/… und eprint.iacr.org/2015/263.pdf bieten weitere Einzelheiten. Es scheint, dass es doch nicht so einfach ist, die Peer-Erkennung zu testen.
Regtest automatisierte Peer-Erkennung
AntwortenHierDatenschutz-Bestimmungen1y, 0v