getblocktemplate — інтерфейс, через який програма отримує від вузла Bitcoin дані для складання кандидата на блок. Він використовує JSON-RPC: запит і структуровану відповідь між програмами. Звичайний режим надає шаблон; інший дозволяє попередньо оцінити власну пропозицію блоку. Жоден із них сам не шукає доказу роботи.
У звичайному режимі mode=template програма Петра отримує, наприклад, попередній блок, транзакції та дозволену винагороду. Це запропоноване завдання, а не вже знайдений блок. Програмі ще потрібно створити coinbase, особливу першу транзакцію, що призначає винагороду, та завершити складання блоку. Заголовок стисло відображає дані блоку. Потім програма шукає хеш — числовий криптографічний відбиток цього заголовка, який відповідатиме цілі майнінгу й становитиме Proof of Work, доказ обчислювальної роботи. Сам getblocktemplate не приймає адреси виплати й не запускає обчислень майнінгового пристрою. Успішна відповідь ще не означає, що Петро майнить. [1]
Уявімо, що вузол надсилає дані у формі, незрозумілій програмі Петра. Тому запит оголошує підтримувані правила в полі rules. Перевірений тут Bitcoin Core v29.0 вимагає segwit, а для тестової мережі Signet також signet. SegWit, зокрема, змінює обробку даних для перевірки транзакцій. Просто додати правильне слово недостатньо: програма має вміти їх обробляти. capabilities повідомляє про інші можливості інтерфейсу й не замінює rules. Точні вимоги залежать від реалізації та версії, якими користуються. [2]
Поле data містить повний запис транзакції, упорядкований для передавання між програмами. Таке впорядкування називають серіалізацією. Байти, основні одиниці цих даних, записані шістнадцятково за допомогою цифр 0–9 і літер a–f. Відповідь також містить короткі ідентифікатори транзакцій. За технічним документом BIP 145 txid обчислюється без даних witness, тоді як hash їх включає. Witness містить, наприклад, підписи, що доводять право витратити кошти. Головний Merkle root, узагальнений відбиток транзакцій у заголовку блоку, використовує txid, а не witness hash. Переплутати ці поля — не просто помилитися в назві: це може дати неправильний загальний відбиток і зробити складений блок недійсним. [3]
Петрові не потрібно засипати вузол запитаннями, чи щось змінилося. Long polling залишає запит відкритим, доки сервер не захоче замінити попередні дані. Програма отримує longpollid і повертає його без змін. За цим значенням сервер визначає, на яку зміну чекає програма. Програма не повинна намагатися вивести зміст із його символів. BIP 22 передбачає тривалий час очікування. Повторні неповні або некоректні відповіді потребують пауз між спробами, а не миттєвого повторення в циклі. Тож мовчазне очікування саме собою не є збоєм. [4]
Навіть звичайний повторний запит не гарантує щойно відібраного вмісту. Bitcoin Core v29.0 тримає підготовлений шаблон у кеші. Він перебудовує його, коли змінюється попередній блок або коли змінився mempool, місцевий набір непідтверджених транзакцій, і від підготовки минуло понад п’ять секунд. Час у заголовку може оновлюватися окремо. Тому Петро може знову отримати той самий набір транзакцій; це не означає зависання вузла. Така поведінка конкретної версії також не обіцяє унікального майнінгового завдання на кожен виклик. [2]
Петро змінив складання блоку й хоче виявити помилки до витратного пошуку. У режимі proposal він передає весь блок шістнадцятковим записом у полі data. Bitcoin Core v29.0 перевіряє також Merkle root, але ще не вимагає знайденого дійсного Proof of Work, доказу обчислювальної роботи. Якщо пропозиція не продовжує останній блок ланцюга, який зараз використовує вузол, повертається inconclusive-not-best-prevblk. Це означає, що бракує передумови для цієї перевірки, а не що проведено повну оцінку дійсності. Попередня перевірка також не поширює блок мережею. [2]
Коли програма знаходить потрібний доказ роботи, вона може подати весь блок через submitblock. hexdata містить цілий серіалізований блок у шістнадцятковому записі, а не лише його заголовок чи відбиток. Документація Bitcoin Core 29 вказує null у разі прийняття та текстовий результат за специфікацією в інших випадках. Необов’язковий другий параметр dummy ігнорується; він не встановлює винагороду. Прийняття вузлом не гарантує незмінного підтвердження: подальший розвиток ланцюга може змінити те, яка гілка залишиться головною. [5]
Щойно запущений вузол може ще не завантажити й не перевірити потрібну історію. У головній мережі, mainnet, Bitcoin Core v29.0 відмовляється видавати шаблон без під’єднаних вузлів-партнерів або під час початкової синхронізації IBD (initial block download). Ідеться про готовність вузла працювати з поточною мережею, а не про відхилення конкретного блоку. Тому під час пошуку причини розрізняємо long poll в очікуванні, неготовий вузол і результат перевірки пропозиції. Усі випадки можуть виглядати як «немає нової роботи», але потребують різних дій. [2]
Для повної картини прочитайте також Block Template, Майнінг, Stratum V2, Extranonce, Bitcoin, Bitcoin Core. На цю статтю також посилаються ASIC Miner, Solo Mining, Job Negotiation.