Coinbase jest rodzajem transakcji dokonywanej za obopólną zgodą, a nie firmą Coinbase czy zwykłą płatnością. Razem z blokiem węzeł weryfikuje punkt zerowy, wysokość zgodnie z BIP34, pułap nagrody, pozycję zerową, dojrzałość i ewentualne zaangażowanie SegWit. Nie jest on oddzielnie przyjmowany do pamięci.
Blok musi zawierać co najmniej jedną transakcję, a baza monet może być tylko pierwszą. Bitcoin Core rozpoznaje to po dokładnej strukturze: pojedyncze wejście z 32 bajtami zerowymi w haszu poprzedniego wyjścia i indeksem 0xffffffff. Dane wejściowe nie odblokowują istniejącego UTXO, więc nie mają zwykłego podpisu ani wartości prevout. Transakcja może nadal mieć wiele wyników, zwykłą wersję, a także czas blokady i niestandardowy identyfikator txid. [Informacje dla programistów Bitcoin – Dane wejściowe Coinbase] [Informacje dla programistów Bitcoin – Łańcuch bloków] [Bitcoin Core – transakcja.h (IsCoinBase)]
Suma wyjść z bazy monet nie może przekroczyć kwoty GetBlockSubsidy powiększonej o opłaty za wszystkie inne ważne transakcje w bloku. Tylko nowo wydany składnik nagrody tworzy nowe satoshi; opłaty konwertują istniejące satoshi. Górnik może zażądać mniej i różnica znika na zawsze, ale pojedyncze satoshi powyżej limitu unieważnia cały blok. Konsensus nie określa podziału pomiędzy pulą, górnikami lub wieloma skryptami. [Bitcoin Core — validation.cpp] [Bitcoin Core — miner.cpp]
Począwszy od BIP34, baza monet scriptSig musi zaczynać się od bieżącej wysokości bloku jako minimalnie zakodowanego numeru CScript. Cały skryptSig ma od 2 do 100 bajtów. Reszta może zawierać dodatkową wartość jednorazową, znacznik puli lub zobowiązanie do scalonego wydobycia, ale nie jest to poza zasadami: nieprawidłowa wysokość lub długość unieważni blok, a osadzone kody sygnatur mogą wykorzystać limit sigop. [Informacje dla programistów Bitcoin – Dane wejściowe Coinbase] [BIP 34 – Wysokość bloku w bazie monet]
Układ ASIC zmienia wartość jednorazową w nagłówku, ale 32-bitowa przestrzeń szybko się kończy. Dlatego oprogramowanie wydobywcze zamienia dodatkową kwotę w bazę monet; spowoduje to zmianę jego txid, transakcji głównej Merkle, a następnie nagłówka bloku, dzięki czemu otrzyma nową przestrzeń mieszającą. Protokoły puli dzielą tę przestrzeń pomiędzy pracowników, aby ich udziały nie kolidowały ze sobą. Dodatkowa nonce jest elementem koordynacyjnym, a nie dodatkową emisją. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate] [Stratum V2 — Specyfikacja protokołu Mining]
Dane wyjściowe Coinbase wykorzystują typowe skrypty blokujące i mogą być dzielone pomiędzy wiele adresów lub polityk. Pula może zapłacić na adres odbioru, natychmiast podzielić przychody lub zarezerwować produkcję dla operatora. Jednak węzeł weryfikuje kwoty i skrypty, a nie umowy czy faktycznych właścicieli. Progi wypłat, PPS, FPPS, PPLNS i późniejsze wypłaty to zasady puli nieprotokołowych. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate]
Jeśli blok zawiera transakcję świadka, BIP141 wymaga zaangażowania świadka bazy monet na jednym wyjściu: OP_RETURN zaczynając od 6a24aa21a9ed i zobowiązania 32-bajtowego. Świadek wejściowy coinbase zawiera pojedynczą 32-bajtową wartość zarezerwowaną. Jeśli istnieje więcej pasujących wyników, konsensus przyjmuje najwyższy indeks. To wyjście wiąże korzeń świadka Merkle; nie jest nagrodą dla górników. [BIP 141 – Zobowiązanie świadka oddzielonego od siebie]
Wyjście coinbase oznaczone jest specjalną flagą w zestawie UTXO i można je wydać tylko wtedy, gdy różnica wysokości wydawania i tworzenia bloków osiągnie COINBASE_MATURITY, dzisiaj 100. W związku z tym nagrodę z wysokości H można wydać po raz pierwszy w bloku H+100. Portfel może wykazywać widoczną różnicę jednego potwierdzenia, ponieważ blok generujący liczy się jako pierwszy. Dojrzałość nie jest ostatecznością. [Bitcoin Core — konsensus.h (COINBASE_MATURITY)]
Jeśli wydobyty blok wypadnie z aktywnego łańcucha z największą ilością pracy podczas reorganizacji, jego wyjścia z bazy monet znikną z aktywnego zestawu UTXO. Kolejne transakcje, w ramach których wykorzystano już dojrzałą nagrodę, również mogą być nieważne. Opóźnienie o 100 bloków ogranicza szkody wynikające z krótkich reorganizacji, ale nie gwarantuje niezmienności. Pula musi oddzielnie monitorować aktywny łańcuch, dojrzałość i swoje zobowiązania wobec górników. [Bitcoin Core — validation.cpp] [Bitcoin Core — konsensus.h (COINBASE_MATURITY)]
Pełny węzeł wymaga bazy monet na pozycji zerowej podczas walidacji, odrzuca dodatkową bazę monet, sprawdza długość skryptu i wysokość BIP34, oblicza opłaty za inne transakcje i odrzuca nagrodę powyżej nowej emisji wraz z opłatami. Weryfikuje także zakresy wartości, wagę, zaangażowanie świadka i późniejszą zapadalność wydatków. Oddzielna baza monet bez kontekstu wysokości i bloku nie należy do puli pamięci. [Bitcoin Core – transakcja.h (IsCoinBase)] [Bitcoin Core – validation.cpp] [BIP 141 – Zobowiązanie świadka segregowanego]
We wczesnych blokach można było utworzyć tę samą bazę monet txid, ponieważ wysokość nie była jeszcze obowiązkowa. BIP30 zapobiega nadpisaniu niewydanych wyników starszych transakcji, a BIP34 sprawia, że nowoczesne bazy monet mają zwykle unikalną wysokość. Genesis jest historycznym wyjątkiem: jego baza monet znajduje się w serializowanym bloku, ale kod inicjujący nigdy nie umieszcza swoich danych wyjściowych w jednorazowej bazie danych UTXO. Dlatego nie można wydać słynnych 50 BTC. [BIP 30 — Zduplikowane transakcje] [BIP 34 — Wysokość bloku w bazie monet] [Bitcoin Core — chainparams.cpp (konstrukcja genezy)]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Blok, Nagroda emisyjna za blok, Opłaty transakcyjne, Górnictwo Bitcoin, Block Template, Bitcoin. Do tego hasła prowadzą również odsyłacze z Nagroda emisyjna za blok, Potwierdzenie, Reorg, Stale Block.