P2P-Nachricht

Es gibt keinen zentralen Server, den man anrufen könnte, daher besteht die gesamte Beziehung eines Nodes zum Netzwerk aus diesem Gespräch. Bitcoin Core kündigt die Protokollversion 70016 an, öffnet seine Verbindungen auf Port 8333, und das ganze Vokabular passt auf eine Seite. Ihre Auszahlung erreicht einen Miner, weil eine Maschine tx zu einer anderen sagte und dies in wenigen Sekunden einige Tausend Mal weitergeleitet wurde.

Wie es funktioniert

Jede Verbindung beginnt mit einem Handshake und geht dann in eine kleine Gruppe wiederkehrender Austausche über.

Das Erste, was eine der beiden Seiten sendet, ist version, mit der Protokollnummer, die sie spricht, ihren Dienst-Flags, der aktuellen Zeit, der Adresse, von der sie glaubt, dass das andere Ende sie hat, einer zufälligen Nonce, mit der erkannt wird, ob sich ein Node versehentlich selbst anwählt, einer Nutzeragenten-Zeichenkette und der Höhe der besten Kette, die sie kennt. Jede Seite antwortet mit verack. Bis beide das getan haben, wird nichts anderes verarbeitet.

Diese Protokollnummer ist eine Funktionsleiter und keine Zierde. Die direkte Ankündigung von Headern erfordert 70012, die Aushandlung kompakter Blöcke erfordert 70014, die Ankündigung eines kompakten Blocks vor der vollständigen Validierung erfordert 70015, und die Weitergabe von Transaktionen über den Witness-Bezeichner erfordert 70016. Ein Node liest die Nummer seines Peers und verzichtet still darauf, Fähigkeiten anzubieten, die dieser Peer nicht nutzen kann, und so wird das Netzwerk ohne koordinierten Wechsel aktualisiert.

Nach Zweck gruppiert ist das Vokabular kurz. Peers finden: getaddr, addr und die Form addrv2 aus BIP155, die Tor- und I2P-Adressen tragen kann. Ankündigen: inv und headers. Anfordern: getheaders, getdata, getblocks, mempool. Liefern: tx, block, cmpctblock, blocktxn, notfound. Verwaltung: ping, pong, sendheaders, sendcmpct, wtxidrelay und feefilter, wobei letzteres einem Peer sagt, er solle Transaktionen unterhalb einer angegebenen Gebührenrate nicht weiterleiten.

Zweimal schweigt das Protokoll bewusst. Unbekannte Befehle werden ignoriert statt abgelehnt, und das ermöglicht es, einen neuen Nachrichtentyp nach und nach in einem Netzwerk einzuführen, das niemand auf einmal aktualisieren kann. Und es gibt für einen Peer keine Möglichkeit, Ihnen zu sagen, warum er Ihre Transaktion verworfen hat: Die reject-Nachricht aus BIP61 wurde in Bitcoin Core 0.18.0 standardmäßig deaktiviert und die Option in 0.20.0 ganz entfernt, weil die Antworten unzuverlässig, trivial zu fälschen und regelmäßig für maßgeblich gehalten wurden.

Wo Sie es sehen

P2P-Nachrichten sind das, was Ihr eigener Node den ganzen Tag tut, und sie sind leicht zu beobachten.

Starten Sie Bitcoin Core mit -debug=net, und das Protokoll nennt jede Nachricht, wenn sie eintrifft. Der Aufruf getpeerinfo meldet für jede Verbindung die gesendeten und empfangenen Bytes, aufgeschlüsselt nach Nachrichtentyp, und das ist der schnellste Weg herauszufinden, dass ein Peer Ihnen fast alles liefert, während die übrigen untätig bleiben. Das Senden einer Zahlung aus einer Wallet, die auf Ihren eigenen Node zeigt, erzeugt eine erkennbare kleine Abfolge: ein inv geht hinaus, ein getdata kommt zurück, ein tx geht als Antwort hinaus.

P2P-Nachricht vs. RPC

Bitcoin hat zwei Schnittstellen, und sie sind nicht austauschbar. P2P ist Node zu Node: nicht authentifiziert, nicht verschlüsselt, sofern nicht beide Enden den v2-Transport aushandeln, auf Port 8333, mit einem Vokabular, das kein einzelner Teilnehmer erweitern kann. RPC ist Programm zu Node: authentifiziert, standardmäßig lokal, auf Port 8332, mit einer Methodenliste, die sich mit jeder Version ändert. Eine Zahlung, die Sie erstellen, durchläuft beide: Sie gelangt als RPC-Aufruf in Ihren Node und verlässt ihn als P2P-Nachricht, und nur die zweite Hälfte geht irgendjemand anderen etwas an.