Gavin Andresen

Програма не підтримує себе сама, коли творець проєкту відходить від справ. Хтось має координувати виправлення, тестування та нові випуски. У ранні роки 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]