387 / 736GAVIN

Gavin Andresen

Ранний разработчик, создатель faucet и автор BIP

Gavin Andresen помогал людям попробовать Bitcoin, а разработчикам — продолжать его улучшать. Он раздавал монеты новичкам, поддерживал программу и предлагал изменения правил. Его история показывает, почему даже влиятельный разработчик не может решать за всю сеть.

Gavin Andresen — ранний разработчик Bitcoin и бывший главный сопровождающий его программного проекта. Он создал Bitcoin Faucet, сервис раздачи монет для знакомства с ними, и написал BIP 16 и BIP 101. Разная судьба этих предложений помогает отличать замысел от принятого правила.

Программа не поддерживает себя сама, когда создатель проекта отходит от дел. Кто-то должен координировать исправления, тестирование и новые выпуски. В ранние годы Bitcoin эту ответственность после Сатоши взял на себя Gavin Andresen. Так его описывает и профиль MIT к встрече 17 ноября 2015 года, где главным сопровождающим уже назван Wladimir van der Laan. Это роль в разработке программы, а не владение сетью. Старая биография также не доказывает нынешнего доступа к репозиторию — общему хранилищу исходного кода. [1]

Новичок может понимать цифровые деньги, но без монет трудно попробовать их получение и отправку. Андресен решал эту проблему с помощью Bitcoin Faucet. Сервис был объявлен 11 июня 2010 года, начинал с 1 100 BTC и предлагал пять монет для пробы. Посетителю не требовалось ждать результата майнинга или искать продавца. Faucet раздавал существующие средства, а не создавал новые биткоины или награду за блок. Он облегчал первое знакомство, не меняя правил выпуска денег. [2]

В ответе от 11 июня 2010 года Андресен уточнил ограничение: пять монет на IP-адрес, а не каждый день. IP-адрес обозначает соединение в компьютерной сети; это не адрес биткоин-кошелька и не надёжный список отдельных людей. Защита сервиса поэтому не была проверкой личности. CAPTCHA, задание для различения человека и автоматической программы, тогда обсуждалась как возможная дополнительная мера. Начальное устройство сервиса нужно отличать от последующих изменений, не переписывая прошлое по образцу сегодняшних услуг. [2]

Другой вклад касался отдельной практической задачи. Получатель может требовать несколько подписей, прежде чем разрешить тратить деньги. Должен ли отправитель каждый раз работать со всем этим правилом? BIP 16 от 2012 года описывает Pay to Script Hash: платёж ссылается на хеш, короткий цифровой отпечаток скрипта с условиями. BIP — нумерованное предложение по улучшению Bitcoin. Сам скрипт, здесь названный redeemScript, предоставляет уже тот, кто тратит средства. Условия сохраняются; меняется момент их предъявления и ответственная за это сторона. [3]

Представьте кассу, для открытия которой нужно согласие нескольких людей. Показать её правила недостаточно, чтобы получить деньги. Аналогично BIP 16 от 2012 года требует проверить хеш предоставленного redeemScript, а затем исполнить его условия. Знание скрипта не заменяет необходимых подписей. Есть и технический предел в 520 байтов для этого вложенного скрипта; байт — единица размера данных. Новичку важно различать две проверки: предъявить верное правило и иметь то, что оно требует. [3]

В 2015 году Андресен представил BIP 101 с предложением постепенно увеличивать максимальный размер блока. Документ называет это Hard Fork: изменением, при котором старые правила отвергали бы часть блоков, разрешённых новыми. Реестр отмечает предложение как Closed, то есть закрытое. Напротив, BIP 16 имеет статус Deployed — внедрённый. Номер BIP или известное имя автора поэтому не доказывают активации. Читая предложение, нужно выяснить и то, начали ли его правила действительно применяться. [4] [3]

Почему увеличение блоков вызывало споры? Более крупный блок вмещает больше транзакций, но его данные необходимо передать, получить и проверить. Поэтому BIP 101 от 2015 года обсуждает расходы на передачу и риск преимуществ для крупных операторов. Человек с медленным соединением может находиться в иных условиях, чем большая майнинговая компания. Ожидания автора относительно технического прогресса — аргумент в пользу предложения, а не измеренный результат для любых будущих обстоятельств. Вопрос в балансе между вместимостью и возможностью самостоятельно проверять сеть. [4]

Bitcoin.org объясняет, что разработчики не могут навязать пользователям изменение правил: люди выбирают программу сами. Для совместной работы участники должны сохранять совместимость правил. Андресен мог написать предложение, подготовить код и убеждать других, но не мог единолично изменить Bitcoin для всех. Его работу разумно оценивать по конкретным вкладам: что давал сервис, что делал код и что приняла сеть. Прежние заслуги не доказывают автоматически правильности каждого последующего утверждения. [5]

Для полной картины прочитайте эту статью вместе с Laszlo Hanyecz, Amir Taaki, Satoshi Nakamoto. На эту статью также ссылаются Satoshi Nakamoto, Laszlo Hanyecz, Amir Taaki.

DOC · 001MIT Media Lab — MLTalks developer biographies (2015)Документация DOC · 002Gavin Andresen — Original Bitcoin Faucet announcement and replies (2010)Документация DOC · 003Gavin Andresen — BIP 16: Pay to Script HashДокументация DOC · 004Gavin Andresen — BIP 101: Increase maximum block sizeДокументация DOC · 005Bitcoin.org — About bitcoin.orgДокументация
Обновлено: Сначала источники · Не является инвестиционной рекомендацией