Skip to content

Latest commit

 

History

History
392 lines (250 loc) · 60.1 KB

bip-0002.mediawiki

File metadata and controls

392 lines (250 loc) · 60.1 KB

  BIP: 2
  Title: BIP process, revised
  Author: Luke Dashjr <[email protected]>
  Translate: Nadezhda Karpova <[email protected]>
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002
  Status: Active
  Type: Process
  Created: 2016-02-03
  License: BSD-2-Clause OPL
  Replaces: 1

Table of Contents

Аннотация

Предложение по улучшению Bitcoin (BIP) - это проектный документ, предоставляющий информацию Bitcoin сообществу или описывающий новую функции Bitcoin, процессы или окружение. BIP должен предоставлять краткую техническую спецификацию функции и ее обоснование.

Мы предполагаем, что BIP станут первичными механизмами для предложения новых функций, сбора информации от сообщества по поводу проблем и для документирования проектных решений, которые вошли в Bitcoin. Автор BIP несет ответственность за достижение консенсуса внутри сообщества и за документирование несовпадающих мнений.

Поскольку BIP хранятся в виде текстовых файлов в версионированном репозитории, их история изменений является хронологическими записями.

Этот конкретный BIP заменяет BIP 1 более четким и понятным описанием процесса.

Авторские права

Этот BIP имеет двойную лицензию в соответствии с лицензией Open Publication и лицензией BSD 2.

Рабочий процесс BIP

Процесс BIP начинается с новой идеи для Bitcoin. У каждого потенциального BIP должен быть лидер (автор) - тот, кто пишет BIP, используя стиль и формат, описанные ниже, создает дискуссии на соответствующих форумах и пытается построить консенсус сообщества вокруг этой идеи.Автор должен сначала попытаться выяснить, является ли идея BIP реализуемой. Небольшие улучшения или исправления часто не требуется стандартизации между несколькими проектами;они не нуждаются в BIP и должны быть введены в соответствующий рабочий процесс разработки Bitcoin с передачей исправления в соответствующий баг-трекер Bitcoin. Для изменения Bitcoin было выдвинуто много идей, которые по разным причинам были отклонены. Первым шагом должен стать поиск прошлых дискуссий, чтобы выяснить, рассмотрена ли идея до этого, и если да, то какие проблемы возникли в ее развитии. После исследования предыдущих работ, лучший способ продолжить - опубликовать новую идею в Bitcoin development mailing list.

Публичная проверка идеи, перед переходом к написанию BIP, предназначена для сохранения времени как потенциального автора, так и сообщества. Выяснение у Bitcoin сообщества, является ли идея оригинальной, может предотвратить трату времени на разработку BIP, который потом в любом случае будет отклонен на основе предыдущих обсуждений (поиск в Интернете не всегда помогает). Это также помогает убедиться, что идея применима ко всему сообществу, а не только к автору. Просто потому, что если идея кажется хорошей автору, это не означает, что она будет работать для большинства людей в тех областях, где используется Bitcoin.

Как только автор спросил Bitcoin сообщество о том, имеет ли идея какие-либо шансы на одобрение, черновик BIP должен быть представлен всем в списке рассылки Bitcoin development mailing list. Это дает автору возможность спланировать проект BIP таким образом, чтобы он был высокого качества и должным образом сформирован, а также добавить дополнительные мысли и опасения по поводу предложения. После обсуждения предложение должно быть отправлено в BIPs git repository как запрос на включение изменений. Черновик должен быть написан в стиле BIP, описанном ниже, и назван примерно в таком стиле: «bip-johndoe-infinbitcoins», пока редактор не присвоит ему номер BIP (авторы НЕ ДОЛЖНЫ сами назначать номера BIP).

Авторы BIP отвечают за сбор отзывов сообщества как по первоначальной идее, так и по BIP, прежде чем отправлять его на рассмотрение. Однако, по возможности, следует избегать длительных открытых обсуждений среди большого публичного списка адресатов. Стратегии эффективного обсуждения включают в себя: создание отдельного SIG списка рассылки для этой темы, принятие автором BIP частных комментариев на ранних этапах проектирования, настройка страницы wiki или репозитория git и т. д., авторы BIP делают это на свое усмотрение.

