396 / 736LUKE

Luke Dashjr

Розробник, відомий як luke-jr

Перш ніж шукати новий блок, майнер має знати, як його зібрати й що дозволено змінювати. Luke Dashjr допомагав описати саме цю взаємодію програм. Його ім’я також пов’язане з Bitcoin Knots і порядком публікації пропозицій щодо вдосконалення Bitcoin.

Luke Dashjr, відомий як luke-jr, — розробник Bitcoin. Його робота стосується інтерфейсів майнінгу, Bitcoin Knots і документів BIP — публічно описаних пропозицій та стандартів. Ці внески показують, як людина може суттєво впливати на розробку, не ухвалюючи рішень за всю мережу.

На GitHub Luke Dashjr користується ім’ям luke-jr. Цей сервіс зберігає вихідний код, пропозиції змін та їхню історію. Профіль містить посилання, зокрема, на Bitcoin Knots і програму для майнінгу BFGMiner. Однак профіль не є повною біографією всіх учасників чи переліком роботи лише однієї людини. Конкретні зміни й авторство специфікацій дають точніші докази. Далі йтиметься про практичні питання: як передати майнеру завдання, завчасно помітити помилку та з’ясувати, чи справді використовується пропозиція. [1]

Майнінг передбачає багаторазові обчислення над підготовленим блоком, доки результат не відповідатиме потрібній складності. Але спочатку треба зібрати його вміст. BIP 22, автором якого є Dashjr, описує getblocktemplate — інтерфейс, через який програма отримує структуру запропонованого блоку разом із транзакціями. Вона не мусить отримувати лише короткий заголовок для хешування: може зібрати блок і внести дозволені зміни. Це схоже на отримання матеріалів для цілого замовлення замість окремої операції. Правила дійсності готового блоку залишаються обов’язковими. [2]

Уявіть транзакцію, яка витрачає вихід іншої транзакції в тому самому запропонованому блоці. Ця попередня транзакція теж має бути включена. Поле depends у BIP 22 зазначає такі залежності. Якщо його немає, залежності невідомі; програма не може вважати, що їх немає. Так само слід трактувати відсутню комісію або sigops — кількість операцій перевірки підписів, яку враховують у лімітах блоку. Відсутність інформації не дорівнює нульовому значенню. Ця начебто дрібниця допомагає не зібрати недійсний блок через неправильне розуміння отриманих даних. [2]

BIP 23 від Dashjr розширює інтерфейс для пулів, що об’єднують роботу майнерів. Необов’язковий режим proposal дозволяє передати підготовлений блок серверу на перевірку, за винятком доказу роботи. Так можна знайти помилку у вмісті до початку витратного пошуку відповідного результату обчислень. Позитивна відповідь означає лише, що пропозиція відповідає правилам цього сервера. Потрібний доказ роботи й оцінка інших вузлів ще попереду. Попередня перевірка не означає, що новий блок уже видобуто. [3]

Інша сфера — запровадження змін до правил. BIP 8, автори якого Shaolin Fry і Luke Dashjr, визначає етапи за висотою блоку, тобто його місцем у ланцюзі. Параметр lockinontimeout задає, чи вимагатиме останній період сигналізації майнерів за визначених умов, щоб зафіксувати майбутню активацію. LOCKED_IN — це не ACTIVE: перший стан забезпечує подальший перехід у межах цього механізму, а нове правило застосовується лише в другому. Це різниця між призначенням моменту набуття чинності та його настанням. Саме написання пропозиції не перемикає всю мережу. [4]

Bitcoin Knots — програма для власного вузла: комп’ютера, який завантажує та повністю перевіряє блоки й транзакції. Документація описує перенесення розробок із Bitcoin Core та можливість додаткових змін; також можуть входити гаманець і графічний інтерфейс. На час цієї ревізії офіційний сайт називає Dashjr головним відповідальним за підтримку проєкту. Відповідальність за програму не дає можливості наказати всій мережі прийняти нові правила. Обираючи програму, варто читати про функції й налаштування кожного випуску, а не припускати, що вони завжди поводяться однаково. [5] [6]

Завантажуючи Bitcoin Knots, потрібно перевірити, чи отримано файл саме від очікуваного видавця. Сайт рекомендує підписи OpenPGP і звіряння відкритих ключів із незалежних джерел. Відкритий ключ перевіряє цифровий підпис, але спершу треба встановити, кому цей ключ належить. Правильний підпис із належно перевіреним ключем підтверджує походження файлу й незмінність підписаних даних. Він не гарантує відсутності помилок у програмі. Перевірка походження, аналіз коду й вибір налаштувань — різні завдання. [6]

Dashjr також написав BIP 2 про підготовку й публікацію пропозицій. Нині його замінює BIP 3 від Murch. Він прямо пояснює: опублікований BIP сам собою не виражає консенсусу спільноти Bitcoin чи загальної рекомендації щодо впровадження. Пропозиція може залишитися на папері, увійти до певної програми або згодом змінити правила, які учасники спільно забезпечують. Надання номера нічого не активує. Читаючи новину про новий BIP, запитайте також, хто його реалізував і чи справді ним користуються. [7] [8]

Для повної картини прочитайте також Matt Corallo, Peter Todd, Satoshi Nakamoto. На цю статтю також посилаються Matt Corallo, Peter Todd.

DOC · 001GitHub — Luke DashjrДокументація DOC · 002BIP 22 — getblocktemplate fundamentalsДокументація DOC · 003BIP 23 — pooled miningДокументація DOC · 004BIP 8 — lock-in by heightДокументація DOC · 005Bitcoin Knots — project documentationДокументація DOC · 006Bitcoin Knots — official websiteДокументація DOC · 007BIP 2 — revised processДокументація DOC · 008BIP 3 — updated processДокументація
Переглянуто: Спочатку джерела · Не інвестиційна порада