Laut der Bitcoin-Core-Entwicklerreferenz hat der RPC-Aufruf getPeerInfo in seiner Ausgabe ein Feld namens „addrlocal“, das unsere IP aus der Weltsicht des Peers enthält.
Warum gibt es diese Ausgabe? Wird es irgendwo verwendet? Hat es einen Anwendungsfall?
Außerdem kommentierten sie, dass „die meisten SPV-Knoten dies auf 127.0.0.1:8333 setzen“, warum sollte ein SPV-Knoten das tun?
Warum gibt es diese Ausgabe?
Weil es Teil der versionP2P-Nachricht ist. getpeerinfogibt weitgehend die von der versionNachricht bereitgestellten Informationen aus.
Wird es irgendwo verwendet? Hat es einen Anwendungsfall?
Zurzeit nicht. Es könnte jedoch in der versionNachricht enthalten gewesen sein, weil Bitcoin ursprünglich dafür entwickelt wurde, Dinge direkt an IP-Adressen zu senden. Früher gab es eine Pay-to-IP-Sache, wo dies nützlich gewesen sein könnte.
Außerdem kommentierten sie, dass „die meisten SPV-Knoten dies auf 127.0.0.1:8333 setzen“, warum sollte ein SPV-Knoten das tun?
Weil es einfacher zu implementieren ist und niemand es tatsächlich verwendet.
Warum gibt es diese Ausgabe?
Es wird von seinen Peers in ihren versionP2P-Nachrichten an den Bitcoin-Knoten gesendet.
Wird es irgendwo verwendet? Hat es einen Anwendungsfall?
Ja. In erster Linie wird es im P2P-Netzwerk von Bitcoin verwendet. Wenn ein Knoten eingehende Bitcoin-Netzwerkverbindungen über das Internet akzeptieren möchte, aber seine eigene IP-Adresse im Internet nicht kennt, kann er die addrLocalvon einem ausgehenden Peer gemeldeten Informationen verwenden, um herauszufinden, von welcher IP-Adresse der ausgehende Peer die Verbindung dieses Knotens kommen sieht. Wenn sich diese IP-Adresse innerhalb gültiger Internetbereiche befindet, kann dieser Knoten diese IP dann für zukünftige eingehende Verbindungen ankündigen. In Bitcoin Core wird dieses Erkennungsverhalten aktiviert oder deaktiviert, indem die -discoverOption bitcoind oder bitcoin-qt bereitgestellt wird.
addrLocalkann auch von Anwendungen verwendet werden, die die Informationen über das von Ihnen erwähnte getPeerInfo-RPC-Verfahren erhalten. Wenn eine Anwendung ihre eigenen Entscheidungen darüber treffen möchte, welche IP-Adresse für einen Knoten, beispielsweise für eine Website, beworben werden soll, kann sie diese von Peers bereitgestellten Daten in ihre Entscheidung einbeziehen. Eine Anwendung möchte möglicherweise auch bestimmen, wie ein Peer mit einem Knoten verbunden ist, wenn dieser Knoten mehrere Verbindungsrouten für Peers anbietet (z. B. über NAT, Reverse-Proxys, Forward-Proxys, Tunnel, Anonymisierer usw.)
Außerdem kommentierten sie, dass „die meisten SPV-Knoten dies auf 127.0.0.1:8333 setzen“, warum sollte ein SPV-Knoten das tun?
Entweder, weil der SPV-Knoten tatsächlich ausgeführt wird und lokal verbunden ist, oder weil der SPV-Knoten gelogen hat. Ein Anwendungsfall für jede Art von Knoten könnte darin bestehen, dass der Entwickler einen Platzhalterwert belässt, während er die Anforderungen des Netzwerkprotokolls noch nicht vollständig implementiert hat, oder wenn der verbindende Knoten verschleiern möchte, welche Route er genommen hat, um sich wann mit diesem Knoten zu verbinden Es stehen mehrere Optionen zur Verfügung.
Die Formulierung „die meisten SPV-Knoten“ wurde weitgehend aus der Dokumentation entfernt.