Настоятельно рекомендуется, чтобы один BIP содержал одно ключевое предложение или новую идею. Чем более BIP сконцентрирован на ней, тем более успешным он может быть. Если у вас есть сомнения, разделите BIP на несколько хорошо сфокусированных предложений.

Если редактор BIP одобряет предложение, он назначает BIP номер, помечает его как «Standards Track», «Informational» или «Process», присваивает ему статус «Draft» (Черновик) и добавляет его в репозиторий git. Редактор BIP не будет необоснованно его отклонять. Причины отказа в присвоении BIP статуса включают в себя: дублирование, игнорирование правил форматирования, несфокусированность или общность, техническая необоснованность, необеспечение надлежащей мотивации или обратной совместимости, несоответствие философии Bitcoin. Для того чтобы BIP был принят, он должен соответствовать определенным минимальным критериям. Это должно быть четкое и полное описание предлагаемого усовершенствования. Улучшение должно представлять собой действительно улучшение. Предлагаемая реализация, если она применима, должна быть прочной и не должна чрезмерно усложнять протокол.

Автор BIP может обновлять Черновик в репозитории по мере необходимости. Обновления черновиков также могут отправляться автором в качестве запросов на включение.

Передача права собственности BIP

Иногда возникает необходимость передать право собственности на BIP новому автору. В общем, нам бы хотелось сохранить соавторство оригинального автора переданного BIP, но это все зависит от самого автора. Оправданной причиной для передачи права собственности является то, что у первоначального автора больше нет времени или ему больше неинтересно обновлять или в дальнейшем работать над BIP, а также если он "выпал" из сети (т.е. недоступен или не отвечает на электронную почту). Необходимая причина передачи права собственности - это то, что вы не согласны с направлением развития BIP. Мы пытаемся создать консенсус вокруг BIP, но если это невозможно, вы всегда можете представить конкурирующий BIP.

Если вы заинтересованы в приобретении права собственности на BIP, отправьте сообщение с просьбой о передаче, адресованное как оригинальному автору, так и редактору BIP. Если автор не ответит на электронную почту своевременно, редактор BIP примет одностороннее решение.

Редакторы BIP

Текущий редактор BIP -Люк Дашир, с которым можно связаться по адресу [email protected].

Ответственности и рабочий процесс редактора BIP

Редактор BIP подписан на список рассылки Bitcoin. Вся корреспонденция, связанная с BIP, должна быть отправлена на [email protected].

Для каждого нового BIP, который появляется, редактор выполняет следующие проверки:

  • Читает BIP, чтобы проверить, готов ли он. Идеи должны иметь технический смысл, даже если они не будут приняты.
  • Точно ли название описывает содержимое.
  • Был ли отправлен Черновик BIP в список рассылки разработки Bitcoin для обсуждения.
  • Обращено ли внимание на мотивацию и обратную совместимость.
  • Правильно ли назначен для данной спецификации определенный заголовок уровня.
  • Приемлемы ли условия лицензирования для BIP.
Если BIP не готов, редактор отправляет его автору для пересмотра с указанием конкретных инструкций.

После того, как BIP готов к помещению в репозиторий, он должен быть отправлен как «запрос на включение» в репозиторий bitcoin/bips, где он может получить дополнительную обратную связь.

Редактор BIP:

  • Назначает номер BIP в запросе на добавление.
  • Объединяет запрос на добавление, когда он готов.
  • Размещает BIP в README.mediawiki
Редакторы BIP должны выполнять административные и редакционные обязанности. Редакторы BIP контролируют изменения и обновляют BIP заголовки при необходимости.

Формат и структура BIP

Спецификация

BIP должны быть записаны в формате mediawiki.

