Поточним процесом керує розгорнутий BIP 3. Кожен може написати пропозицію, але номер призначається, а документ публікується редакторами BIP. BIP поділяються на специфікаційні, інформаційні та процесні, проходять стани Draft, Complete, Deployed і Closed і залишаються рекомендацією авторів; Справжнє впровадження відбувається лише через впровадження, використання та, можливо, активацію за межами самого репозиторію. (Informational)
BIP є публічним документом пропозиції щодо біткойнів. Він може визначати технічну функцію, правило сумісності, процес, рекомендацію або історичний запис. Репозиторій дає дизайну стабільну точку відліку та зберігає історію змін. BIP не є законом, командою протоколу чи автоматичним оновленням; вузол забезпечує виконання лише правил, які містяться в програмному забезпеченні, яке він фактично запускає.
BIP 3 під назвою Оновлений процес BIP має статус Розгорнуто та замінив BIP 2. Процес уточнив робочий процес, обмежив простір для прийняття рішень редакторами, замінив стару категорію Standards Track на категорію Specification і спростив статуси. У той же час тут прямо сказано, що репозиторій є засобом публікації та архівом, а не системою голосування чи лічильником прийнятності.
Робота починається ще до GitHub. Автор має переглянути старіші пропозиції та обговорити конкретну ідею в списку розсилки щодо розробки біткойнів. Тільки достатньо опрацьована пропозиція надсилається як пул-запит без власного номера. Редактор BIP присвоює номер, якщо текст тематично релевантний, правильно відформатований і явно виходить за рамки ідеї; потім публікує його шляхом об’єднання в репозиторій.
Специфікація BIP встановлює реалізовані технічні правила для функціональності або сумісності; він повинен мати еталонну реалізацію та комплексні тестові вектори перед станом Complete. Інформаційний BIP описує проектну проблему, рекомендацію або інформацію. Process BIP змінює процес навколо Bitcoin і після розгортання може функціонувати як документ процесу, що постійно оновлюється.
Чернетка означає пропозицію в розробці. Complete говорить, що автори вважають заплановану роботу завершеною і рекомендують прийняти або реалізувати; для специфікації BIPu повинні бути документи щодо впровадження та тестування. Розгорнутий означає задокументоване активне використання або, у випадку процесу BIP, необхідний приблизний консенсус. Закрито вказує на документ, над яким більше не працюють або не використовують; залишається збереженим для історії.
Редактори BIP переглядають обсяг, формат, попереднє обговорення, ліцензію та готовність, призначають номери та зберігають метадані. Відповідно до BIP 3, вони не повинні вирішувати, чи буде прийнята пропозиція. Таким чином, проста публікація суперечливого BIP не підтверджує його безпеки, коректності, популярності чи консенсусу спільноти.
Номер слугує в основному стабільним орієнтиром. BIP 39 є широко використовуваним мнемонічним стандартом, BIP 141 описує правила SegWit, BIP 174 визначає PSBT, а BIP 50 є результатом розколу в березні 2013 року. Інші пронумеровані BIP залишаються чернетками або закритими. Сама цифра нічого не говорить про важливість, реалізацію чи схвалення.
Специфікація може існувати без робочої реалізації, експериментальне програмне забезпечення може реалізовувати проект, а розгортання чи активація є окремими подіями. Для консенсусних змін різниця є вирішальною: один BIP може визначати нові правила, інший спосіб їх розгортання, і вузол починає їх застосовувати лише тоді, коли це визначається його програмним забезпеченням та умовами активації.
BIP 141 — це специфікація BIP, правила якої стали частиною консенсусу біткойнів після активації SegWit. BIP 174 — це формат взаємодії гаманців і підписувачів без зміни дійсності блоків. БІП 50 документує інцидент. BIP 3 сам по собі є BIP процесу. Тому речення «BIP отримано» може означати принципово різні речі для різних типів.
Сучасний BIP містить такі метадані, як статус, тип, дата присвоєння номера, ліцензія, посилання для обговорення, версія та, можливо, Requires, Replaces і Proposed-Replacement. Після завершення більш значні зміни записуються в журнал змін із версіями, подібними до семантичного керування версіями. Зворотна несумісна зміна до зрілої специфікації зазвичай повинна отримувати новий BIP, а не тихо змінювати значення старого числа.
Завжди починайте з поточної версії в офіційному репозиторії, а не зі знімка екрана чи старої статті. Перевірте тип, статус, версію, авторів, обговорення, залежності та журнал змін. Потім самостійно перевірте підтримку у відповідному програмному забезпеченні та, для консенсусного дизайну, розгортання та активацію. Ключове питання полягає не в тому, «чи існує BIP?», а в тому, «що саме він визначає, хто його впроваджує та які докази показують, що він дійсно активний?».
Для повної картини прочитайте також Soft Fork, Правила консенсусу, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. На цю статтю також посилаються Soft Fork, Війна за розмір блока, Bitcoin Core.