39 / 691CBTX

Coinbase-Transaktion

Eine Coinbase-Transaktion ist die obligatorische erste Transaktion jedes Bitcoin-Blocks. Es verfügt über einen einzigen speziellen Input, der kein älteres UTXO ausgibt, es einem Miner ermöglicht, höchstens die neu ausgegebene Belohnungskomponente eines bestimmten Betrags zuzüglich Gebühren in einem Block zu beanspruchen, und produziert Outputs, die nicht für weitere 100 Blöcke fällig werden.

Bei Coinbase handelt es sich um eine einvernehmliche Art von Transaktion, nicht um ein Coinbase-Unternehmen oder eine regelmäßige Zahlung. Zusammen mit dem Block überprüft der Knoten den Null-Outpoint, die Höhe gemäß BIP34, die Belohnungsobergrenze, die Null-Position, die Reife und ein mögliches SegWit-Engagement. Es wird nicht separat in den Mempool aufgenommen.

Ein Block muss mindestens eine Transaktion enthalten und Coinbase kann nur die erste sein. Bitcoin Core erkennt es an seiner genauen Struktur: eine einzelne Eingabe mit 32 Null-Bytes im Hash der vorherigen Ausgabe und einem Index von 0xffffffff. Die Eingabe entsperrt kein vorhandenes UTXO, daher verfügt es nicht über eine reguläre Signatur oder einen Prevout-Wert. Eine Transaktion kann weiterhin mehrere Ausgaben haben, eine reguläre Version sowie eine Sperrzeit und eine benutzerdefinierte txid. [Bitcoin-Entwicklerreferenz – Coinbase-Eingabe] [Bitcoin-Entwicklerreferenz – Blockchain] [Bitcoin Core – transaktion.h (IsCoinBase)]

Die Summe der Coinbase-Ausgaben darf GetBlockSubsidy für diesen Betrag zuzüglich der Gebühren aller anderen gültigen Transaktionen im Block nicht überschreiten. Nur die neu ausgegebene Belohnungskomponente erzeugt neue Satoshi; Gebühren wandeln bereits bestehende Satoshi um. Ein Miner kann weniger beanspruchen und die Differenz ist für immer verloren, aber ein einziger Satoshi über dem Limit macht den gesamten Block ungültig. Der Konsens bestimmt nicht die Aufteilung zwischen einem Pool, Minern oder mehreren Skripten. [Bitcoin Core – validation.cpp] [Bitcoin Core – miner.cpp]

Ab BIP34 muss scriptSig Coinbase mit der aktuellen Blockhöhe als minimal codierte CScript-Nummer beginnen. Die gesamte scriptSig ist 2 bis 100 Bytes groß. Der Rest kann eine zusätzliche Nonce, ein Pool-Tag oder eine zusammengeführte Mining-Verpflichtung enthalten, liegt jedoch nicht außerhalb der Regeln: Eine falsche Höhe oder Länge führt dazu, dass der Block ungültig wird, und eingebettete Signatur-Opcodes verbrauchen möglicherweise das Sigop-Limit. [Bitcoin-Entwicklerreferenz – Coinbase-Eingabe] [BIP 34 – Blockhöhe in Coinbase]

Der ASIC ändert die Nonce im Header, aber der 32-Bit-Speicherplatz geht schnell zur Neige. Die Mining-Software wandelt daher die zusätzliche Nonce in eine Coinbase um; Dadurch werden seine txid, die Merkle-Root-Transaktion und anschließend der Block-Header geändert, sodass er einen neuen Hash-Bereich erhält. Poolprotokolle teilen diesen Raum zwischen den Arbeitern auf, damit ihre Anteile nicht kollidieren. Die zusätzliche Nonce ist ein Koordinationsstück, keine zusätzliche Emission. [Bitcoin Core – miner.cpp] [BIP 22 – getblocktemplate] [Stratum V2 – Mining-Protokoll-Spezifikation]

Coinbase-Ausgaben verwenden gängige Sperrskripte und können auf mehrere Adressen oder Richtlinien aufgeteilt werden. Der Pool kann an eine Abholadresse zahlen, die Einnahmen sofort aufteilen oder die Leistung für den Betreiber reservieren. Der Knoten überprüft jedoch Beträge und Skripte, nicht Verträge oder tatsächliche Eigentümer. Auszahlungsschwellenwerte, PPS, FPPS, PPLNS und spätere Auszahlungen sind nicht protokollierte Poolregeln. [Bitcoin Core – miner.cpp] [BIP 22 – getblocktemplate]