Каждый BIP должен иметь следующие части:

  • Preamble -- Заголовки, содержащие метаданные о BIP (см. ниже).
  • Abstract -- Краткое (~ 200 слов) описание рассматриваемой технической проблемы.
  • Copyright/public domain -- BIP должны быть лицензированы в соответствии с условиями авторских прав (см. ниже).
  • Specification -- Техническая спецификация должна описывать синтаксис и семантику любой новой функции. Спецификация должна быть достаточно подробной, чтобы предоставить конкурентоспособную и совместимую реализацию для любой из существующих Bitcoin платформ.
  • Motivation -- Мотивация имеет решающее значение для BIP, которые хотят изменить Bitcoin протокол. Она должна четко объяснять, почему существующая спецификация протокола не подходит для решения проблемы, которую решает BIP.
  • Rationale -- Обоснование объясняет спецификацию, описывая, чем была мотивирована разработка и почему принимались конкретные проектные решения. Оно должно описывать альтернативные проекты, которые были рассмотрены и связаны с работой. Обоснование должно предоставлять доказательство достигнутого в сообществе консенсуса и описывать важные возражения или проблемы, поднятые в ходе обсуждения.
  • Backwards Compatibility -- Обратная совместимость, все BIP, которые вводят обратную несовместимость, должны включать раздел, описывающий эти несовместимости и их серьезность. BIP должен объяснить, как автор предлагает решить проблему этих несовместимостей.
  • Reference Implementation -- Справочная реализация должна быть завершена до того, как любой BIP получит статус «Final» (Финальный), однако нет необходимости реализовывать ее до того, как BIP будет принят. Лучше сначала завершить спецификацию и обоснование и достичь консенсуса до написания кода. Окончательная реализация должна включать тестовый код и документацию, соответствующие Bitcoin протоколу.

Вводная часть заголовка BIP

Каждый BIP должен начинаться с вводной части заголовка RFC 822. Заголовки должны отображаться в следующем порядке. Заголовки с «*» являются необязательными и описаны ниже. Все остальные заголовки необходимы. 

  BIP: <BIP number, or "?" before being assigned>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
  Title: <BIP title; maximum 44 characters>
  Author: <list of authors' real names and email addrs>
* Discussions-To: <email address>
* Comments-Summary: <summary tone>
  Comments-URI: <links to wiki page for comments>
  Status: <Draft | Active | Proposed | Deferred | Rejected |
           Withdrawn | Final | Replaced | Obsolete>
  Type: <Standards Track | Informational | Process>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
  License: <abbreviation for approved license(s)>
* License-Code: <abbreviation for code under different approved license(s)>
* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
* Requires: <BIP number(s)>
* Replaces: <BIP number>
* Superseded-By: <BIP number>

Заголовок Layer (только для протоколов Standard Track BIP) свидетельствует о том, к какому уровню относится данный BIP. См. BIP 123 для определений различных уровней BIP. Активация этого BIP подразумевает активацию BIP 123.

Заголовок автора содержит имена и адреса электронной почты всех авторов/владельцев BIP. Формат значения заголовка автора должен быть таким: 

  Random J. User <[email protected]>

Если авторов несколько, каждый из них должна быть упомянут отдельной строкой по правилам RFC 2822.

Пока BIP обсуждается в частных дискуссиях (обычно на этапе Черновик), в заголовке Discussionions-To (Обсуждение) указывается список рассылки или URL-адрес, где обсуждается BIP. No Discussions-To (Обсуждение отсутствует) – этот заголовок необходим, если BIP обсуждается в частном порядке с автором или в Bitcoin рассылках по электронной почте.

Заголовок Type (Тип) указывает на тип BIP: Standards Track (Стандартное отслеживание), Informational (Информационный) или Process (Процессуальный).

Заголовок Created (Создан) записывает дату, когда BIP был назначен номер, а Post-History (История постов) используется для записи дат, когда новые версии BIP появляются в Bitcoin рассылках. Даты быть в формате гггг-мм-дд, например, 2001-08-14. Post-History (История постов) может быть ссылкой на конкретный топик в архиве списка рассылки.

BIP могут иметь заголовок Requires (Запросы), указывающий номера BIP, от которых зависит этот BIP.

BIP могут также иметь заголовок «Superseded-By» (Заменено на), указывающий, что BIP был заменен более актуальным документом; значение - это номер BIP, который заменил документ. Актуальный BIP должен иметь заголовок «Replaces» (Замены), содержащий номер устаревшего BIP.

Вспомогательные файлы

BIP могут включать вспомогательные файлы, например, диаграммы. Вспомогательные файлы должны быть включены в подкаталог для этого BIP. Вспомогательные файлы должны быть названы BIP-XXXX-Y.ext, где «XXXX» - номер BIP, «Y» - это серийный номер (начиная с 1), а «ext» заменяется фактическим расширением файла (например, «png»).

