Block Template

Jeder neue Block baut auf einem bestimmten Vorgänger auf. Die Vorlage benennt ihn durch previousblockhash, seinen eindeutigen Fingerabdruck. height bezeichnet die Position des geplanten Blocks in der Kette. Hinzu kommen version für die Header-Version, bits als kompakte Codierung des Zielwerts für das Mining-Ergebnis und Zeitangaben. Es geht um den Aufbau eines konkreten Blocks, nicht um eine unabhängige Zahlungsliste. Dieselben Transaktionen hinter einem anderen Vorgänger ergeben bereits eine andere Aufgabe. [1]

Anna erhält Bitcoin und bezahlt anschließend damit. Sollen beide Überweisungen im selben Block stehen, muss zuerst die Transaktion kommen, die ihr die Mittel zuweist, und danach diejenige, die sie ausgibt. BIP 22, das technische Dokument zum Aufbau der Vorlage, definiert dafür das Feld depends: Das Feld verweist mit bei eins beginnenden Positionen auf frühere Einträge in der Liste transactions. Diese enthält nicht die Coinbase, die besondere erste Transaktion zur Zuweisung der Mining-Belohnung. Fehlt depends, sind die Abhängigkeiten unbekannt. Die Software darf daraus nicht schließen, dass es keine gibt. [1]

Zur Belohnung gehören neu ausgegebene Bitcoin nach den Regeln der jeweiligen Blockhöhe und die Gebühren der tatsächlich enthaltenen Transaktionen. Auch die hier verlinkte Version Bitcoin Core v29.0 berechnet sie so. Diese Software prüft Blöcke und Transaktionen und kann Vorlagen für das Mining vorbereiten. In unserem Beispiel bringen die Transaktionen 10000 sats ein. Entfernt man eine unabhängige Transaktion mit 3000 sats Gebühr, bleiben 7000 sats Gebühren übrig. Sats sind kleine Bitcoin-Einheiten. Das Feld coinbasevalue gibt die höchste Belohnung an, die der Miner mit der ursprünglichen Transaktionsauswahl beanspruchen darf. Ändert sich diese Auswahl, muss der Betrag neu berechnet werden. Entscheidend sind die tatsächlichen Gebühren, nicht die Summe für den alten Inhalt. [4] [1]

Ein Block enthält auch kryptografische Fingerabdrücke zur Prüfung seiner Daten. BIP 141 beschreibt das Witness Commitment, einen kryptografischen Fingerabdruck der Witness-Daten, zu denen etwa Signaturen zum Nachweis einer Ausgabeberechtigung gehören. Es wird aus wtxid-Kennungen abgeleitet, die diese Daten einschließen. Bitcoin Core 29 liefert default_witness_commitment für eine unveränderte Vorlage. Ändern sich relevante Transaktionen oder ihre Reihenfolge, muss das Commitment geprüft oder neu berechnet werden. Auch der Merkle root, der gemeinsame Transaktionsfingerabdruck im Header, muss aus den endgültigen TXID-Kennungen berechnet werden, einschließlich der Kennung der geänderten Coinbase. Ein altes Siegel gehört nicht auf veränderte Inhalte. [5] [3]

Blockplatz ist begrenzt, und Miner wählen aus, was hineinkommt. Bitcoin Core v29.0 berücksichtigt Pakete zusammenhängender Transaktionen, deren Gewicht als Maß der angerechneten Datenlast und sigops, die für das Blocklimit gezählten Signaturprüfungsoperationen. Einstellungen wie blockmaxweight und blockmintxfee beeinflussen die Größe des erstellten Blocks und die geforderte Gebührenrate. Das ist Auswahlpolitik. Fehlt eine Zahlung deshalb, muss sie nach den Netzwerkregeln nicht ungültig sein. Eigene Einstellungen des Miners erhöhen außerdem nicht die Netzwerklimits, die andere Knoten prüfen. [4] [3]

In BIP 23 listet mutable die vom Server erlaubten Änderungen auf, etwa Zeitänderungen oder das Hinzufügen von Transaktionen. Das ist eine Vereinbarung über den Umgang mit einer bestimmten Vorlage. Sie setzt den Konsens nicht außer Kraft: die Gültigkeitsregeln, die andere Teilnehmer unabhängig prüfen. Vorgänger, Zeit, Schwierigkeit und Transaktionen müssen weiterhin stimmen. Zugang zur Vorlage bedeutet auch nicht, dass jedes angeschlossene Mining-Gerät ihren Inhalt beliebig ändern kann. Das hängt vom Aufbau des Systems und der übermittelten Aufgabe ab. [2]

Während der Berechnungen kann ein anderer Miner die Kette erweitern. Soll die weitere Arbeit am neuesten akzeptierten Block ansetzen, reicht es nicht, in der alten Vorlage nur den Fingerabdruck des Vorgängers auszutauschen. Einige Transaktionen könnten schon bestätigt sein; Höhe und weitere Bedingungen ändern sich. BIP 23 beschreibt expires als zeitliche Begrenzung der Arbeit und prevblock als Erlaubnis, sie mit einem anderen Vorgänger zu verwenden. Auch diese Erlaubnis ersetzt keine Prüfung: Transaktionen, Belohnung und der gesamte neue Kontext müssen erneut beurteilt werden. [2]

Ein Fehler im eigenen Entwurf sollte besser vor einer langen Suche auffallen. Der Modus proposal nach BIP 23 erlaubt die Prüfung eines Vorschlags ohne gültigen Proof of Work, also ohne bereits gefundenes Ergebnis zum Nachweis der nötigen Rechenarbeit. Eine positive Beurteilung bedeutet weder einen gefundenen oder verbreiteten Block noch einen garantierten dauerhaften Platz in der Kette. Sie besagt, dass der Entwurf die betreffende Vorprüfung bestanden hat. Der fertige Block muss bei der Einreichung noch die erforderliche Validierung einschließlich Arbeitsnachweis durchlaufen. [2]