Bitcoin-Kommunikation mit nicht standardmäßigen Ports

Ich schreibe eine Bitcoin-Webanwendung, die auf einem externen Server bereitgestellt werden soll, über den ich keine Kontrolle habe. Ich werde wahrscheinlich keinen Zugriff auf den Standard-Bitcoin-Port (8333) haben. Wird dies ein Problem verursachen, wenn Sie sich mit Standard-Bitcoin-Clients verbinden, oder können sie die Kommunikation mit einer nicht standardmäßigen Portnummer handhaben? Gibt es Bitcoin-bezogene Anwendungen, die auch andere Ports zur Kommunikation verwenden (wie einen Pool oder ähnliches)?

Auf welche Weise(n) muss die Web-App mit dem Bitcoin-Netzwerk interagieren? Wird der Bitcoin-Client auf dem Computer ausgeführt, auf dem die Web-App ausgeführt wird?
Ich beabsichtige, meinen eigenen Bitcoin-Client für die Web-App zu schreiben, also hoffe ich, vollständig mit dem Bitcoin-Netzwerk interagieren zu können. Alternativ möchte ich vielleicht nur einen Pool in der Web-App ausführen. Es gibt also kein Problem mit der Client-Anpassung, solange das Netzwerk auch damit umgehen kann.

Antworten (3)

Wenn Sie nur ausgehende Verbindungen herstellen, spielt es keine Rolle, welche Ports Sie verwenden. Ihr Kunde kann ohne Probleme vollständig am Netzwerk teilnehmen.

Wenn also meine App eine Verbindung mit einem anderen Client herstellen kann, der angibt, dass meine Adresse Port :80 hat, erhält sie eine Antwort auf Port :80?
Wenn Sie sich mit einem Client verbinden, erhalten Sie Antworten auf die Verbindung, die Sie gerade mit diesem Client hergestellt haben. Das Bitcoin-Netzwerk verwendet dauerhafte TCP-Verbindungen, die aktiv bleiben, solange beide Knoten weiterlaufen.
Übrigens, ich denke, Sie haben ein unnötiges "und" verwendet. Kann deinen Beitrag nicht editieren, da ich mindestens 6 Zeichen ändern müsste ;).
Vielen Dank. Ich habe die Struktur dieses Satzes geändert, nachdem ich ihn geschrieben hatte, und die Änderung nicht abgeschlossen.

Knoten im Netzwerk, die nicht auf den Standardports (8333 für das Hauptnetzwerk, 18333 für Testnet) ausgeführt werden, werden vom Referenzclient vermieden, um keine Unterbrechung anderer Dienste zu verursachen. Sollte sonst jemand einen gefälschten Knoten ankündigen, der auf einem anderen Anwendungsport läuft, könnten andere Knoten im Netzwerk einen Denial-of-Service-Angriff verursachen, da sie erfolglos versuchen, sich mit ihm zu verbinden.

Ein Codeausschnitt des Bitcoin Core-Clients, der zeigt, dass Knoten Nicht-Standard-Ports ignorieren, es sei denn, sie sind sehr verzweifelt, jemanden zu finden, mit dem sie sich verbinden können:

// do not allow non-default ports, unless after 50 invalid addresses selected already
if (addr.GetPort() != Params().GetDefaultPort() && nTries < 50)
continue;

Wenn Sie das Netzwerk aktiv mit eingehenden Verbindungen unterstützen möchten, sollten Sie die "Port"-Einstellung des Bitcoin-Daemons möglichst nicht ändern.

Habe das nie gewusst. Aber das ist eine ziemliche Einschränkung. Macht das das Blockieren des Bitcoin-Verkehrs nicht viel einfacher? (wenn Regierungen oder so das wollen würden) Und wie gehe ich vor, um mehrere vollständige Knoten innerhalb eines LANs hinter derselben IP zu betreiben? (z. B. in meinem Bürogebäude)
Es ist ohnehin trivial, den Bitcoin-Verkehr zu blockieren, also ist es im eigentlichen Sinne keine große Grenze. Andere Leute können Netzwerkschichten erstellen, die versuchen, dieses Problem zu lösen, anstatt Teil des Kerndämons zu sein. Wenn Sie mehrere Knoten hinter einer externen IP haben, lassen Sie nur einen zuhören und alle anderen verbinden sich damit.

Beachten Sie, dass -addnode die Einstellung -port ignoriert

Beispielsweise haben sowohl node1 als auch node2 einen -port=14444

node1> bitcoin-cli addnode node2 hinzufügen

2018-08-11 02:07:04 connect() zu node2:18444 nach select() fehlgeschlagen: Verbindung abgelehnt (111)

Die Lösung besteht darin, den Port in den Hostnamen node1> bitcoin-cli addnode node2:14444 add aufzunehmen