Block Template ist ein Datensatz zum Zusammenstellen eines Blocks, für dessen Header nach proof of work gesucht wird. Er verbindet Vorgängerblock, Transaktionen, Coinbase und Mining-Bedingungen; er beweist weder einen gefundenen noch einen akzeptierten Block.
previousblockhash und height ordnen den Kandidaten in die Kette ein. Hinzu kommen version, bits und Zeitangaben. Die Vorlage dient zum Zusammenstellen eines Blocks und ist nicht bloß ein fertiger Header für die blinde Wiederholung derselben Berechnung. [BIP 22 — Block template structure]
In BIP 22 verweist depends mit bei eins beginnenden Indizes auf frühere Einträge in transactions; Coinbase gehört nicht zu dieser Liste. Gibt eine Kindtransaktion einen Output einer im selben Block enthaltenen Elterntransaktion aus, muss diese vorher stehen. Fehlendes depends bedeutet unbekannte Abhängigkeiten, nicht deren Abwesenheit. [BIP 22 — Block template structure]
Bitcoin Core v29.0 bildet die Coinbase aus der Subvention dieser Höhe und den tatsächlichen Gebühren enthaltener Transaktionen. Nach dem Entfernen von Transaktionen darf der alte coinbasevalue nicht automatisch als berechtigte Vergütung bestehen bleiben. Eine andere Auswahl erfordert eine Neuberechnung verfügbarer Gebühren. [Bitcoin Core v29.0 — Block assembler]
Nach BIP 141 bindet das witness commitment Witness-Daten über wtxid. Bitcoin Core 29 liefert default_witness_commitment für die unveränderte Vorlage. Nach Änderungen relevanter Transaktionen oder ihrer Reihenfolge muss das Commitment geprüft oder neu berechnet werden; resultierende TXID müssen in die Merkle root des Headers eingehen. [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]
Bitcoin Core v29.0 wählt Pakete mit Abhängigkeiten aus und beachtet Gewicht sowie sigops. blockmaxweight und blockmintxfee beeinflussen die Zusammenstellung. Eine dadurch ausgelassene Transaktion ist nicht allein deshalb konsenswidrig; die Miner-Konfiguration erhöht auch keine Netzwerkgrenzen. [Bitcoin Core v29.0 — Block assembler]
BIP 23 beschreibt mit mutable erlaubte Änderungen, etwa an Zeit oder Transaktionen. Server-Erlaubnis setzt den Konsens nicht außer Kraft: Vorgänger, Zeit, Schwierigkeit und Transaktionen müssen weiterhin stimmen. Zugriff auf eine Vorlage garantiert einem Endgerät außerdem keine uneingeschränkte Inhaltsauswahl. [BIP 23 — Mutations and proposals]
BIP 23 kann Arbeit durch expires begrenzen und Änderungen an prevblock regeln. Ändert sich die Kettenspitze, garantiert ein bloßer Austausch des Vorgänger-Hashes nicht die weitere Gültigkeit aller übrigen Daten. Höhe, Transaktionen, Vergütung und andere Kontextbedingungen sind neu zu prüfen. [BIP 23 — Mutations and proposals]
Der Modus proposal in BIP 23 prüft einen Vorschlag ohne gültigen proof of work zu verlangen. Ein positives Ergebnis bedeutet daher weder einen gefundenen oder veröffentlichten Block noch einen dauerhaften Platz in der Kette. Der fertige Block muss beim Einreichen die entsprechende Validierung durchlaufen. [BIP 23 — Mutations and proposals]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Mining Pool, Block-Header, Extranonce, Merkle-Baum. Auf diesen Eintrag verweisen außerdem Coinbase-Transaktion, Stratum V1, Stratum V2, Extranonce.