Jeff Garzik — разработчик, известный по аккаунту jgarzik. Он работал над биткоин-программами и BIP — документами, описывающими конкретные изменения или процедуры. Его вклад показывает, как развивается Биткоин: автор может написать код и предложить правило, но не приказать всей сети его принять.
На 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]
Для полной картины прочитайте эту статью вместе с Cynthia Lummis, Mike Hearn, Война за размер блока. На эту статью также ссылаются Mike Hearn.