getblocktemplate ist eine Schnittstelle, über die Software von einem Bitcoin-Knoten Daten zum Zusammenstellen eines möglichen neuen Blocks erhält. Sie nutzt JSON-RPC, also eine Anfrage mit strukturierter Antwort zwischen Programmen. Der normale Modus liefert eine Vorlage; ein weiterer Modus kann einen eigenen Entwurf vorab prüfen. Keiner von beiden sucht selbst nach einem Arbeitsnachweis.
Im üblichen Modus mode=template erhält Peters Programm etwa den Vorgängerblock, Transaktionen und die zulässige Belohnung. Das ist ein Arbeitsentwurf, kein bereits gefundener Block. Die Software muss coinbase, die besondere erste Transaktion zur Zuweisung der Belohnung, erstellen und den Block zusammensetzen. Der Header fasst die Blockdaten kompakt zusammen. Die Software sucht dann einen Hash, einen numerischen kryptografischen Fingerabdruck dieses Headers, der das Mining-Ziel erfüllt und als Proof of Work die Rechenarbeit nachweist. getblocktemplate nimmt selbst keine Auszahlungsadresse entgegen und startet keine Berechnungen der Mining-Geräte. Eine erfolgreiche Antwort bedeutet daher noch nicht, dass Peter schürft. [1]
Angenommen, der Knoten sendet Daten in einem Format, mit dem Peters Programm nicht umgehen kann. Deshalb nennt die Anfrage im Feld rules die unterstützten Regeln. Der hier geprüfte Bitcoin Core v29.0 verlangt segwit und für das Testnetz Signet zusätzlich signet. SegWit verändert unter anderem den Umgang mit Daten zur Transaktionsprüfung. Das passende Wort einzutragen reicht nicht: Die Software muss die Regeln tatsächlich umsetzen. capabilities meldet andere Fähigkeiten der Schnittstelle und ersetzt rules nicht. Die genauen Anforderungen hängen von Implementierung und Version ab. [2]
Das Feld data enthält die vollständige Transaktion, geordnet für die Übertragung zwischen Programmen. Diese Anordnung heißt Serialisierung. Die Bytes, die Grundeinheiten dieser Daten, werden hexadezimal mit den Ziffern 0–9 und den Buchstaben a–f dargestellt. Die Antwort enthält außerdem kurze Kennungen der Transaktionen. Nach der technischen Spezifikation BIP 145 wird txid ohne witness-Daten berechnet, während hash sie einschließt. Witness enthält beispielsweise Signaturen, die eine Ausgabeberechtigung belegen. Die zentrale Merkle root, der zusammengefasste Transaktionsfingerabdruck im Blockheader, verwendet txid statt des witness hash. Diese Felder zu verwechseln ist mehr als ein Namensfehler: Es kann einen falschen Gesamtfingerabdruck erzeugen und den zusammengesetzten Block ungültig machen. [3]
Peter muss den Knoten nicht ständig fragen, ob sich etwas geändert hat. Beim Long Polling bleibt eine Anfrage offen, bis der Server die bisherigen Daten ersetzen möchte. Das Programm übernimmt longpollid und sendet es unverändert zurück. An diesem Wert erkennt der Server, auf welche Änderung das Programm wartet. Das Programm darf aus den enthaltenen Zeichen keine Bedeutung ableiten. BIP 22 sieht eine lange Wartefrist vor. Wiederholt unvollständige oder ungültige Antworten erfordern Pausen zwischen Versuchen statt einer sofortigen Wiederholungsschleife. Stilles Warten ist deshalb für sich genommen kein Ausfall. [4]
Auch eine gewöhnliche wiederholte Anfrage garantiert keine neu ausgewählten Inhalte. Bitcoin Core v29.0 hält eine vorbereitete Vorlage im Cache. Er erstellt sie neu, wenn der Vorgänger wechselt oder wenn sich der mempool, der lokale Bestand unbestätigter Transaktionen, geändert hat und seit der Vorbereitung mehr als fünf Sekunden vergangen sind. Die Zeit im Header kann er gesondert aktualisieren. Peter erhält daher möglicherweise dieselbe Transaktionsauswahl erneut; der Knoten ist deswegen nicht stecken geblieben. Dieses versionsspezifische Verhalten verspricht auch keine eigenständige Mining-Aufgabe bei jedem Aufruf. [2]
Peter hat die Blockerstellung verändert und möchte Fehler vor einer aufwendigen Suche entdecken. Im Modus proposal übergibt er den vollständigen Block als hexadezimale Darstellung in data. Bitcoin Core v29.0 prüft auch die Merkle root, verlangt aber noch keinen gültigen Proof of Work, den Nachweis der Rechenarbeit. Knüpft der Entwurf nicht an den letzten Block der Kette, die der Knoten gerade verwendet, an, lautet die Antwort inconclusive-not-best-prevblk. Damit fehlt eine Voraussetzung dieser Prüfung; es ist keine vollständige Beurteilung der Gültigkeit. Die Vorprüfung verbreitet den Block auch nicht im Netzwerk. [2]
Hat die Software den nötigen Arbeitsnachweis gefunden, kann sie den vollständigen Block über submitblock einreichen. hexdata enthält den gesamten serialisierten Block in hexadezimaler Schreibweise, nicht nur Header oder Fingerabdruck. Die Dokumentation von Bitcoin Core 29 nennt null bei Annahme und andernfalls ein Textergebnis gemäß Spezifikation. Der optionale zweite Parameter dummy wird ignoriert; er bestimmt keine Belohnung. Die Annahme durch einen Knoten garantiert keine dauerhafte Bestätigung: Durch die weitere Entwicklung der Kette kann sich ändern, welcher Zweig der Hauptzweig bleibt. [5]
Ein frisch gestarteter Knoten hat die benötigte Historie womöglich noch nicht heruntergeladen und geprüft. Im Hauptnetz, mainnet, gibt Bitcoin Core v29.0 ohne verbundene Gegenstellen oder während der anfänglichen Synchronisierung IBD (initial block download) keine Vorlage aus. Das betrifft die Bereitschaft des Knotens, mit dem aktuellen Netzwerk zu arbeiten, nicht die Ablehnung eines bestimmten Blocks. Bei der Fehlersuche unterscheiden wir deshalb einen wartenden Long Poll, einen noch nicht bereiten Knoten und das Ergebnis einer Entwurfsprüfung. Alles kann wie „keine neue Arbeit“ wirken, erfordert aber unterschiedliche Maßnahmen. [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Block Template, Mining, Stratum V2, Extranonce, Bitcoin, Bitcoin Core. Auf diesen Eintrag verweisen außerdem ASIC Miner, Solo Mining, Job Negotiation.