Типы BIP

Есть три типа BIP:

  • Standards Track BIP (Стандартное отслеживание) описывает любые изменения, которые влияют на большинство или все реализации Bitcoin, такие как изменение сетевого протокола, изменение в блоке, правил валидации транзакций или любые изменения и дополнения, которые влияют на функциональную совместимость приложений, использующих Bitcoin. Standards Track BIP состоят из двух частей: проектного документа и справочной реализации.
  • Informational BIP (Информационный) описывает проблему разработки Bitcoin или предоставляет общие рекомендации или информацию сообществу Bitcoin, но не предлагает новую функцию. Informational BIP не обязательно представляют собой консенсус или рекомендацию сообщества Bitcoin, поэтому пользователи и разработчики могут либо игнорировать эти BIP, либо следовать их советам.
  • Process BIP (Процессуальный) описывает процесс, связанный с Bitcoin, или предлагает изменение процесса. Process BIP похожи на Standards Track BIP, но применяются к областям, отличным от самого протокола Bitcoin. Они могут предлагать реализацию, но не базу кода Bitcoin; они часто требуют консенсуса от сообщества; в отличие от Informational BIP, они являются чем-то бо́льшим, чем рекомендации, и пользователи, как правило, не могут их игнорировать. Примеры включают в себя процедуры, рекомендации, изменения в процессе принятия решений и изменения в инструментах или среде, используемых в разработке Bitcoin. Любой meta-BIP также рассматривается как Process BIP.

Поле статуса BIP

Спецификация

Возможные пути статуса BIP:

Авторы BIP могут самостоятельно принять решение по изменению статуса на «Draft» (Черновик), «Deferred» (Отложен) или «Withdrawn» (Выведен). Редактор BIP также может изменить статус на «Deferred» (Отложен), если в BIP не наблюдается никакого прогресса. Статус BIP может быть изменен с «Draft» (Черновик) (или «Rejected» (Отклонен)) на «Proposes» (Предложен), когда автор считает, что он завершен, имеет работающую реализацию (там, где это применимо)и планируется сообществом к переходу до статуса «Final» (Финальный).

Статус BIP должны быть изменен с «Draft» (Черновик) или «Proposes» (Предложен) на «Rejected» (Отклонен) по запросу любого лица, если в BIP не наблюдалось прогресса в течение трех лет. Статус такого BIP может быть изменен на «Draft» (Черновик), если автор предоставляет изменения, которые касаются критики общественности, или на «Proposes» (Предложен), если он отвечает критериям, указанным в предыдущем абзаце.

BIP со статусом «Proposes» (Предложен) может стать «Final» (Финальный) только тогда, когда произошли определенные события, отражающие принятие в реальном мире. Они разные для каждого BIP в зависимости от характера предлагаемых изменений, который будет раскрыт ниже. Оценка этого изменения статуса должна объективно поддаваться проверке и/или обсуждаться в рассылке на тему разработки.

Когда BIP со статусом «Final» (Финальный) больше не актуален, его статус может быть изменен на «Replaced» (Заменен) или «Obsolete» (Устаревший) (что эквивалентно Заменен). Это изменение также должно объективно поддаваться проверке и/или обсуждению.

BIP может изменять статус с «Draft» (Черновик) до «Active» (Активный), когда он достигает приблизительного консенсуса в списке рассылки. Такое предложение имеет приблизительный консенсус, если оно было открыто для обсуждения в списке рассылки разработки не менее одного месяца, и никто не поддерживает любые необоснованные возражения против него. Противоречивые или обструктивные возражения могут быть проигнорированы/отменены по общему согласию о том, что они были в достаточной степени рассмотрены, но были недостаточно аргументированы.

Переход к статусу Final

Софтфорк BIP строго требует четкого большинства майнеров, определяющегося голосованием (например, с использованием BIP 9). Кроме того, если некая структура хочет сделать «неуверенный» хардфокрк (например, изменить алгоритм доказательства работы), софтфорк не получит статус «Final» (Финальный), пока такой хардфорк не будет иметь поддержку большинства в течение не более чем трех месяцев. Софтфорки BIP также могут устанавливать дополнительные требования для их принятия. Из-за возможности изменений в динамике майнинга, особенно в свете делегированного голосования (пулы майнеров), настоятельно рекомендуется, чтобы сам BIP требовал около 95% голосов, если более низкий порог не обоснован.

