Coinbase — це консенсусний тип транзакції, а не компанія Coinbase або звичайний платіж. Разом із блоком вузол перевіряє нульовий аутпойнт, висоту відповідно до BIP34, максимальну винагороду, нульову позицію, зрілість і можливе зобов’язання SegWit. Окремо в mempool не приймається.
Блок повинен містити принаймні одну транзакцію, а coinbase може бути лише першою. Bitcoin Core розпізнає його за точною структурою: один вхід із 32 нульовими байтами в хеші попереднього виводу та індексом 0xffffffff. Введення не розблоковує існуючий UTXO, тому він не має звичайного підпису чи попереднього значення. Транзакція все ще може мати кілька виходів, звичайну версію, а також час блокування та спеціальний txid. [Довідка розробника біткойнів — вхідні дані Coinbase] [Довідка розробника біткойнів — ланцюг блоків] [Ядро біткойнів — transaction.h (IsCoinBase)]
Сума виходів coinbase не може перевищувати GetBlockSubsidy для цієї суми плюс комісії за всі інші дійсні транзакції в блоці. Тільки нещодавно випущений компонент винагороди створює нові сатоші; комісії конвертують існуючі сатоші. Майнер може претендувати на менше, і різниця зникне назавжди, але один сатоші, що перевищує ліміт, робить весь блок недійсним. Консенсус не визначає поділ між пулом, майнерами або декількома сценаріями. [Bitcoin Core — validation.cpp] [Bitcoin Core — miner.cpp]
Починаючи з BIP34, coinbase scriptSig має починатися з поточної висоти блоку як мінімально закодованого числа CScript. Весь scriptSig становить від 2 до 100 байт. Решта може містити додатковий nonce, тег пулу або зобов’язання щодо об’єднаного майнінгу, але це не виходить за межі правил: неправильна висота чи довжина зробить блок недійсним, а вбудовані коди операцій підпису можуть використовувати ліміт sigop. [Довідка розробника біткойнів — вхідні дані Coinbase] [BIP 34 — Висота блоку в coinbase]
ASIC змінює nonce у заголовку, але 32-розрядний простір швидко закінчується. Таким чином, програмне забезпечення для майнінгу перетворює додатковий nonce на базу монет; це змінить його txid, кореневу транзакцію Merkle і згодом заголовок блоку, тому він отримає новий хеш-простір. Протоколи пулу поділяють цей простір між працівниками, щоб їхні частки не конфліктували. Додатковий nonce є координаційною частиною, а не додатковим викидом. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate] [Stratum V2 — Специфікація протоколу майнінгу]
Виходи Coinbase використовують загальні сценарії блокування та можуть бути розподілені між кількома адресами чи політиками. Пул може здійснювати оплату на адресу отримання, негайно розділити дохід або зарезервувати вихід для оператора. Однак вузол перевіряє суми та сценарії, а не контракти чи фактичних власників. Пороги виплат, PPS, FPPS, PPLNS і пізніші зняття є правилами непротоколного пулу. [Bitcoin Core — miner.cpp] [BIP 22 — getblocktemplate]
Якщо блок містить трансакцію-свідок, BIP141 вимагає зобов’язання-свідка coinbase в одному виході: OP_RETURN, починаючи з 6a24aa21a9ed, і 32-байтове зобов’язання. Вхідний свідок coinbase містить одне 32-байтове зарезервоване значення. Якщо відповідних результатів більше, консенсус отримує найвищий індекс. Цей висновок прив’язує свідковий корінь Меркла; не винагорода для майнерів. [BIP 141 — Зобов’язання окремого свідка]
Вихід coinbase позначається спеціальним прапорцем у наборі UTXO і може бути витрачений лише тоді, коли різниця у висоті витратного та створюючого блоків досягне COINBASE_MATURITY, на сьогоднішній день 100. Тому нагороду з висоти H можна витратити вперше в блоці H+100. Гаманець може показувати явну різницю в одне підтвердження, оскільки блок, що генерує, зараховується першим. Зрілість - це не остаточність. [Bitcoin Core — consensus.h (COINBASE_MATURITY)]
Якщо видобутий блок випадає з активного ланцюга з найбільшою роботою під час реорганізації, його виходи coinbase зникнуть з активного набору UTXO. Наступні транзакції, які вже витратили зрілу винагороду, також можуть бути недійсними. Затримка в 100 блоків обмежує шкоду від коротких реорганізацій, але не гарантує незмінності. Пул повинен окремо відстежувати активний ланцюг, зрілість і свої зобов’язання перед майнерами. [Bitcoin Core — validation.cpp] [Bitcoin Core — consensus.h (COINBASE_MATURITY)]
Повний вузол потребує coinbase на нульовій позиції під час перевірки, відхиляє додаткову coinbase, перевіряє довжину scriptSig і висоту BIP34, обчислює комісії за інші транзакції та відхиляє винагороду за новий випуск плюс комісії. Він також перевіряє діапазони значень, вагу, зобов’язання свідків і пізнішу зрілість витрат. Окрема база монет без контексту висоти та блоку не належить до мемпулу. [Bitcoin Core — transaction.h (IsCoinBase)] [Bitcoin Core — validation.cpp] [BIP 141 — Segregated Witness commitment]
У ранніх блоках можна було створити ту саму coinbase txid, оскільки висота ще не була обов’язковою. BIP30 запобігає перезапису невитрачених вихідних даних старішої транзакції, а BIP34 робить сучасні бази монет унікальної висоти. Genesis є історичним винятком: його coinbase знаходиться в серіалізованому блоці, але код ініціалізації ніколи не поміщає свій результат у витратну базу даних UTXO. Тому знамениті 50 BTC не можна витрачати. [BIP 30 — Дублікати транзакцій] [BIP 34 — Висота блоку в coinbase] [Bitcoin Core — chainparams.cpp (побудова генезису)]
Для повної картини прочитайте також Блок, Емісійна винагорода за блок, Комісії за транзакції, Майнінг, Block Template, Bitcoin. На цю статтю також посилаються Емісійна винагорода за блок, Підтвердження, Reorg, Stale Block.