Standardness und Policy

Neugier

1. Warum wird eine gültige Transaktion manchmal von einer Wallet abgelehnt, bevor sie überhaupt einen Miner erreicht?
2. Was passiert, wenn eine Gegenpartei eine andere Software verwendet als Sie, beide aber „korrekt“ sind?
3. Wie kann es zukünftige Upgrades schützen, ungenutzte Opcodes vom Relay-Pfad fernzuhalten?

Erkunden

1. Konsensregeln definieren die Gültigkeit; sie legen fest, was in einem Block stehen darf und von jedem Node akzeptiert wird. Standardness ist eine davon getrennte, lokale Policy, die bestimmt, welche Transaktionen ein bestimmter Node an seine Peers weiterleitet und in seinem Mempool hält. Eine Transaktion kann nach den Konsensregeln völlig gültig, nach der Standard-Relay-Policy aber nicht standard sein. Sendet ein Nutzer eine solche Transaktion ins Netzwerk, kann sein eigener Node sie sofort verwerfen, obwohl Miner sie technisch aufnehmen könnten.
2. Standard-Output-Typen sind streng begrenzt, um Nodes vor Denial-of-Service-Angriffen und Ressourcenerschöpfung zu schützen. Dazu gehören P2PKH, P2SH, P2WPKH, P2WSH, P2TR, kleine Bare-Multisig-Scripts (bis zu drei Schlüssel) und OP_RETURN-Datenoutputs bis zu einer bestimmten Größe. Scripts mit reservierten oder unbekannten Opcodes oder solche, die Größenlimits überschreiten, werden standardmäßig nicht weitergeleitet. Diese Filterung hält den Mempool beherrschbar und verhindert, dass böswillige Akteure das Netzwerk mit komplexem, rechenintensivem Datenmüll fluten.
3. Policy ist nicht statisch; sie entwickelt sich je nach Node-Implementierung weiter. 2025 beschlossen die Entwickler von Bitcoin Core, das Standard-Größenlimit für OP_RETURN-Datenoutputs zu lockern. Die Änderung löste eine Debatte unter Node-Betreibern aus; einige lehnten die Ausweitung ab und wechselten zu alternativer Software wie Bitcoin Knots, um die strengeren bisherigen Limits beizubehalten. Diese Divergenz zeigt, dass Standardness eine lokale Einstellung ist: Zwei Nodes mit unterschiedlichen Versionen oder Forks können unterschiedliche Teilmengen gültiger Transaktionen weiterleiten, ohne den Konsens zu verletzen.
4. Eine nicht standardmäßige, aber gültige Transaktion kann dennoch bestätigt werden, wenn sie das übliche Relay-Netzwerk vollständig umgeht. Miner haben Dienste zur direkten Einreichung angeboten, über die Nutzer Transaktionen unabhängig von der Node-Policy direkt in ihre Blöcke schicken können. Verlässt sich eine Wallet zur Sicherheit darauf, dass nicht standardmäßige Transaktionen abgelehnt werden – in der Annahme, ein ungültig wirkendes Script werde sich nie verbreiten –, geht sie ein Risiko ein: Eine Gegenpartei mit direktem Zugang zu Minern könnte diese Transaktion bestätigen lassen. Das erzeugt eine Abweichung im Verhalten, nicht in der Wahrheit, und kann zu unerwarteten Geldbewegungen oder Verlusten führen.
5. Standardness dient als Sicherheitsventil für künftige Soft-Fork-Upgrades. Indem schon jetzt strengere Regeln gelten – etwa indem reservierte, für Upgrades vorgesehene NOP-Opcodes beim Weiterleiten als nicht standard behandelt werden –, sorgt das Protokoll für einen reibungslosen Übergang, wenn ein Upgrade die Konsensregeln verschärft. Da Transaktionen mit diesen reservierten Opcodes standardmäßig weder weitergeleitet noch gemined werden, gibt es kaum oder keine davon, wenn ein Soft Fork diesen Opcodes eine Bedeutung gibt. Die neuen Regeln machen also nichts ungültig, worauf sich jemand verlassen hat, und es ist unwahrscheinlich, dass nicht aktualisierte Miner einen Block minen, den die neuen Regeln ablehnen.
6. Lesen Sie die Policy-Prüfungen selbst nach: Im Quellcode von Bitcoin Core enthält policy/policy.cpp die Funktionen IsStandard und IsStandardTx, die die zulässigen Output-Typen und Größenlimits auflisten; die Reihe „Waiting for confirmation“ von Bitcoin Optech erklärt die Gründe dafür. Vergleichen Sie sie mit den Konsensregeln im Validierungscode und beachten Sie, wie viel enger die Relay-Regeln gefasst sind.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)