Хардфорк BIP требует принятия от всей структуры Bitcoin, в частности, тех, кто продает желаемые товары и услуги в обмен на Bitcoin, а также владельцев Bitcoin, которые хотят потратить или могут потратить свои Bitcoin (в том числе на обмен на другие валюты) по-разному в свете такого хардфорка. Принятие должно быть выражено фактическим использованием хардфорка на практике (т. е. не просто выражением общественной поддержки, хотя это и хороший шаг для установления соглашения до принятия BIP). Это экономическое принятие не может быть установлено простым большинством голосов, за исключением буквально принуждения к принятию меньшинством этого хардфорка (независимо от того, является ли он жизнеспособным вне рамок настоящего документа).

Следует учитывать, что BIP, описывающие взаимодействие узлов, должны быть приняты не менее чем 1% публичных узлов в течение одного месяца.

API/RPC и прикладной уровень BIP должны быть реализованы как минимум двумя независимыми и совместимыми программными приложениями.

Авторам программного обеспечения предлагается опубликовать данные о том, какие BIP поддерживает их программное обеспечение, чтобы помочь в проверке изменений статуса. Хорошие примеры на момент написания этого BIP можно посмотреть в Bitcoin Core's doc/bips.md file, а также в файле Bitcoin Wallet for Android's wallet/README.specs file. Эти критерии считаются объективными способами наблюдения за фактическим применением BIP и не должны использоваться в качестве причин для противодействия или отклонения BIP. Если BIP станет фактически и недвусмысленно принят, несмотря на то, что он не соответствует указанным здесь критериям, он все равно должен быть обновлен до статуса «Final» (Финальный).

Обоснование

Почему это вообще необходимо?

  • BIP 1 определяет неоднозначные критерии для поля статус BIP, что часто является источником путаницы. В результате многие BIP со значительным использованием в реальном мире остались в статусе «Draft» (Черновик) или «Proposes» (Предложен) дольше, чем предназначалось. Предоставляя объективные критерии для оценки продвижения BIP, это предложение направлено на то, чтобы помочь сохранить статус точным и актуальным.
Как вся экономика Bitcoin определяется людьми, которые продают товары/услуги за Bitcoin и которые ими владеют?

  • Чтобы Bitcoin функционировал как валюта, он должен быть приниматься в качестве оплаты. Bitcoin монеты не имеют ценности, если вы не можете приобрести что-либо в обмен на них. Если для всех, принимающих такие платежи, требуется определенный набор консенсусных правил, то Bitcoin де-факто определяются этим набором правил - это уже реализовано сейчас. Если ожидается, что такие консенсусные правила будут расширяться (с хардфорком), торговцы должны принимать платежи, произведенные в соответствии с новым набором правил, или они отклонят «Bitcoin» как недействительную валюту. Владельцы Bitcoin имеют отношение к этой ситуации, когда они выбирают продавцов, у которых хотят потратить свои Bitcoin монеты, и могут также в целом решить продавать по одному набору консенсусных правил или по другому, таким образом, могут наводнить рынок Bitcoin и сбить цены.
Почему в экономику не входит <x></x>?
  • Некоторые организации могут в определенной степени участвовать в предоставлении товаров и/или услуг в обмен на Bitcoin, таким образом, в этом качестве (но не в их способности как <x></x> ) могут быть вовлечены в экономику.
  • Майнеры не вовлечены в экономику, потому что они просто *полагаются на* других, чтобы продавать/тратить добытые Bitcoin монеты. Поэтому они должны принимать все остальные решения при принятии консенсусных правил.
  • Биржи не включаются в экономику, поскольку они просто предоставляют услуги подключения продавцов и пользователей, которые хотят что-то покупать. Даже если все обмены должны были быть с использованием Bitcoin, эти продавцы и пользователи могут торговать напрямую и/или учреждать свои собственные биржи.
  • Разработчики не включены в экономику, так как они просто пишут код, и другие решают, использовать этот код или нет.