Wenn der Block eine Witness-Transaktion enthält, erfordert BIP141 eine Coinbase-Witence-Verpflichtung in einer Ausgabe: OP_RETURN, beginnend mit 6a24aa21a9ed und eine 32-Byte-Verpflichtung. Der Coinbase-Eingabezeuge enthält einen einzelnen reservierten 32-Byte-Wert. Wenn es mehr übereinstimmende Ergebnisse gibt, nimmt der Konsens den höchsten Index an. Diese Ausgabe bindet die Zeugen-Merkle-Wurzel; keine Belohnung für Bergleute. [BIP 141 – Engagement für getrennte Zeugen]

Die Ausgabe von Coinbase ist im UTXO-Set mit einem speziellen Flag gekennzeichnet und darf nur ausgegeben werden, wenn die Differenz der Höhe des Ausgabe- und Erstellungsblocks COINBASE_MATURITY, heute 100, erreicht. Daher kann die Belohnung aus Höhe H zum ersten Mal im Block H+100 ausgegeben werden. Das Wallet kann einen scheinbaren Unterschied von einer Bestätigung aufweisen, da der generierende Block zuerst zählt. Reife ist nicht Endgültigkeit. [Bitcoin Core – consens.h (COINBASE_MATURITY)]

Wenn ein abgebauten Block während der Reorganisation mit der meisten Arbeit aus der aktiven Kette fällt, verschwinden seine Coinbase-Ausgaben aus dem aktiven UTXO-Satz. Nachfolgende Transaktionen, bei denen die Fälligkeitsprämie bereits ausgegeben wurde, können ebenfalls ungültig sein. Eine Verzögerung von 100 Blöcken begrenzt den Schaden kurzer Reorganisationen, garantiert jedoch keine Unveränderlichkeit. Ein Pool muss die aktive Kette, den Reifegrad und seine Verpflichtungen gegenüber den Bergleuten separat überwachen. [Bitcoin Core – validation.cpp] [Bitcoin Core – consens.h (COINBASE_MATURITY)]

Der vollständige Knoten erfordert während der Validierung eine Münzbasis auf Position Null, lehnt zusätzliche Münzbasis ab, überprüft die Länge von scriptSig und die BIP34-Höhe, berechnet Gebühren für andere Transaktionen und lehnt Belohnungen über der Neuausgabe plus Gebühren ab. Es überprüft auch die Preisspanne, das Gewicht, das Engagement des Zeugen und die spätere Fälligkeit der Ausgaben. Eine separate Coinbase ohne Höhe und Blockkontext gehört nicht in den Mempool. [Bitcoin Core – transaction.h (IsCoinBase)] [Bitcoin Core – validation.cpp] [BIP 141 – Segregated Witness Commitment]

In den frühen Blöcken konnte die gleiche txid-Coinbase erstellt werden, da die Höhe noch nicht zwingend vorgeschrieben war. BIP30 verhindert, dass die nicht ausgegebene Ausgabe einer älteren Transaktion überschrieben wird, und BIP34 sorgt dafür, dass moderne Coinbases üblicherweise eine eindeutige Höhe haben. Genesis ist eine historische Ausnahme: Seine Münzbasis befindet sich in einem serialisierten Block, aber der Initialisierungscode hat seine Ausgabe nie in die entbehrliche UTXO-Datenbank gestellt. Daher können die berühmten 50 BTC nicht ausgegeben werden. [BIP 30 – Doppelte Transaktionen] [BIP 34 – Blockhöhe in Coinbase] [Bitcoin Core – chainparams.cpp (Genesis-Konstruktion)]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Block, Blocksubvention, Transaktionsgebühren, Mining, Block Template, Bitcoin. Auf diesen Eintrag verweisen außerdem Blocksubvention, Bestätigung, Nonce.

DOC · 001Bitcoin Developer Reference — Coinbase inputDokumentationDOC · 002Bitcoin Developer Reference — Block chainDokumentationDOC · 003Bitcoin Core — transaction.h (IsCoinBase)DokumentationDOC · 004Bitcoin Core — validation.cppDokumentationDOC · 005Bitcoin Core — consensus.h (COINBASE_MATURITY)DokumentationDOC · 006Bitcoin Core — miner.cppDokumentationDOC · 007BIP 22 — getblocktemplateSpezifikationDOC · 008BIP 30 — Duplicate transactionsSpezifikationDOC · 009BIP 34 — Block height in coinbaseSpezifikationDOC · 010BIP 141 — Segregated Witness commitmentSpezifikationDOC · 011Bitcoin Core — chainparams.cpp (genesis construction)DokumentationDOC · 012Stratum V2 — Mining Protocol specificationSpezifikation
Geprüft am 1. August 2026Quellenbasiert · Keine Anlageberatung