Bitcoin hat keinen zentralen Server. Nodes sprechen direkt miteinander über ein einfaches Peer-to-Peer-Protokoll, standardmäßig auf TCP-Port 8333.
Der Nachrichtenrahmen
Im ursprünglichen (v1) Protokoll beginnt jede Nachricht mit einem Header: 4 „Magic“-Bytes, die das Netz identifizieren (F9 BE B4 D9 auf Mainnet), ein 12-Byte-Befehlsname, eine Payload-Länge und eine 4-Byte-Prüfsumme. Der Verkehr ist unverschlüsselt.
v2: verschlüsselter Transport
BIP324 fügt einen verschlüsselten Transport hinzu. Bitcoin Core unterstützt ihn und hat ihn seit Version 27.0 standardmäßig aktiviert. Er authentifiziert Peers nicht, erschwert aber passives Spionieren und Manipulation stark.
Der Handshake
Zwei Nodes tauschen version-Nachrichten (Software-Version, angebotene Dienste, beste Höhe) und bestätigen mit verack. Feature-Nachrichten wie sendheaders, sendcmpct, wtxidrelay und sendaddrv2 werden um den Handshake herum gesendet.
Daten gossipen
invkündigt an „ich habe diese Transaktion oder diesen Block“.getdatafragt danach, undtxoderblockliefert sie.headersundgetheaderstauschen Block-Header, bis zu 2.000 auf einmal.cmpctblock,getblocktxnundblocktxntragen Compact Blocks (BIP152).feefiltersagt einem Peer, keine Transaktionen unter einer Feerate zu senden.ping/pongprüfen, ob die Verbindung lebt.
Peers finden
Ein neuer Node fragt zuerst DNS-Seeds, betrieben von bekannten Community-Mitgliedern, nach Adressen. Danach lernt er mehr über addr- und addrv2-Nachrichten. BIP155s addrv2 kann Tor-v3-, I2P- und CJDNS-Adressen tragen.
Angriffe abwehren
Bitcoin Core macht standardmäßig 8 Full-Relay-Outbound-Verbindungen und 2 Block-Relay-only-Verbindungen. Es wählt Adressen aus verschiedenen Netzgruppen, damit ein Angreifer einen Node nicht leicht umzingeln kann (ein „Eclipse-Angriff“). Peers, die ungültige Daten senden, werden getrennt.
Fazit
Die P2P-Schicht bewegt nur Daten. Jeder Node prüft weiterhin jeden Block und jede Transaktion selbst gegen die Konsens-Regeln.