Но они делают важные вещи и много вложили в Bitcoin! Разве они не должны быть вовлечены в такое важное решение?
  • Этот BIP не нацелен на то, чтобы определять, что «должно» быть основой решений. Утверждение, каким бы совершенным оно ни было, бесполезно без способов заставить других его использовать. Процесс BIP направлен не на то, чтобы быть своего рода сильным «управлением» Bitcoin, а просто для создания совместного хранилища предложений и предоставления информации о стандартах, которые люди могут добровольно принять или нет.В BIP можно только надеяться на достижение точности в отношении поля «Status» (Статус), который должен отражать реальность *того, как на самом деле обстоят дела*, а не *как они должны быть*.
Что, если один продавец хочет заблокировать хардфорк?
  • Этот BIP описывает только прогресс состояния поля Status, а не развертывание хардфорка (или любого другого изменения).
  • Тем не менее, один магазин не может работать в вакууме: если они действительно одни, они скоро перестанут продавать в обмен на Bitcoin платежи, поскольку никто не захочет использовать предыдущую блок-цепочку для оплаты. Если они больше не продают, они перестают соответствовать критериям, которые дают право на вето.
Как насчет небольшого числа торговцев (может быть, двух), которые продают продукты друг другу?
  • В этом случае будет казаться, что предыдущий Bitcoin жив и работоспособен, а хардфорк провалился. Вопрос: "как разрешить такое разделение?" выходит за рамки этого BIP.
Как экономическое соглашение может наложить вето на софтфорк?

  • Группа майнеров определяется правилами консенсуса для создания групповых подписей в системе, где количество участников может меняться произвольным образом dynamic-membership multi-party signature (для Bitcoin, алгоритм доказательства работы), которые могут быть изменены с помощью хардфорка. Таким образом, если условия требуют модификации этой группы, начинается сопротивление софтфорку, и большинство майнеров, поддерживающих этот софтфорк, фактически будут аннулированы, потому что экономика может решить заменить их другой группой потенциальных майнеров, которые не поддерживают софтфорк.
Что произойдет, если экономика решает уйти от спорного софтфорка с помощью хардфорка более чем 3 месяца спустя?
  • Спорный софтфорк в этом случае изменит свой статус с «Final» на «Replaced», чтобы отразить характер хардфорка, который заменяет предыдущий (финальный) софтфорк.
Каков идеальный процент слушающих узлов необходим для принятия предложений, описывающих взаимодействие узлов?
  • Это неизвестно, на данный момент он устанавливается относительно произвольно. Для случайного выбора одноранговых узлов, чтобы иметь хотя бы один другой узел, реализующий расширение, потребуется 13% или более, но узлы могут продолжать сканировать сеть для таких узлов, возможно успешно. Кроме того, существуют служебные биты, которые помогают заранее провести идентификацию.
Почему необходимо, чтобы по крайней мере два программных проекта выпустили реализацию API/RPC и BIT прикладного уровня, прежде чем они получат статус «Final»?
  • Если есть только одна реализация спецификации, то нет другой программы, для которой используется или требуется стандартный интерфейс.
  • Даже если есть только два проекта, а не более, между ними существует некоторая стандартная координация.
Что делать, если предлагается BIP, который подходит только для одного конкретного проекта?
  • Процесс BIP существует для стандартизации между независимыми проектами. Если что-то влияет только на один проект, это должно быть сделано через собственные внутренние процессы этого проекта и не предлагаться в качестве BIP.

Комментарии к BIP

Спецификация

Каждый BIP должен в своей преамбуле ссылаться на общедоступную страницу wiki с итоговыми комментариями на странице. Обозреватели BIP, которые считают себя квалифицированными, должны размещать свои собственные комментарии на этой странице wiki. Страница комментариев обычно должна использоваться только для публикации окончательных комментариев для завершенного BIP. Если BIP еще не завершен, рецензенты должны вместо этого публиковать комментарии в соответствующем списке рассылки по разработке, чтобы позволить автору(ам) BIP решать любые вопросы или проблемы, указанные в комментариях.

