Block Template

Кожен новий блок спирається на конкретного попередника. У шаблоні його позначає previousblockhash, унікальний відбиток, а height вказує позицію запропонованого блоку в ланцюжку. Інші поля містять version, версію заголовка, bits, стислий запис цільового значення для результату майнінгу, і часові дані. Це основа для складання конкретного блоку, а не незалежний перелік платежів. Ті самі транзакції після іншого попередника вже утворюють інше завдання. [1]

Анна отримує біткоїн, а потім платить ним. Якщо обидва перекази мають увійти до одного блоку, спочатку повинна стояти транзакція, що передала їй кошти, а потім та, що їх витрачає. BIP 22 — технічний документ про формат шаблону — визначає для цих зв’язків поле depends: воно посилається на попередні позиції списку transactions, нумеровані від одиниці. Список не містить coinbase, особливої першої транзакції, що нараховує винагороду майнеру. Відсутнє depends означає невідомі залежності, а не підтверджену їх відсутність. Програма не повинна вважати брак відомостей порожнім списком. [1]

Винагорода охоплює нові біткоїни за правилами відповідної висоти та комісії фактично включених транзакцій. Так її розраховує й наведений Bitcoin Core v29.0. Ця програма перевіряє блоки й транзакції та може готувати шаблони для майнінгу. У нашому прикладі транзакції дають 10000 sats; вилучення незалежної транзакції з комісією 3000 sats залишає 7000 sats комісій. Sats — дрібні одиниці біткоїна. Поле coinbasevalue вказує найбільшу винагороду, яку майнер може нарахувати собі для початкового добору транзакцій. Якщо добір змінюється, цю суму потрібно перерахувати. Розрахунок має виходити з фактичних комісій, а не суми для старого вмісту. [4] [1]

Блок також містить криптографічні відбитки для перевірки даних. BIP 141 описує witness commitment — криптографічну прив’язку до даних witness, серед яких є, наприклад, підписи, що доводять право витратити кошти. Вона обчислюється з ідентифікаторів wtxid, які охоплюють ці дані. Bitcoin Core 29 надає default_witness_commitment для незміненого шаблону. Після зміни відповідних транзакцій чи їхнього порядку цю прив’язку треба перевірити або перерахувати. Merkle root — спільний відбиток транзакцій у заголовку — також потрібно обчислити з остаточних ідентифікаторів TXID, зокрема ідентифікатора зміненої coinbase. Стара печатка не підходить до зміненого вмісту. [5] [3]

Місце в блоці обмежене, а майнер обирає його вміст. Bitcoin Core v29.0 оцінює пакети пов’язаних транзакцій, їхню вагу як міру навантаження даними та sigops — операції перевірки підписів, які враховують у ліміті блоку. Налаштування blockmaxweight і blockmintxfee впливають на розмір створюваного блоку й потрібну ставку комісії. Це політика добору. Платіж, пропущений з цієї причини, не обов’язково порушує правила мережі. Власні налаштування майнера також не збільшують мережевих лімітів, які перевіряють інші вузли. [4] [3]

У BIP 23 поле mutable перелічує зміни, які дозволяє сервер, наприклад коригування часу чи додавання транзакцій. Це домовленість про роботу з конкретним шаблоном. Дозвіл не скасовує консенсусу — правил дійсності, які інші учасники перевіряють незалежно. Попередник, час, складність і транзакції все одно мають бути правильними. Доступ до шаблону також не означає, що кожен підключений пристрій може довільно змінювати вміст; це залежить від організації системи й отриманого завдання. [2]

Під час обчислень інший майнер може продовжити ланцюжок. Щоб працювати над продовженням останнього прийнятого блоку, недостатньо замінити відбиток попередника у старому шаблоні. Деякі транзакції вже можуть бути підтверджені, змінюються висота та інші умови. BIP 23 описує expires як часовий ліміт роботи, а prevblock — як дозвіл використовувати її з іншим попередником. Навіть такий дозвіл не замінює перевірки: слід заново оцінити транзакції, винагороду та весь новий контекст. [2]

Помилку у власному проєкті краще знайти до тривалого пошуку. Режим proposal за BIP 23 дозволяє подати його на перевірку без дійсного Proof of Work, тобто без уже знайденого результату, що доводить потрібну обчислювальну роботу. Позитивна оцінка не означає, що блок знайдено чи поширено, і не гарантує постійного місця в ланцюжку. Вона означає проходження відповідної попередньої перевірки. Завершений блок під час подання ще має пройти належну валідацію, зокрема перевірку доказу роботи. [2]