BIP — скорочення від Bitcoin Improvement Proposal. Це документ про технічне рішення, процедуру або важливі відомості щодо Bitcoin. Інші можуть його вивчити, критично оцінити й за потреби застосувати; публікація автоматично не змінює ані програми, ані правила мережі.
Анна готує платіж на комп'ютері, але хоче підписати його апаратним гаманцем іншого виробника. Обидві програми мають розуміти передані дані. Саме таку проблему розв'язує BIP 174: він описує PSBT, спільний формат для передавання незавершеної транзакції та відомостей, потрібних для підпису. Розробники можуть спиратися на один документ замість того, щоб окремо вигадувати несумісні формати. Це одна з практичних причин існування BIP. [8]
Різні номери означають різну роботу. BIP39 описує створення слів відновлення та їх перетворення на seed — початкові дані для виведення ключів гаманця. BIP 141 описує SegWit, зміну правил обробки транзакцій, що набула чинності після активації в мережі. BIP 174 допомагає гаманцям передавати транзакції для підпису без зміни правил дійсності блоків. BIP 50 натомість документує причини та усунення інциденту березня 2013 року, коли мережа тимчасово розділилася. Отже, не кожен BIP пропонує нове правило Bitcoin. [6] [7] [8] [9]
Описати рішення, запрограмувати його та почати використовувати — різні кроки. Опис називають специфікацією, програмний код — реалізацією. Гаманець може експериментувати з чернеткою; іншу пропозицію ще може не використовувати жодна програма. Для змін правил дійсності блоків потрібна також активація — момент, з якого відповідне ПЗ починає їх застосовувати. Публікація тексту не оновлює автоматично ваш вузол, тобто комп'ютер, що перевіряє правила мережі. [7] [10]
Номер насамперед допомагає знайти потрібний документ і долучитися до тієї самої дискусії. Більше число не означає кращу пропозицію чи рекомендоване оновлення. Навіть пронумерований документ може залишитися незавершеним або бути відкладений. Якщо сервіс рекламує підтримку певного BIP, треба ще з'ясувати, про яку функцію йдеться і чи справді її має конкретна версія програми. [2]
Автори спершу вивчають попередні роботи й обговорюють ідею в Bitcoin Development Mailing List — відкритій поштовій дискусії розробників. Зауваження можуть виявити проблему ще до написання довгого тексту. Достатньо опрацьовану пропозицію подають до спільного сховища bitcoin/bips на GitHub як pull request, тобто запит на включення. Автори не обирають номер самостійно: редактор призначає його після перевірки теми, формату та готовності документа. [1]
BIP Editors дбають про опубліковані документи: перевіряють попереднє обговорення, зрозумілість, формат і ліцензію, призначають номери та підтримують записи. Це не дає їм права вирішувати, яким ПЗ вам користуватися або які правила прийматиме ваш вузол. Наявність у сховищі не гарантує безпеки чи згоди спільноти. Реальне використання залежить від окремих проєктів та учасників мережі. [1]
Якщо новина каже, що BIP схвалено, відкрийте документ і з'ясуйте, що сталося. Йому лише призначили номер, автори завершили роботу чи вже є підтримка, якою користуються? Для гаманця шукайте підтвердження в документації та випусках ПЗ; для зміни правил мережі перевірте також умови й перебіг активації. Так можна відрізнити цікаву пропозицію від уже доступної функції. [10] [2]
Чинний порядок описує BIP 3, Updated BIP Process, зі статусом Deployed. Він замінив BIP 2 та спростив типи й статуси документів. Тому старі статті можуть містити назви Standards Track або Final, які не відповідають сьогоднішньому поділу. Орієнтуйтеся на актуальний файл та його історію. Сховище публікує і зберігає пропозиції, а не проводить голосування про майбутнє Bitcoin. [1] [5]
Specification описує технічні правила, за якими можна створювати сумісні програми. Перед завершенням потрібні також робоча еталонна реалізація — програма, яка показує, як втілити запропоноване рішення, — і тестові вектори — приклади вхідних даних з очікуваними результатами. Informational містить інформацію, аналіз або рекомендації. Process визначає порядок роботи, наприклад публікації самих BIP. Саме до цієї останньої групи належить BIP 3; нового формату транзакції Bitcoin він не встановлює. [1]
Draft — робота, яка ще триває. Complete означає, що автори завершили заплановане й рекомендують прийняття. Deployed вказує на доведене активне використання; для Process це може бути потрібний rough consensus — широка згода після обговорення й опрацювання обґрунтованих заперечень, а не простий підрахунок голосів. Closed позначає історичний документ, який уже не розробляють, не просувають і не використовують активно. Він залишається в архіві. Навіть Deployed не означає підтримки кожним гаманцем. [1]
У заголовку наведено авторів, тип, статус, дату призначення номера, ліцензію й посилання на обговорення. Requires перелічує потрібні інші BIP, Replaces — пропозиції, які документ має замінити, а Proposed-Replacement — можливого наступника. Після переходу до статусу Complete подальші зміни записують у Changelog, журнал змін, із датою та номером версії. Поле Version у заголовку вказує поточну версію документа. Несумісна з попереднім рішенням зміна зазвичай має отримати новий BIP, щоб той самий номер непомітно не набув іншого змісту. [1]
Для повної картини прочитайте також Soft Fork, Правила консенсусу, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. На цю статтю також посилаються Soft Fork, Війна за розмір блока, Bitcoin Core, Біткоїн-освіта.