Некоторые BIP получают огласку вне сообщества разработчиков до завершения, а другие BIP могут вообще не завершиться. Во избежание ситуации, когда критические комментарии BIP могут остаться незамеченными в течение этого периода времени, рецензенты могут по своему усмотрению публиковать свои отзывы на странице комментариев при условии, что они сначала отправят его в список рассылки и планируют позже удалить или пересмотреть его в отношении завершенной версии. Такие изменения должны быть сделаны путем редактирования предыдущего обзора и обновления временной метки. Комментарии, сделанные до завершенной версии, могут быть удалены, если они больше не актуальны и не обновлены своевременно (например, в течение одного месяца).

Страницы должны быть названы полным названием BIP (например, «BIP 0001») и помещены в пространство «Комментарии». Например, для BIP 1 ссылка будет выглядеть следующим образом: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001.

Комментарии, размещенные на этой wiki, должны быть в следующем формате: 

    <Your opinion> --<Your name>, <Date of posting, as YYYY-MM-DD>

BIP могут также выбрать второй форум для комментариев, в дополнение к BIP wiki. В этом случае URI второго форума должен быть указан ниже URI основной wiki.

Через некоторое время сам BIP может быть обновлен итоговыми комментариями. Комментарии могут быть выбраны из следующего списка, этот BIP не предназначен для покрытия всех возможных нюансов, и по мере необходимости могут использоваться другие комментарии:

  • Пока нет комментариев.
  • Единогласно рекомендуется к осуществлению
  • Единогласно не рекомендуется к осуществлению
  • В основном рекомендуется к осуществлению, есть некоторые затруднения
  • В основном не рекомендуется к осуществлению, есть некоторые затруднения
Например, вступление к BIP 1 может быть обновлено следующим образом: 

    Comments-Summary: No comments yet.
    Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0001
                  https://some-other-wiki.org/BIP_1_Comments

Эти поля должны идти после заголовка «Discussions-To», определенному в BIP 1 (если этот заголовок отсутствует, он должен следовать за позицией, в которой он будет присутствовать; как правило, это непосредственно над заголовком Status). Чтобы избежать сомнений: комментарии и статус - это несвязанные показатели для оценки BIP, и ни один из них не должен напрямую влиять на другой.

Обоснование

В чем суть комментариев BIP?

  • Были приняты различные BIP ( были выполнены критерии, необходимые для статуса Final), несмотря на то, что они считаются вообще нецелесообразными. По этой причине некоторые BIP считаются содерщажими «хорошую идею» просто в силу того, что им присвоили номер BIP. Из-за низкого входного барьера для представления новых BIP представляется целесообразным, чтобы рецензенты могли высказать свое мнение о них таким образом, чтобы он был доступен для общественности, без необходимости пересматривать всю дискуссию по вопросам разработки.
Будут ли комментарии BIP подвергаться цензуре или ограничиваться конкретными участниками/«экспертами»?

  • Участники должны свободно воздерживаться от комментариев по теме, которая находится за пределами их области знаний или опыта. Однако комментарии не должны подвергаться цензуре, и участие должно быть открытым для общественности.

Лицензирование BIP

Спецификация

Новые BIP могут быть приняты со следующими лицензиями. Каждый новый BIP должен идентифицировать по крайней мере одну приемлемую лицензию в своем вступлении. Заголовок лицензии в вступлении должен быть помещен после заголовка «Created». На каждую лицензию должна ссылаться ее соответствующая аббревиатура, указанная ниже.

Например, введение может включать следующий заголовок лицензии: 

    License: BSD-2-Clause
             GNU-All-Permissive

В этом случае текст BIP полностью лицензируется как по лицензии, утвержденной OSI BSD 2, так и по GNU All-Permissive License, и каждый может изменять и распространять текст при условии, что они соответствуют условиям лицензии. Другими словами, список лицензий является выбором «ИЛИ», а не требованием «И». Также возможно лицензировать исходный код отдельно от текста BIP. После заголовка «License» размещается необязательный заголовок «License-Code» (Код Лицензии). Опять же, на каждую лицензию должна ссылаться ее соответствующая аббревиатура, указанная ниже.

Например, введение, указывающее дополнительный заголовок «License-Code», может выглядеть так: 

    License: BSD-2-Clause
             GNU-All-Permissive
    License-Code: GPL-2.0+

В этом случае код в BIP недоступен в соответствии с лицензиями BSD или All-Permissive, а только в соответствии с GNU General Public License (GPL) версии 2 или новее. Если код должен быть доступен только в версии 2, символ «+» следует удалить из аббревиатуры лицензии. Для более поздней версии (например, GPL 3.0) нужно увеличить номер версии (и сохранить или удалить «+» в зависимости от намерения). 

    License-Code: GPL-2.0   # This refers to GPL v2.0 *only*, no later license versions are acceptable.
    License-Code: GPL-2.0+  # This refers to GPL v2.0 *or later*.
    License-Code: GPL-3.0   # This refers to GPL v3.0 *only*, no later license versions are acceptable.
    License-Code: GPL-3.0+  # This refers to GPL v3.0 *or later*.

В случае, если лицензирование для текста или кода слишком сложно выразить простым списком альтернатив, вместо этого список следует заменить на один термин «Complex» (Комплекс). Во всех случаях подробности условий лицензирования должны быть предоставлены в разделе авторского права BIP. BIP не должны быть лицензированы *исключительно* в соответствии с утвержденными условиями и также могут быть лицензированы по нежелательным лицензиям *в дополнение к* по крайней мере одной приемлемой лицензии. В этом случае в заголовках «License-Code» должны быть указаны только приемлемые лицензии.

Рекомендуемые лицензи

Кроме того, рекомендуется, чтобы литеральный код, включенный в BIP, имел двойную лицензию на тех же условиях, что и проект, который он модифицирует. Например, литеральный код, предназначенный для Bitcoin Core, в идеале должен иметь двойную лицензию в соответствии с условиями лицензии MIT, а также одну из вышеперечисленных с остальной частью текста BIP.

Не рекомендуемые, но приемлемые лицензии

Нежелательные лизенции

Все лицензии, не включенные в приведенные выше списки, не являются приемлемыми для предложений по улучшению Bitcoin, если только более поздний BIP не добавиляет их. Тем не менее, BIP, предшествующие принятию этого BIP, были разрешены в соответствии с другими условиями и должны использовать эту аббревиатуру, когда другие лицензия не предоставляется:

Обоснование

BIP 1 разрешил Open Publication License (Открытую лицензию на публикацию, OPL) или выпуск в общественное достояние; было ли этого достаточно?

  • OPL считается устаревшей и не подходящей для новых публикаций.
  • Многие не знакомы с терминами OPL и могут просто предпочесть использовать общественное достояние, а не лицензию под неопределенными условиями.
  • Условия лицензии OPL позволяли автору предотвратить публикации и производные работы, которые были широко признаны неприемлемыми для стандартов Bitcoin.
  • Общественное достояние не является общепризнанным как законное действие, поэтому оно нецелесообразно.
Почему лицензии на программное обеспечение включены?

  • Некоторые BIP, особенно уровня консенсуса, могут включать литеральный код в самом BIP, который может быть недоступен в соответствии с точными условиями лицензии BIP.
  • Несмотря на это, не все лицензии на программное обеспечение приемлемы для контента, включенного в BIP.
Почему общественное достояние больше не подходит для новых BIP?
  • В некоторых юрисдикциях общественное достояние не признается законным действием, оставляя BIP просто защищенным авторским правом без какого-либо перераспределения или модификации.

Изменения BIP 1

  • Приемлемые лицензии полностью пересмотрены, что позволяет использовать широкий спектр открытых лицензий, запрещая тем самым более старые варианты.
  • Статус «Accepted» (Принят) был переименован в «Proposed» (Предложен).
  • Требуется реализация (когда это применимо) до того как BIP переходит к статусу «Proposed».
  • Представлены комментарии к BIP.
  • Добавлены заголовки с лицензиями.
  • Заголовок Layer (Уровень) включен из BIP 123.
  • В поддиректории bip-XXXX разрешены вспомогательные файлы без изображений.
  • Адреса электронной почты авторов теперь необходимо указывать.
  • Заголовок The Post-History (История постов) может быть предоставлен ссылкой вместо простой даты
  • Формат Markdown больше не разрешен для BIP.
  • Заголовок Resolution (Разрешение) был удален, поскольку он не применим к децентрализованной системе, где нет полномочий для принятия окончательных решений.

Смотрите также