Jeff Garzik

На GitHub Jeff Garzik використовує ім’я jgarzik. Його роботу можна простежити в окремих репозиторіях — відкритих сховищах коду та історії його змін. Це корисніше, ніж приписувати одній людині нечітку роль того, хто «керує Біткоїном». Для програми важливо зрозуміти її функції та конкретну версію; для пропозиції — що саме вона мала змінити. Сам профіль розробника не визначає, яку версію програми запускатимуть інші люди. [1]

Вступний файл README описує cpuminer Гарзіка як програму для майнінгу Біткоїна за допомогою CPU, тобто процесора комп’ютера. Багатопотоковість дозволяє розподіляти обчислення між потоками, що виконуються одночасно. Проєкт pooler/cpuminer для Litecoin і Bitcoin прямо вказує, що походить від цієї програми. Запозичення коду з подальшим окремим розвитком називають форком проєкту. Саме по собі воно не розділяє мережу Біткоїна, а додані пізніше функції могли бути відсутні в оригіналі Гарзіка. [2] [3]

Інший приклад — Picocoin. Він містить libccoin, бібліотеку мовою C, функції якої розробники можуть використовувати у біткоїн-застосунках. Проте README позначає пов’язані HD-гаманець і вузол brd як WIP, тобто незавершені. HD-гаманець виводить сімейство ключів зі спільної основи, а вузол призначений для зв’язку з мережею Біткоїна. Репозиторій архівували 15 лютого 2024 року. Це корисне історичне джерело, але доступність коду сама по собі не доводить, що продукт готовий, підтримується й безпечний для власних заощаджень. [4]

Уявімо вузол, який хоче дізнатися, які непідтверджені транзакції знає підключений до нього вузол. BIP 35 Гарзіка розв’язує це завдання: повідомлення mempool запитує список, відповідь inv містить ідентифікатори транзакцій — їхні хеші, а getdata дозволяє потім запросити самі дані. Mempool — локальна «черга очікування» транзакцій до підтвердження, а не єдиний список для всього світу. Команда getrawmempool у документації Bitcoin Core також повертає вміст конкретного вузла. Наявність транзакції в ньому ще не означає підтвердження у блоці. [5] [8]

Розмір блоків впливає і на місце для транзакцій, і на ресурси для їх передавання та перевірки. У BIP 100 Garzik, Tom Harding і Dagur Valberg Johannsson запропонували змінювати ліміт за голосами, записаними майнерами у блоки. Перерахунок мав відбуватися кожні 2016 блоків із вимогою 75% підтримки у блоках та обмеженими кроками зміни. Отже, це не голосування за кількістю людей. Реєстр позначає пропозицію як Closed, тобто закриту; її опис не доводить, що механізм прийняла вся мережа Біткоїна. [6]

Візьмімо звичайний вузол, який досі перевіряє початковий ліміт 1 MB. Отримавши більший блок, він його відхилить, навіть якщо майнер підтримує вищу межу. Саме про такий поділ попереджає BIP 100. Голос у блоці — дані для нової програми, а не команда, що переписує стару. Зміна, яка дозволяє блоки, відхилювані попередніми правилами, є Hard Fork. Це інше значення слова fork, ніж просте створення похідного проєкту на GitHub. [6]

BIP 102 Гарзіка пропонував інший підхід: один раз підняти ліміт до 2 MB. Активація вимагала б одночасного виконання часової умови та сигналу підтримки у 95% з останніх 1000 блоків. Виконання цих умов саме по собі не змінило б старі програми перевірки: вони й далі відхиляли б більші блоки. Ця пропозиція теж має статус Closed. Вона описує запропоновану зміну, а не чинні сьогодні правила розміру біткоїн-блоків. [7]

У кожному BIP варто читати і зміст, і статус. BIP 35 позначено як Deployed, тобто впроваджений, на рівні Peer Services — сервісів і зв’язку між вузлами. BIP 100 та BIP 102 мають статус Closed на рівні Consensus (hard fork), бо стосуються того, які блоки вузли визнають дійсними. Один автор може працювати в обох напрямах із різними результатами. Успішне впровадження мережевого повідомлення не означає одночасного прийняття всіх його пропозицій щодо правил. [5] [6] [7]