Konsensregeln legen fest, welche Transaktionen und Blöcke Bitcoin akzeptieren kann. Jeder Full Node, also ein Programm zur unabhängigen Prüfung des Netzwerks, wendet sie selbst an. Er prüft beispielsweise, ob dieselben Mittel nicht erneut ausgegeben werden, ob die in der Sprache Bitcoin Script formulierten Ausgabebedingungen erfüllt sind und ob der Block einen gültigen Proof of Work besitzt: den Nachweis einer gelösten Mining-Aufgabe. Auch die Menge neu erzeugter Bitcoin wird geprüft. Mehr Rechenleistung berechtigt einen Miner nicht, diese Regeln zu umgehen.
Stellen Sie sich vor, jemand gibt dieselben Mittel aus einer früheren Zahlung erst an Sie und dann an ein Geschäft weiter. Beide Ausgaben können nicht zu einer gültigen Historie gehören. Zur Prüfung verfolgt der Node Transaktionsoutputs: Einträge mit einem Betrag und den Bedingungen, unter denen er ausgegeben werden kann. Erhält ein Node einen Block, prüft er, ob der Block die Regeln seiner Software erfüllt, und nicht, wer ihn empfohlen hat. Er kontrolliert unter anderem die Verfügbarkeit der Outputs, die ausgegeben werden sollen, die Bedingungen von Bitcoin Script samt erforderlichen Signaturen, den Proof of Work und die zulässige Miner-Vergütung. Ein Regelverstoß führt zur Ablehnung. Unterstützung durch Unternehmen oder Mehrheiten im Internet ändern daran nichts. [1]
Ein Miner wählt Transaktionen aus und sucht nach einem Block; ein Full Node prüft das Ergebnis unabhängig. Entwickler können Änderungen vorschlagen und Software veröffentlichen, ändern dadurch aber noch nicht die Regeln anderer Nodes. Die Betreiber entscheiden, welche Software sie ausführen. Das bestimmt, was ihr eigener Node akzeptiert, nicht was alle anderen akzeptieren müssen. [2] [1]
Für unbestätigte Transaktionen gelten außerdem lokale Regeln: Was nimmt der Node in seinen Mempool auf, also seinen lokalen Bestand an Transaktionen, die auf eine Bestätigung warten? Was leitet er an andere Nodes weiter? Diese Policy kann strenger sein als der Konsens. Eine Ablehnung durch den Mempool bedeutet deshalb allein noch nicht, dass die Transaktion in einem Block ungültig wäre. Bei der Blockprüfung wird die Relay-Policy nicht angewandt. [3]
Ein Soft Fork verschärft die Regeln: Nach den neuen Regeln gültige Blöcke erfüllen auch die alten. Ältere Nodes prüfen die neuen Bedingungen allerdings nicht. Ein Hard Fork kann dagegen Blöcke zulassen, die ältere Nodes ablehnen. Ein Aktivierungsverfahren hilft bei der Koordination; es garantiert weder allgemeine Zustimmung noch ersetzt es die Softwareentscheidung der Betreiber. [4]
Mit einem eigenen Full Node können Sie empfangene Blöcke selbst prüfen, statt sich auf eine Blockexplorer-Website zu verlassen. Ein Node kann mehrere Zweige kennen, also unterschiedliche Fortsetzungen einer gemeinsamen Historie. Unter den gültigen Zweigen wählt er anhand der chainwork: der Summe der Arbeit, die jedem Block entsprechend seiner Mining-Schwierigkeit zugerechnet wird. Das ist weder eine Messung des tatsächlich verbrauchten Stroms noch eine bloße Zählung der Blöcke. Mehr Arbeit rechtfertigt keinen Regelverstoß. Damit Nodes zum selben Ergebnis kommen, müssen sie die Regeln auch in ungewöhnlichen Fällen einheitlich anwenden. Ein Programmfehler kann dazu führen, dass sie unterschiedliche Blöcke akzeptieren. [4] [5]
Ein Node kann die Weiterleitung einer Transaktion wegen einer zu niedrigen Gebühr ablehnen. Nimmt ein Miner sie dennoch in einen Block auf und erfüllen Transaktion und Block die Konsensregeln, akzeptiert der Node den Block. Beansprucht der Miner dagegen mehr als die erlaubte Menge neuer Bitcoin, die sogenannte Block Subsidy, zuzüglich der Transaktionsgebühren im Block, lehnt der Node den Block trotz gültigem Proof of Work ab. Entscheidend ist der Ablehnungsgrund, nicht der Ruf des Miners. [3] [1]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Full Node, Soft Fork, Proof of Work, Bitcoin Core, Bitcoin Script, Mempool. Auf diesen Eintrag verweisen außerdem 21 Million, Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal).