Se o BIP tiver vários autores cada um deles deve estar numa linha separada seguindo a convenção de continuação de linhas do RFC2822 [14]. Na fase inicial onde a proposta ainda está sendo rascunhada o cabeçalho poderá ter um campo chamado de Discussão-Para que indicará um endereço URI (Uniform Resource Identifier é quase uma URL com algumas diferenças) ou o nome de uma lista de discussão privada onde a proposta está sendo discutida. Esta fase já é posterior a fase de discussão preliminar. O campo data se refere ao momento em que o BIP recebeu um número. As opções para o campo tipo de BIP são: Standards Track, Informational e Process. O campo Post-history (complemento do histórico) permite a inclusão de um link para algum tópico específico ou para algum arquivo de uma lista de discussão. O campo Requires indica o número de outro(s) bip(s) dos quais o BIP apresentado pelo autor depende. Se algum BIP tiver o campo Superseded-By significa que ele se tornou obsoleto/ultrapassado e foi substituído por outro BIP apresentado posteriormente. Neste caso o BIP indica qual é o número do BIP que entrou no seu lugar. O novo BIP também deve indicar no cabeçalho o campo Replace indicando qual é o número do BIP que se tornou obsoleto.
Arquivos Auxiliares
Os BIPs podem ter arquivos auxiliares tais como diagramas. Os arquivos auxiliares devem ser incluídos em um subdiretório para esse BIP ou devem ser nomeados como BIP-XXXX-Y.ext, onde “XXXX” é o número do BIP, “Y” é um número de série (começando em 1) e “ext” é substituído pela extensão real do arquivo (por exemplo, “png”).
Tipos de BIP
Stardards Tracks: Este tipo de BIP é aquele que introduz alterações que afetam a maioria ou todas as implementações do Bitcoin. São os casos de alterações no protocolo do Bitcoin, nas regras de validação de blocos ou transações ou qualquer alteração ou inclusão que afete a interoperabilidade de aplicativos que usam Bitcoin. Existem duas partes essenciais que compõe um BIP deste tipo, uma é a apresentação do projeto (design) e a outra parte é a implementação de referência (codificação de teste).
Informational: São BIP’s que descrevem problemas no projeto do Bitcoin, fornecem diretrizes ou informações gerais para a comunidade sem propor novos recursos. Não representam nem exigem consenso ou recomendação obrigatória e podem ser ignorados.
Process: São BIP’s que propõem mudanças em algum processo em outras áreas do protocolo do Bitcoin. As alterações que pretendem fazer alterações no código do Bitcoin são classificadas como Standards Tracks e os BIP’s que não se enquadram nesta categoria entram na categoria de Process. Não é obrigatório, mas pode ser necessário alcançar o consenso da comunidade e ao contrário do BIP Informational geralmente não devem ser ignorados. Um exemplo desse tipo de BIP pode ser uma proposta para mudança no ambiente usado no desenvolvimento do Bitcoin ou em alguma ferramenta que está sendo usada.
CAMPO STATUS
Especificação
A sequência típica de status que um BIP poderá ser enquadrado são os seguintes:
Imagem printada em 09/02/2022 com palavras substituídas para português de:
bips/bip-0002.mediawiki at master · bitcoin/bips · GitHub
O autor da proposta pode alterar o status do seu BIP entre os seguintes estágios: Rascunho, Adiado ou Retirado. Se o editor perceber que algum BIP não está tendo nenhum progresso poderá alterar o status para Adiado.
Um BIP avançará para o status de Proposta somente quando o autor considerar que ele está pronto, tem uma implementação em funcionamento (quando for aplicável) e a comunidade demonstrou interesse em avançar com a implementação do que está sendo proposto naquele BIP.
Qualquer pessoa pode solicitar a alteração do status de um BIP classificado como Rascunho ou Proposta para a situação de Rejeitado se constatar que determinado BIP não teve nenhum progresso nos últimos três anos. Um BIP que tenha sido movido para o status de Rejeitado poderá voltar para a situação de Rascunho se alguém apresentar uma defesa consistente contra as críticas que foram feitas à proposta e até mesmo ter seu status alterado para Proposta se esta defesa atender aos critérios exigidos para o andamento de um BIP.
Um BIP atingirá o status Final (finalizado) apenas quando critérios específicos que demonstrem a viabilidade da sua adoção no mundo real (em produção). A mudança que será introduzida pela finalização de um BIP deverá ser objetivamente verificável e/ou discutida previamente na lista de desenvolvedores do Bitcoin.
Podem ocorrer situações em que um BIP finalizado perca relevância. Neste caso seu status poderá ser alterado para Substituído ou Obsoleto (equivale a ser Substituído). Esse processo também deve ser objetivamente verificável e/ou discutido. (obs: quem já lidou com projetos que me perdoe pela simplificação. OVI - Indicador objetivamente verificável significa que os dados ou indicadores apresentados na proposta são mensuráveis. Pessoas diferentes que tenham acesso aos indicadores deverão chegar às mesmas conclusões sobre a viabilidade do projeto).
No caso exclusivamente de BIP’s do tipo Process existe a possibilidade de um status ser alterado de Rascunho diretamente para Final quando ele atinge consenso numa lista de discussão. É o que pode acontecer se uma proposta (BIP) estiver disponível para discussão na lista de desenvolvedores por um prazo mínimo de um mês e neste prazo não surgir nenhuma objeção fundamentada. Se forem apresentadas objeções de natureza obstrutiva ou sem correlação com a proposta elas poderão ser ignoradas/anuladas desde que estas circunstâncias sejam devidamente claras através de um acordo geral, uma espécie de consenso sobre a questão.
Progressão para o status Final
Todo BIP que resulta num soft-fork [15] dependerá de uma votação (consenso) da maioria dos mineradores. Esta sinalização favorável deverá ser registrada num bloco minerado (por exemplo usando o BIP 009 que implementou novas regras de consenso para cada soft-fork). Além disso poderão ser estabelecidos requisitos adicionais para a implementação de um BIP que resulta num sof-fork. Devido a possibilidade deste tipo de implementação afetar a rotina dos mineradores recomenda-se expressamente que no próprio BIP se estabeleça que cerca de 95% dos mineradores sejam favoráveis, a não ser que seja apresentada uma justificativa para a definição de um parâmetro abaixo desse limite. Se a mudança indicar que há possibilidade de ocorrência de um hard-fork por causa da adoção de um BIP que por exemplo muda o algoritmo da prova de trabalho o BIP que implementa um sof-fork não se tornará Final enquanto este hard-fork tiver apoio majoritário dos mineradores (se os mineradores não gostarem de uma implementação e decidirem não adotar a implementação esta decisão pode gerar uma divisão na rede, uma funcionando com a nova implementação e a outra corrente funcionando sem a nova implementação, ou ficará pendente durante três meses).
Nota .: no BIP 002 (no original) consta o seguinte trecho neste tópico: “… especially in light of delegated voting (mining pools)”. Delegação de voto indica que um grupo entrega para um representante a condição de votar em nome do grupo. Pool de mineração aparece entre parêntese e com base nisso deduzo que os votos dos mineradores que aderem a um pool de mineração que teoricamente também teriam o direito de votar são delegados ao minerador líder. No caso em que os mineradores devem sinalizar a sua adesão ou não a um BIP que requer a manifestação deles num bloco minerado deduzo que todos os mineradores de um pool incluem o voto (decisão do pool) no bloco que estão minerando durante o período de votação. Esta é a forma que se usa para registrar de forma definitiva a adesão (voto) dos mineradores quando esta manifestação é necessária, como no caso dos BIPs que geram soft-forks. Também deduzo que a decisão quanto a direção do voto (adesão ou não) é feita previamente entre os mineradores do pool e teoricamente todos os mineradores do pool devem seguir a escolha da maioria. Os que não concordarem podem se desligar do pool. Em todo caso o minerador líder de um pool tem muita influência e costuma exercer a sua liderança levando o pool na direção que ele quer.
Um BIP que gera um hard-fork vai requerer a adesão de todo a economia envolvido com Bitcoin, principalmente dos agentes que vendem bens e serviços em troca de pagamentos com bitcoins. E por consequência também vai requerer a adesão dos detentores de bitcoins que eventualmente tenham intenção de gastar/consumir ou usar/trocar por outros moedas considerando que esse gasto ou uso será diferente no caso de um hard-fork. O hard-fork não poderá ser implementado com base numa grande ou supermaioria a não ser que ocorra literalmente a imposição do hard-fork obrigando a “aceitação” por parte da minoria que discorda (a viabilidade ou não desse tipo de iniciativa não faz parte do escopo do BIP 002).
Os BIP’s que tratam de questões ou serviços relacionadas a rede P2P devem ser avaliados e adotados por pelo menos 1% dos NÓS da rede Bitcoin pelo prazo mínimo de um mês.
Os BIP’s que envolvem uso da arquitetura RPC/API [16] e demais aplicativos devem ser implementados por pelo menos dois aplicativos de software independentes e compatíveis.
Os desenvolvedores de softwares estão convidados a publicar resumos sobre os BIP’s que seu programa suporta para auxiliar na verificação de alterações de status. Na época em que o BIP foi feito o autor incluiu dois links a título de exemplo (obs.: tem o link no texto original caso queira checar) [5].
Os critérios expostos neste documento são considerados como formas objetivas de observar a adoção de fato de um BIP. Se um BIP vier a ser implementado mesmo que não atenda a um ou mais critérios descritos neste BIP seu status deverá ser atualizado para Final/Ativo. O descumprimento de um ou mais critérios deste BIP não deve ser usado como argumento para se opor ou rejeitar um BIP.
JUSTIFICATIVA
Esta etapa é feita sob o formato ou no estilo de perguntas e respostas (FAQ). As respostas abaixo são baseadas na motivação que existiu para a elaboração do BIP 002 em substituição ao BIP 001. No caso de outras propostas as respostas devem se ater ao conteúdo ou objetivo proposto pelo autor. No original as perguntas não estão numeradas, mas vou enumerar por aqui:
1 - Porque esta implementação/atualização/correção é necessária?
- O BIP 001 definiu critérios ambíguos para o campo status dos BIPs gerando confusão. Muitos BIPs que eram importantes para o dia a dia foram mantidos no status de Rascunho ou Proposto por mais tempo do que deveriam ter sido deixados. Ao propor o uso de critérios objetivos para avaliar a progressão dos BIP’s esta proposta tem o objetivo de fazer com que o status dos BIPs seja mantido atualizado e de forma mais precisa ou exata/justa.
2 - Como toda a economia do Bitcoin é definido/visto por pessoas que vendem bens e serviços e por seus detentores/possuidores?
- Para que o bitcoin funcione como moeda ele deve ser aceito como um meio de pagamento. Bitcoins não terão valor se você não puder adquirir nada em troca deles. Todos aqueles que aceitam pagamentos em bitcoins exigem que exista um conjunto específico de regras de consenso e os bitcoins funcionam de fato sob um conjunto de regras, essa é situação atual. Se essas regras de consenso forem alteradas/ampliadas (como na ocorrência de um hard-fork) os comerciantes e prestadores de serviço terão que aceitar pagamentos em bitcoins feitos sob o novo conjunto de regras ou acabarão rejeitando os bitcoins como um meio válido de pagamento. Os portadores de bitcoins são importantes na medida em que são eles que escolhem os comerciantes e prestadores de serviços onde irão gastar seus bitcoins. Se esses detentores decidirem vender seus bitcoins sob determinada regra de consenso ou sob uma nova regra de consenso inundarão o mercado com seus bitcoins e o preço cairá.
3 - Porque (ver print abaixo) não são considerados agentes econômicos?
- Algumas entidades podem, até certo ponto estarem envolvidas na oferta de bens e/ou serviços recebendo bitcoins em troca, mas não a ponto de estarem envolvidas efetivamente no sistema econômico do Bitcoin (não estão envolvidos na capacidade de (ver print abaixo).
- Os mineradores não estão incluídos no sistema econômico do Bitcoin porque eles dependem apenas da atuação dos outros usuários comprando ou vendendo produtos e o resultado do seu trabalho de mineração (bloco) não tem valor econômico. Portanto cabe a eles aceitarem a direção escolhida por todos os demais agentes econômicos do Bitcoin sobre as regras de consenso. Transcrevo este trecho no original: “Therefore, they must accept everyone else’s direction in deciding the consensus rules.”
- As corretoras não estão incluídos no sistema econômico do Bitcoin porque eles apenas fornecem serviços de conexão entre os comerciantes e prestadores de serviços e os respectivos usuários que fazem transações. Mesmo que todas as corretoras deixassem de existir ou intermediar bitcoins os comerciantes e prestadores de serviços poderiam negociar diretamente ou criando novas corretoras.
- Os desenvolvedores não estão incluídos no sistema econômico do Bitcoin porque cabe a eles apenas escreverem os códigos que poderão ser aceitos/usados ou não pelos outros.
*(Obs.: deduzo que o código (ver o print acima) tem a ver com (ou faz algum tipo de referência) a algum tipo de tag ou comando usado em programação.
4 - Mas, eles (mineradores, corretoras e desenvolvedores) tem um papel importante e investiram muito nas suas atribuições relacionadas ao Bitcoin! Eles não deveriam ser incluídos num processo de tomada de decisão tão importante?
- Este BIP não tem intenção de estabelecer como deve ser o processo de tomada de decisão. Aceitar essa condição, de alguma forma, seria uma forma de forçar os outros a usá-lo. O sistema de recebimento, discussão e deliberação de propostas batizado de BIP não pretende ser uma espécie de “governança” forçada do Bitcoin. Seu objetivo é meramente de fornecer um repositório colaborativo onde é possível propor e incluir informações sobre padrões/processos que as pessoas poderão adotar voluntariamente ou não. Este BIP (n.º 002) apenas pretende alcançar a melhor forma de refletir da forma mais precisa possível a situação do campo “status” se esforçando para refletir a realidade “como as coisas realmente são”, em vez de tentar mostrar “como deveriam ser”.
5 - E se um único comerciante (possuidor/investidor) tentar bloquear um hard-fork?
- Este BIP aborda apenas a progressão do campo status do BIP, não tem efeitos sobre a implantação de um hard-fork (ou de qualquer outra alteração) em si.
- Independente disso, um lojista ou prestador de serviços não poderá operar no vácuo, se ele começar a agir isoladamente logo terá que deixar de vender ou prestar serviços em troca de pagamentos em bitcoins porque ficará cada vez mais difícil encontrar pessoas dispostas a fazer transações que sejam processadas e incluídas na corrente anterior/antiga do Blockchain. (obs.: na prática essa situação pode acontecer pelo menos a curto prazo, como no caso do Ethereum que já teve duas correntes operando após um hard-fork e do próprio Bitcoin que já sofreu algumas bifurcações gerando novas correntes que operam até hoje). Se estes comerciantes ou prestadores de serviços deixarem de aceitar bitcoins da nova corrente de blocos (Blockchain) que nasceu a partir de um hard-fork decidido pela maioria deixará de atender aos critérios estabelecidos neste BIP que permitem a sua participação no processo tornando seu veto sem valor.
6 - E no caso de um pequeno número de comerciantes e/ou prestadores de serviços (talvez apenas dois) que negociam produtos entre eles?
- Tudo indica que neste cenário o hard-fork falhou e o Bitcoin anterior (corrente de blocos antiga) se mantém vivo e operando.
7 - Como um acordo comercial (no original é acordo econômico) pode vetar um soft-fork?
- Os mineradores devem seguir as regras de consenso DMMS (dynamic membership multi-party signature) para criar o cabeçalho de cada bloco (blockheader) que no caso do Bitcoin é baseado no algoritmo de prova de trabalho (PoW - Proof of Work) que pode vir a ser modificado por meio de um hard-fork. Se um grupo de mineradores optar por um soft-fork (porque não concordam como hard-fork) essa decisão não terá importância porque o sistema econômico do Bitcoin poderá substituí-los por outro grupo de possíveis mineradores que são contrários ao soft-fork.
8 - O que acontece se o sistema econômico do Bitcoin não aderir a um soft-fork controverso por mais de três meses?
- Neste caso o soft-fork controverso mudará seu status de Final (pronto para implementação) para Substituído para refletir a natureza do hard-fork no lugar do soft-fork anterior. (obs.: sobre esta questão ver o primeiro parágrafo do item Progressão Para o Status Final que trata desta questão sobre um soft-fork acabar gerando um hard-fork).
9 - Qual é a porcentagem ideal de NÓS que devem ser ouvidos quando um BIP propõe alterações na rede P2P?
- Neste momento (2016) não existe um percentual fixado que acaba sendo definido de forma bastante arbitrária. Numa varredura aleatória feita entre outros pares da rede procurando pela existência de pelo menos um (outro) par da rede operando com a nova implementação seria necessário encontrar pelo menos 13% adotando a nova extensão e quanto mais prolongado for a busca maiores serão as chances de sucesso. Na realização desta busca por outros pares da rede que já adotaram a nova extensão pode ser usado o recurso service bits. (obs.: o service bits é uma espécie de identificação auxiliar de um NÓ da rede. No caso da implementação do BIP 141 – SegWit - Segregated Witness os NÓS que tinham adotado essa implementação se identificavam na rede como NODE_SEGWIT indicando que estes NÓS poderiam receber blocos e transações SegWit e os NÓS que não tinham essa identificação indicavam que não estavam aptos a receber e/ou propagar transações e blocos SegWit).
10 - Porque é necessário que pelos menos dois projetos de software adotem ou atualizem seus aplicativos e/ou a arquitetura API/RPC antes de serem classificados para o status Final?
- Se ocorrer apenas uma implementação de uma nova especificação/alteração implementada por um BIP não haverá outro programa/aplicativo fazendo interface com essa implementação, tornando seu uso desnecessário. Se pelo menos duas implementações forem realizadas com base nas alterações introduzidas pelo BIP já será possível avaliar a padronização entre eles e uma eventual coordenação.
11 - E se for proposto um BIP que só faça sentido para um único projeto específico?
- O sistema de implementação através de BIP existe para padronização de projetos independentes. Se algo afeta apenas um projeto a alteração deve ser feita no próprio projeto afetado e nunca deve ser feito via proposta de um BIP.
COMENTÁRIOS
Especificação
Cada BIP deve conter no seu preâmbulo um link direcionando para o site público wiki do github com um resumo dos comentários. Os revisores do BIP que se considerarem qualificados devem postar seus próprios comentários neste. O conteúdo da página deve ser de natureza final e o comentário deve se ater aos BIPs que já tenham sido concluídos. Se o BIP ainda não foi concluído e o revisor tem algo a dizer deve enviá-lo para o tópico relativo à questão que está sendo tratado no BIP para a lista de discussão dos desenvolvedores. Isso vai permitir que o(s) autor(es) possam avaliar e resolver quaisquer preocupações ou problemas apontados pelo revisor.
Imagem printada em 16/02/2022 com partes destacadas pelo autor e retirado de:
Home · bitcoin/bips Wiki · GitHub
A exposição ou divulgação de um BIP fora da comunidade de desenvolvedores durante o fluxo percorrido por cada BIP não é igual. Uns podem se destacar mais e outros podem ficar esquecidos e pendentes sem conclusão. No caso de revisões críticas e para evitar que este tipo de problema passe despercebido durante o período em que um BIP está em trâmite os revisores podem, a seu critério, postar sua revisão diretamente no site de comentários desde que este comentário já tenha sido publicado anteriormente na lista de discussão dos desenvolvedores. Além disso o revisor deve ter em mente que seu comentário deverá ser removido no final do processo ou revisado para adequá-lo ou ajustá-lo, se for o caso. Os ajustes devem ser feitos diretamente no próprio comentário com a consequente atualização da data/hora. Após o tramite final do processo de um BIP as revisões críticas que tenham sido publicadas antes desta etapa podem ser removidas se não forem aplicáveis e/ou não foram atualizadas em tempo hábil (por exemplo, no prazo de um mês).
O nome da página deve ter o número completo do BIP (exemplo: BIP 0001) e ter a palavra Comentário. Exemplo para incluir um comentário para o BIP 001: Comentário:BIP 0001 (que deverá ser em inglês)
As postagens feitas nesta página exclusiva para comentários devem ter o seguinte formato:
<Sua opinião> –, <Data da postagem, as AAAA-MM-DD>
Imagem printada em 16/02/2022 com partes destacadas pelo autor e retirado de:
Comments:BIP 0038 · bitcoin/bips Wiki · GitHub
Além da página pública wiki o autor de um BIP pode optar pela criação de um segundo fórum para discussão/comentários relativos ao BIP. Neste caso o segundo link deve ser postado após o link da página principal de comentários.
Após algum tempo o próprio BIP poderá ser atualizado com um resumo dos comentários. O formato deste resumo deve ser bem sintético e poderá ser escolhido entre os exemplos abaixo, mas este BIP não tem intenção de listar todas as possíveis maneiras de sintetizar ou resumir um comentário podendo ser usado outras frases conforme o caso:
- Nenhum comentário ainda;
- Implementação recomendada por unanimidade;
- Implementação desencorajada por unanimidade;
- Implementação bastante recomendada e com algumas objeções;
- Implementação com muitas objeções e com algumas recomendações.
Por exemplo:
Comentários-Resumo: Nenhum comentário ainda.
Comentários – URI: Home · bitcoin/bips Wiki · GitHub
https://some-other-wiki.org/BIP_1_Comments
Esses campos devem ter o cabeçalho “Discussão-Para” conforme definido no BIP (se esse cabeçalho não estiver presente, ele deve ser incluído logo após a posição em que deveria estar presente que geralmente é logo acima do cabeçalho Status).
Para evitar dúvidas: comentários e status são métricas que não tem conexão entre si e não devem servir de parâmetro para julgar um BIP e um não deve influenciar diretamente o outro.
Continua…
