O texto a seguir é uma tradução do BIP 2, o documento que descreve como novos recursos devem ser adicionados ao código do Bitcoin e quais os processos para se atualizar esse protocolo.
BIP: 2
Title: BIP process, revised
Author: Luke Dashjr <luke+bip@dashjr.org>
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
Tabela de Conteúdo
Resumo
Direito Autoral
Fluxo de trabalho BIP
Transferência de Dono de BIP
Editor do BIP
Responsabilidades e Fluxo de trabalho dos editores do BIP
Formato e Estrutura BIP
Especificações
Preâmbulo do cabeçalho BIP
Arquivos auxiliares
Tipos de BIP
Campo do status BIP
Especificações
Avanço para Status Final
Especificações
Comentários BIP
Especificações
Justificativa
Licenças do BIP
Especificações
Licenças Recomendadas
Licenças não recomendadas, mas aceitáveis
Licenças não aceitáveis
Mudanças em relação ao BIP 1
Veja também
Resumo
Uma Proposta de Melhoria do Bitcoin (BIP) é um documento de design que fornece informações à comunidade Bitcoin ou descreve um novo recurso para o Bitcoin ou seus processos. O BIP deve fornecer as especificações técnicas de forma concisa e uma justificativa para o recurso.
Pretendemos que os BIPs sejam os principais mecanismos para propor novos recursos, para coletar contribuições da comunidade sobre um problema e para documentar as decisões de design que foram as tomadas de decisão do Bitcoin. O autor do BIP é responsável por construir consenso dentro da comunidade e documentar opiniões divergentes.
Como os BIPs são mantidos como arquivos de texto em um repositório versionado, seu histórico de revisões é o registro histórico da proposta de recurso.
Este BIP específico substitui o BIP 1 , criando um processo mais bem definido e claro.
Direito Autoral
Este BIP tem dupla sob a Licença de Publicação Aberta e a Licença 2 de cláusulas BSD.
Fluxo de trabalho BIP
O processo BIP começa com uma nova ideia para Bitcoin. Cada BIP potencial deve ter um defensor – alguém que escreve o BIP usando o estilo e formato descritos abaixo, conduz as discussões nos fóruns apropriados e tenta construir um consenso comunitário em torno da ideia. O defensor do BIP (também conhecido como Autor) deve primeiro tentar verificar se a ideia é compatível com o BIP. Pequenos aprimoramentos ou patches em um determinado software geralmente não exigem padronização entre vários projetos; eles não precisam de um BIP e devem ser injetados no fluxo de trabalho de desenvolvimento relevante específico do projeto com um envio de patch ao rastreador de problemas aplicável. Além disso, muitas ideias foram apresentadas para alterar o Bitcoin e foram rejeitadas por vários motivos. O primeiro passo deve ser pesquisar discussões anteriores para ver se uma ideia já foi considerada antes e, em caso afirmativo, que questões surgiram na sua progressão. Depois de investigar trabalhos anteriores, a melhor maneira de proceder é postar sobre a nova ideia na lista de discussão de desenvolvimento do Bitcoin.
Examinar publicamente uma ideia antes de escrever um BIP visa economizar tempo tanto do autor quanto da comunidade em geral. Perguntar primeiro à comunidade Bitcoin se uma ideia é original ajuda a evitar que se gaste muito tempo em algo que certamente será rejeitado com base em discussões anteriores (pesquisar na Internet nem sempre resolve). Também ajuda a garantir que a ideia seja aplicável a toda a comunidade e não apenas ao autor. Só porque uma ideia parece boa para o autor não significa que funcionará para a maioria das pessoas nas áreas onde o Bitcoin é usado.
Depois que o autor perguntar à comunidade Bitcoin se uma ideia tem alguma chance de aceitação, um rascunho do BIP deverá ser apresentado à lista de discussão de desenvolvimento do Bitcoin. Isto dá ao autor a oportunidade de dar corpo ao BIP para torná-lo devidamente formatado, de alta qualidade, e para abordar preocupações adicionais sobre a proposta. Após uma discussão, a proposta deve ser submetida ao repositório git dos BIPs como uma solicitação pull. Este rascunho deve ser escrito no estilo BIP conforme descrito abaixo e nomeado com um pseudônimo como "bip-johndoe-infinitebitcoins" até que um editor lhe atribua um número BIP (os autores NÃO DEVEM auto atribuir números a um BIP).
Os autores do BIP são responsáveis por coletar feedback da comunidade sobre a ideia inicial e o BIP antes de enviá-lo para revisão. Contudo, sempre que possível, devem ser evitadas discussões longas e abertas em listas de discussão públicas. As estratégias para manter as discussões eficientes incluem: configurar uma lista de discussão SIG separada para o tópico, fazer com que o autor do BIP aceite comentários privados nas fases iniciais de design, configurar uma página wiki ou repositório git, etc.
É altamente recomendável que um único BIP contenha uma única proposta-chave ou uma nova ideia. Quanto mais focado for o BIP, mais bem sucedido tende a ser. Em caso de dúvida, divida seu BIP em vários bem focados.
Quando o rascunho do BIP for concluído, um editor do BIP atribuirá um número ao BIP e vai lhe atribuirá um rótulo, tais como Standards Track, Informational ou Process e mesclará a solicitação pull com o repositório git do BIP. Os editores do BIP não rejeitarão injustificadamente um BIP. As razões para rejeitar os BIPs incluem duplicação de esforços, desrespeito às regras de formatação, ser muito desfocado ou muito amplo, ser tecnicamente insalubre, não fornecer a motivação adequada ou abordar a compatibilidade com versões anteriores, ou não estar de acordo com a filosofia Bitcoin. Para que um BIP seja aceito, ele deve atender a determinados critérios mínimos. Deve ser uma descrição clara e completa da melhoria proposta. A proposta deve representar uma melhoria. A implementação proposta, se aplicável, deve ser sólida e não deve complicar indevidamente o protocolo.
O autor do BIP pode atualizar o rascunho conforme necessário no repositório git. Atualizações nos rascunhos também devem ser enviadas pelo autor como pull requests.
Transferindo propriedade do BIP
Ocasionalmente, torna-se necessário transferir a propriedade dos BIPs para um novo autor. Em geral, gostaríamos de manter o autor original como coautor do BIP transferido, mas isso depende do autor original. Uma boa razão para transferir a propriedade é porque o autor original não tem mais tempo ou interesse em atualizá-lo ou prosseguir com o processo BIP, ou desapareceu da rede (ou seja, está inacessível ou não responde ao e-mail). Um mau motivo para transferir a propriedade é porque você não concorda com a orientação do BIP. Tentamos construir um consenso em torno de um BIP, mas se isso não for possível, você sempre poderá enviar um BIP concorrente.
Se você estiver interessado em assumir a propriedade de um BIP, envie uma mensagem solicitando a posse, endereçada ao autor original e aos editores do BIP. Se o autor original não responder ao e-mail em tempo hábil, os editores do BIP tomarão uma decisão unilateral (não é como se tais decisões não pudessem ser revertidas :).
Editores BIP
Os editores BIP atuais são:
Luke Dashjr (luke_bipeditor@dashjr.org)
Kalle Alm (karljohan-alm@garage.co.jp)
Responsabilidades e fluxo de trabalho do editor BIP
Os editores do BIP assinam a lista de discussão de desenvolvimento do Bitcoin. A correspondência relacionada ao BIP fora da lista deve ser enviada (ou CC) aos editores do BIP.
Para cada novo BIP que chega em um editor faz o seguinte:
Lê o BIP para verificar se está pronto: correto e completo. As ideias devem fazer sentido técnico, mesmo que não pareça provável que sejam aceitas.
O título deve descrever com precisão o conteúdo.
O rascunho do BIP deve ter sido enviado para a lista de discussão de desenvolvimento do Bitcoin para discussão.
A motivação e a compatibilidade com versões anteriores (quando aplicável) devem ser abordadas.
O cabeçalho da camada definido deve ser atribuído corretamente de acordo com as especificações fornecidas.
Os termos de licenciamento devem ser compatíveis com os BIPs.
Caso o BIP não esteja pronto, o editor o enviará de volta ao autor para revisão, com instruções específicas.
Assim que o BIP estiver pronto para o repositório, ele deverá ser enviado como uma "solicitação pull" ao repositório git do BIP, onde poderá obter mais feedback.
O editor BIP irá:
Atribuir um número BIP na solicitação pull.
Mesclar a solicitação pull quando estiver pronta.
Listar o BIP em README.mediawiki
Os editores do BIP devem cumprir responsabilidades administrativas e editoriais. Os editores BIP monitoram as alterações do BIP e atualizam os cabeçalhos do BIP conforme apropriado.
Formato e estrutura BIP
Especificação
Os BIPs devem ser escritos no formato mediawiki.
Cada BIP deve ter as seguintes partes:
Observação de tradução: optei por deixar em inglês o nome das partes.Preamble – Cabeçalhos contendo metadados sobre o BIP (veja abaixo).
Abstract – Uma breve descrição (cerca de 200 palavras) do problema técnico que está sendo abordado.
Copyright – O BIP deve ser explicitamente licenciado sob termos aceitáveis de direitos autorais (veja abaixo).
Specification – A especificação técnica deve descrever a sintaxe e a semântica de qualquer novo recurso. A especificação deve ser detalhada o suficiente para permitir implementações concorrentes e interoperáveis para qualquer uma das plataformas Bitcoin atuais.
Motivation– A motivação é crítica para BIPs que desejam mudar o protocolo Bitcoin. Deve explicar claramente por que o protocolo atual é inadequado para resolver o problema que o BIP resolve.
Rationale – A justificativa dá corpo à especificação, descrevendo o que motivou o projeto e por que decisões específicas de projeto foram tomadas. Deve descrever projetos alternativos que foram considerados e trabalhos relacionados. A justificativa deve fornecer evidências de consenso dentro da comunidade e discutir objeções ou preocupações importantes levantadas durante a discussão.
Backwards compatibility– Todos os BIPs que introduzem incompatibilidades com versões anteriores devem incluir uma seção descrevendo essas incompatibilidades e sua gravidade. O BIP deverá explicar como o autor propõe lidar com essas incompatibilidades.
Reference implementation – A implementação de referência deve ser concluída antes de qualquer BIP receber o status “Final”, mas não precisa ser concluída antes que o BIP ser aceito. É melhor terminar primeiro a especificação e a justificativa e chegar a um consenso sobre isso antes de escrever o código. A implementação final deve incluir código de teste e documentação apropriada para o protocolo Bitcoin.
Preâmbulo do cabeçalho BIP
Cada BIP deve começar com um preâmbulo de cabeçalho no estilo RFC 822. Os cabeçalhos devem aparecer na seguinte ordem. Os cabeçalhos marcados com "*" são opcionais e estão descritos abaixo. Todos os outros cabeçalhos são obrigatórios.
Observação de tradução: optei por deixar em inglês essa seção.
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>
O cabeçalho da camada/Layer header (somente para BIPs de rastreamento de padrões/Standards Track BIPs) documenta a qual camada de Bitcoin o BIP se aplica. Consulte BIP 123 para definições das várias camadas BIP. A ativação deste BIP implica a ativação do BIP 123.
O Author header lista os nomes e endereços de e-mail de todos os autores/proprietários do BIP. O formato do valor do cabeçalho Autor deve ser:
Random J. User <address@dom.ain>Se houver vários autores, cada um deverá estar em uma linha separada, seguindo as convenções de linha de continuação RFC 2822.
Enquanto um BIP estiver em discussões privadas (geralmente durante a fase inicial de Rascunho), um cabeçalho Discussions-To indicará a lista de discussão ou URL onde o BIP está sendo discutido. Nenhum cabeçalho Discussions-To é necessário se o BIP estiver sendo discutido em particular com o autor ou nas listas de discussão de e-mail Bitcoin.
O Type Header especifica o tipo de BIP: Standards Track, Informational ou Process.
O Created Header registra a data em que o BIP recebeu um número, enquanto Post-History é usado para registrar quando novas versões do BIP são postadas nas listas de discussão do Bitcoin. As datas devem estar no formato aaaa-mm-dd, por exemplo. 14/08/2001. O Post-History pode ser um link para um tópico específico em um arquivo de lista de discussão.
Os BIPs podem ter um Requires header, indicando os números BIP dos quais esse BIP depende.
Os BIPs também podem ter um cabeçalho Superseded-By, indicando que um BIP se tornou obsoleto por um documento posterior; o valor é o número do BIP que substitui o documento atual. O BIP mais recente deve ter um cabeçalho Replaces contendo o número do BIP que tornou obsoleto.
Arquivos Auxiliares
Os BIPs podem incluir arquivos auxiliares, como diagramas. Os arquivos auxiliares devem ser incluídos em um subdiretório desse BIP, ou devem ser denominados 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
Existem três tipos de BIP:
BIP Standards Track descreve qualquer alteração que afete a maioria ou todas as implementações do Bitcoin, como uma alteração no protocolo de rede, uma alteração nas regras de validade de bloco ou transação ou qualquer alteração e adição que afete a interoperabilidade de aplicativos que usam Bitcoin. Os BIPs do Standard Track consistem em duas partes, um documento de design e uma implementação de referência.
BIP informativo descreve um problema de design do Bitcoin ou fornece diretrizes ou informações gerais para a comunidade Bitcoin, mas não propõe um novo recurso. Os BIPs informativos não representam necessariamente um consenso ou recomendação da comunidade Bitcoin, portanto, os usuários e implementadores são livres para ignorar os BIPs informativos ou seguir seus conselhos.
BIP de processo ou Meta-BIP descreve um processo em torno do Bitcoin ou propõe uma alteração em um processo. Os BIPs de processo são como BIPs de rastreamento de padrões, mas se aplicam a outras áreas além do próprio protocolo Bitcoin. Eles podem propor uma implementação, mas não para a base de código do Bitcoin; muitas vezes exigem consenso da comunidade; ao contrário dos BIPs informativos, eles são mais do que recomendações e os usuários normalmente não têm liberdade para ignorá-los. Os exemplos incluem procedimentos, diretrizes, mudanças no processo de tomada de decisão e mudanças nas ferramentas ou ambiente usado no desenvolvimento do Bitcoin. Qualquer meta-BIP também é considerado um BIP de Processo.
Campo de status do BIP
Especificação
Os caminhos típicos do status dos BIPs são os seguintes:
Os autores de um BIP podem decidir por conta própria alterar o status entre Draft, Diferido (Deferred) ou Retirado (Withdrawn). Um editor BIP também pode alterar o status para Adiado (Deferred) quando nenhum progresso estiver sendo feito no BIP.
Um BIP só pode mudar o status de Rascunho (ou Rejeitado) para Proposto, quando o autor considerar que está completo, tem uma implementação funcional (quando aplicável) e a comunidade tem planos para avançá-lo para o status Final.
O status do BIPs podem ser alterados de Rascunho ou Proposto para o status Rejeitado, mediante solicitação de qualquer pessoa, caso não tenham feito progressos em três anos. Tal BIP pode ser alterado para o status de Rascunho se o defensor fornecer revisões que abordem de forma significativa as críticas públicas à proposta, ou para o status de Proposto se atender aos critérios exigidos conforme descrito no parágrafo anterior.
Um BIP proposto poderá progredir para Final somente quando ocorrerem critérios específicos que reflitam a adoção no mundo real. Isto é diferente para cada BIP, dependendo da natureza das alterações propostas, que serão expandidas abaixo. A avaliação desta mudança de status deve ser objetivamente verificável e/ou ser discutida na lista de discussão de desenvolvimento.
Quando um BIP Final deixa de ser relevante, seu status pode ser alterado para Substituído ou Obsoleto (que equivale a Substituído). Esta mudança também deve ser objetivamente verificável e/ou discutida.
Um processo BIP pode mudar de status de Rascunho para Ativo quando atinge um consenso aproximado na lista de discussão. Diz-se que tal proposta tem um consenso aproximado se estiver aberta à discussão na lista de discussão sobre desenvolvimento há pelo menos um mês, e ninguém mantém quaisquer objeções fundamentadas não abordadas a ela. Objeções abordadas ou obstrutivas podem ser ignoradas/anuladas por acordo geral de que foram suficientemente abordadas, mas deve ser dada uma fundamentação clara em tais circunstâncias.
Progressão para o status final
Um BIP soft-fork exige estritamente uma maioria clara dos mineradores, expressa por votação na blockchain (por exemplo, usando o BIP 9). Além disso, se a economia parecer disposta a fazer um hard fork "sem confiança" (como uma mudança no algoritmo de prova de trabalho), o soft fork não se tornará final enquanto tal hard fork puder ter apoio da maioria, ou no máximo três meses. Os BIPs soft-fork também podem estabelecer requisitos adicionais para a sua adoção. Devido à possibilidade de alterações na dinâmica dos mineradores, especialmente à luz da votação delegada (pools de mineração), é altamente recomendado que uma votação por maioria absoluta de cerca de 95% seja exigida pelo próprio BIP, a menos que seja dada justificação para um limiar mais baixo.
Um BIP hard-fork requer a adoção de toda a economia Bitcoin, incluindo aqueles que vendem bens e serviços em troca de pagamentos em bitcoin, bem como os detentores de Bitcoin que desejam gastar ou gastariam seus bitcoins (incluindo a venda para outras moedas). A adopção deve ser expressa através da utilização de fcto do hard-fork na prática (ou seja, não apenas expressando o apoio público, embora isso seja um bom passo para estabelecer um acordo antes da adopção do BIP). Esta adopção económica não pode ser estabelecida apenas por uma supermaioria, exceto forçando literalmente a minoria a aceitar o hard-fork (se isto é viável ou não, está fora do âmbito deste documento).
Deve-se observar que os BIPs de serviços de peers devem ser adotados por pelo menos 1% dos nós de escuta pública (public listening nodes) durante um mês.
Esclarecimento da tradutora: um nó de escuta (ou nó completo) é um nó publicamente visível que verifica todas as informações da blockchain sem confiar em nenhuma fonte específica. Os nós de escuta tem uma porta aberta específica (geralmente a 8333) que se comunica e fornece informações a qualquer outro nó que decida estabelecer conexão com ele.
Os nós podados - utilizados nas versões mais recentes do Bitcoin Core- não mantém blocos antigos para economizar espaço de armazenamento. API/RPC e aplicações de BIPs da camada devem ser implementados por pelo menos dois aplicativos de software independentes e compatíveis.
Os autores de software são incentivados a publicar resumos dos BIPs que seu software suporta para auxiliar na verificação de mudanças de status. Bons exemplos disso no momento em que este BIP foi escrito podem ser observados no arquivo doc/bips.md do Bitcoin Core, bem como no arquivo wallet/README.specs.md do Bitcoin Wallet para Android.
Estes critérios são considerados formas objetivas de observar a adoção de fato do BIP e não devem ser usados como razões para se opor ou rejeitar um BIP. Caso um BIP seja adotado de forma efetiva e inequívoca, apesar de não atender aos critérios aqui descritos, ele ainda deverá ser atualizado para o status Final.
Justificativa
Por que isso é necessário?
BIP 1 define critérios ambíguos para o campo Status dos BIPs, o que costuma ser uma fonte de confusão. Como resultado, muitos BIPs com uso significativo no mundo real foram deixados com o status de Rascunho ou Proposto por mais tempo do que o apropriado. Ao fornecer critérios objetivos para avaliar a progressão dos BIPs, esta proposta visa ajudar a manter o estatuto preciso e atualizado.
Como toda a economia Bitcoin é definida por pessoas que vendem bens/serviços e detentores?
Para que o Bitcoin funcione como moeda, ele deve ser aceito como forma de pagamento. Os Bitcoins não têm valor se você não puder adquirir nada em troca deles. Se todos os que aceitam tais pagamentos exigem um conjunto específico de regras de consenso, os “bitcoins” são de fato definidos por esse conjunto de regras – este já é o caso hoje. Se espera-se que essas regras de consenso sejam ampliadas (como acontece com um hard fork), esses comerciantes precisam aceitar pagamentos feitos sob o novo conjunto de regras, ou rejeitarão “bitcoins” como inválidos. Os holders são relevantes na medida em que escolhem os comerciantes com quem desejam gastar os seus bitcoins, e também podem, como um todo, decidir vender sob um conjunto de regras de consenso ou outro, inundando assim o mercado com bitcoins e provocando uma queda no preço.
Por que <x></x> não estão incluídos na economia?
Algumas entidades podem, até certo ponto, também estar envolvidas na oferta de bens e/ou serviços em troca de bitcoins, estando assim envolvidas na economia nessa qualidade (mas não na sua capacidade como <x></x>).
Mineradores não estão incluídos na economia, porque apenas dependem de outros para vender/gastar os seus produtos minerados, que de outra forma seriam inúteis. Portanto, devem aceitar a orientação de todos os outros na decisão das regras de consenso.
As exchanges não estão incluídas na economia, pois apenas prestam serviços de conexão entre comerciantes e usuários que desejam negociar. Mesmo que todas as exchanges desertassem do Bitcoin, esses comerciantes e usuários sempre poderão negociar diretamente e/ou estabelecer suas próprias exchanges.
Os desenvolvedores não estão incluídos na economia, pois apenas escrevem código, cabendo a outros decidir usar ou não esse código.
Mas eles estão fazendo algo importante e investiram muito em Bitcoin! Eles não deveriam ser incluídos em uma decisão tão importante?
Este BIP não pretende abordar o que “deveria” ser a base das decisões. Tal afirmação, por mais perfeita que seja na sua justificação, seria fútil sem alguma forma de forçar outros a usá-la. O processo BIP não pretende ser uma espécie de “governança” forçada do Bitcoin, apenas fornecer um repositório colaborativo para propor e fornecer informações sobre padrões, que as pessoas podem adotar voluntariamente ou não. Só pode esperar alcançar precisão no que diz respeito ao campo do “Status” esforçando-se por refletir a realidade de como as coisas realmente são, em vez de como deveriam ser.
E se um único comerciante desejar bloquear um hard fork?
Este BIP aborda apenas a progressão do campo Status do BIP, e não a implantação do hard fork (ou qualquer outra alteração) em si.
Independentemente disso, uma loja não pode operar no vácuo: se eles estiverem realmente sozinhos, em breve não venderão mais em troca de pagamentos em bitcoin, já que ninguém mais estaria disposto a usar a versão anterior para pagá-los. Caso deixem de vender, deixam de atender aos critérios aqui previstos que possibilitam seu veto.
E quanto a um pequeno número de comerciantes (talvez apenas dois) que vendem produtos entre si?
Nesse cenário, a versão anterior do Bitcoin estará vivo e funcionando e o hard fork falhou. A forma de resolver tal divisão está fora do âmbito deste BIP.
Como pode o acordo económico vetar um soft-fork?
O grupo de mineradores é determinado pelas regras de consenso para a assinatura multipartidária de associação dinâmica (para Bitcoin, o algoritmo de prova de trabalho), que pode ser modificado com um hard fork. Assim, se as mesmas condições necessárias para modificar este grupo forem satisfeitas em oposição a um soft-fork, a maioria dos mineradores que apoia o soft-fork é efetivamente nula porque a economia pode decidir substituí-los por outro grupo de potenciais mineiros que não suportam o soft-fork.
O que acontecerá se a economia decidir afastar-se de um controverso soft-fork, mais de três meses depois?
O controverso soft-fork, nesta circunstância, muda do status Final para Substituído para refletir a natureza do hard-fork que substitui o soft-fork anterior (final).
Qual é a porcentagem ideal de nós de escuta (listening nodes) necessários para adotar propostas de serviços de peers?
Isso é desconhecido e definido de forma bastante arbitrária neste momento. Para que uma seleção aleatória de peers tenha pelo menos um outro par implementando a extensão, seriam necessários 13% ou mais, mas os nós poderiam continuar a varrer a rede em busca de tais pares, talvez com algum sucesso razoável. Além disso, existem bits de serviço para ajudar na identificação antecipada.
Por que é necessário que pelo menos dois projetos de software liberem uma implementação de API/RPC e BIPs da camada de aplicação, antes de se tornarem finais?
Se houver apenas uma implementação de uma especificação, não haverá outro programa para o qual uma interface padrão seja usada ou necessária.
Mesmo que existam apenas dois projetos em vez de mais, existe alguma coordenação padrão entre eles.
E se for proposto um BIP que só faça sentido para um único projeto específico?
O processo BIP existe para padronização entre projetos independentes. Se algo afetar apenas um projeto, deve ser feito através dos próprios processos internos desse projeto e, em primeiro lugar, nunca ser proposto como um BIP.
Comentários do Bitcoin Improvement Proposal (BIP)
Especificação
Cada BIP deve, em seu preâmbulo, vincular-se a uma página wiki pública com um resumo dos comentários dessa página. Os revisores do BIP que se considerem qualificados deverão postar seus próprios comentários nesta página wiki. A página de comentários geralmente só deve ser usada para postar comentários finais sobre um BIP concluído. Se um BIP ainda não estiver concluído, os revisores deverão postar no tópico da lista de discussão de desenvolvimento aplicável para permitir que o(s) autor(es) do BIP abordem quaisquer preocupações ou problemas apontados pela revisão.
Alguns BIPs recebem exposição fora da comunidade de desenvolvimento antes de serem concluídos, e outros BIPs podem nem sequer ser concluídos. Para evitar uma situação em que revisões críticas do BIP possam passar despercebidas durante este período, os revisores podem, a seu critério, ainda publicar sua revisão na página de comentários, desde que primeiro a publiquem na lista de discussão e planejem removê-la ou revisá-la posteriormente, conforme aplicável, com base na versão completa. Tais revisões deverão ser feitas editando a revisão anterior e atualizando o carimbo de data/hora. As revisões feitas antes da versão completa poderão ser removidas se não forem mais aplicáveis e não tiverem sido atualizadas em tempo hábil (por exemplo, dentro de um mês).
As páginas devem ser nomeadas com o número BIP completo (por exemplo, "BIP 0001") e colocadas no namespace "Comentários".
Por exemplo, o link para BIP 1 será https://github.com/bitcoin/bips/wiki/Comments:BIP-0001 .
Os comentários postados nesta wiki devem usar o seguinte formato:
`<Your opinion> --<Your name>, <Date of posting, as YYYY-MM-DD>`Os BIPs também podem optar por listar um segundo fórum para comentários dos BIPs, além do wiki dos BIPs. Neste caso, o URI do segundo fórum deve ser listado abaixo do URI do wiki principal.
Depois de algum tempo, o próprio BIP poderá ser atualizado com um tom resumido dos comentários. Os tons do resumo podem ser escolhidos dentre os seguintes, mas este BIP não pretende cobrir todas as nuances possíveis e outros resumos podem ser usados conforme necessário:
Nenhum comentário ainda.
Recomendado por unanimidade para implementação
Desencorajar unanimemente a implementação
Principalmente recomendado para implementação, com algum desânimo
Principalmente desencorajado para implementação, com algumas recomendações
Por exemplo, o preâmbulo do BIP 1 pode ser atualizado para incluir a linha:
Comments-Summary: No comments yet.
Comments-URI: <https://github.com/bitcoin/bips/wiki/Comments:BIP-0001>
<https://some-other-wiki.org/BIP_1_Comments>
Estes campos devem seguir o cabeçalho "Discussions-To" definido no BIP 1 (se esse cabeçalho não estiver presente, deverá seguir a posição onde estaria presente; geralmente fica imediatamente acima do cabeçalho Status).
Para evitar dúvidas: comentários e status são métricas não relacionadas para julgar um BIP e nenhum deve influenciar diretamente o outro.
Justificativa
Qual é o propósito dos comentários do BIP?
Vários BIPs foram adotados (os critérios exigidos para o status “Final”), apesar de serem considerados geralmente desaconselháveis. Atualmente, alguns consideram os BIPs uma “boa ideia” simplesmente pelo fato de lhes ser atribuído um número BIP. Devido à baixa barreira de entrada para submissão de novos BIPs, parece aconselhável que os revisores expressem as suas opiniões sobre eles de uma forma que seja consumível pelo público, sem necessidade de rever toda a discussão sobre desenvolvimento.
Os comentários do BIP serão censurados ou limitados a determinados participantes/"especialistas"?
Os participantes devem abster-se livremente de fazer comentários fora da sua área de conhecimento ou especialização. Contudo, os comentários não devem ser censurados e a participação deve ser aberta ao público.
Licenciamento BIP
Especificação
Novos BIPs podem ser aceitos com as seguintes licenças. Cada novo BIP deve identificar pelo menos uma licença aceitável no seu preâmbulo. O cabeçalho License no preâmbulo deve ser colocado após o cabeçalho Created. Cada licença deve ser referenciada pela respectiva abreviatura fornecida abaixo.
Por exemplo, um preâmbulo pode incluir o seguinte cabeçalho de licença:
License: BSD-2-Clause
GNU-All-Permissive
Neste caso, o texto BIP é totalmente licenciado sob a licença BSD de 2 cláusulas aprovada pela OSI, bem como a licença GNU All-Permissive, e qualquer pessoa pode modificar e redistribuir o texto, desde que cumpra os termos de *qualquer* licença . Em outras palavras, a lista de licenças é uma escolha “OU”, não um requisito.
Também é possível licenciar o código-fonte de forma diferente do texto BIP. Um cabeçalho License-Code opcional é colocado após o cabeçalho License. Novamente, cada licença deve ser referenciada pela respectiva abreviatura fornecida abaixo.
Por exemplo, um preâmbulo especificando o cabeçalho License-Code opcional pode ter a seguinte aparência:
License: BSD-2-Clause
GNU-All-Permissive
License-Code: GPL-2.0+
Neste caso, o código no BIP não está disponível sob as licenças BSD ou All-Permissive, mas apenas sob os termos da Licença Pública Geral GNU (GPL), versão 2 ou mais recente. Se o código estivesse disponível exatamente apenas na versão 2, o símbolo "+" deveria ser removido da abreviatura da licença. Para uma versão posterior (por exemplo, GPL 3.0), você aumentaria o número da versão (e manteria ou removeria o “+” dependendo da intenção).
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*.
Caso o licenciamento do texto ou código seja demasiado complicado para ser expresso através de uma simples lista de alternativas, a lista deverá ser substituída pelo termo único "Complexo". Em todos os casos, os detalhes dos termos de licenciamento devem ser fornecidos na seção de Direitos Autorais do BIP.
Os BIPs não precisam ser licenciados exclusivamente sob termos aprovados e também podem ser licenciados sob licenças inaceitáveis além de pelo menos uma licença aceitável. Neste caso, apenas as licenças aceitáveis devem ser listadas nos cabeçalhos Licença e Código de licença.
Licenças recomendadas:
BSD-2-Clause: Licença BSD de 2 cláusulas aprovada pela OSI
BSD-3-Clause: Licença BSD de 3 cláusulas aprovada pela OSI
CC0-1.0: Creative Commons CC0 1.0 Universal GNU-All-Permissive: Licença GNU All-Permissive
Além disso, recomenda-se que o código literal incluído no BIP seja licenciado duplamente sob os mesmos termos de licença do projeto que ele modifica. Por exemplo, o código literal destinado ao Bitcoin Core seria idealmente licenciado duplamente sob os termos de licença do MIT, bem como um dos acima com o restante do texto BIP.
Licenças não recomendadas, mas aceitáveis
Apache-2.0: Licença Apache, versão 2.0
BSL-1.0: Boost Software License, versão 1.0
Licenças não aceitáveis
Todas as licenças não incluídas explicitamente nas listas acima não são termos aceitáveis para uma Proposta de Melhoria do Bitcoin, a menos que um BIP posterior estenda esta para adicioná-las. No entanto, os BIPs anteriores à aceitação deste BIP eram permitidos sob outros termos, e deveriam utilizar estas abreviaturas quando nenhuma outra licença fosse concedida:
PD: Lançado em domínio público
Justificativa
O BIP 1 permitiu a Licença Aberta de Publicação ou a liberação em domínio público; isso foi insuficiente?
O OPL é geralmente considerado obsoleto e não uma licença adequada para novas publicações.
Muitos não estão familiarizados com os termos do OPL e podem preferir usar o domínio público em vez de licenciar sob termos incertos.
Os termos da licença OPL permitiam ao autor impedir a publicação e trabalhos derivados, o que era amplamente considerado inadequado para os padrões Bitcoin.
O domínio público não é universalmente reconhecido como uma acção legítima, pelo que é desaconselhável.
Por que as licenças de software estão incluídas?
Alguns BIPs, especialmente a camada de consenso, podem incluir código literal no próprio BIP, que pode não estar disponível sob os termos exatos da licença do BIP.
Apesar disso, nem todas as licenças de software seriam aceitáveis para o conteúdo incluído nos BIPs.
Por que o Domínio Público não é mais aceitável para novos BIPs?
Em algumas jurisdições, o domínio público não é reconhecido como uma ação legal legítima, deixando o BIP simplesmente protegido por direitos autorais, sem qualquer redistribuição ou modificação permitida.
Mudanças em relação o BIP 1
As licenças aceitáveis foram escolhidas novamente, permitindo uma ampla variedade de licenças abertas, ao mesmo tempo que proíbe as escolhas mais antigas e problemáticas.
O status Aceito foi renomeado para Proposto.
Agora é necessária uma implementação (quando aplicável) antes que os BIPs possam prosseguir para o Status Proposto.
Os comentários BIP foram introduzidos recentemente.
Os cabeçalhos do preâmbulo da licença foram adicionados.
O cabeçalho da camada está incluído no BIP 123.
Arquivos auxiliares sem imagem são permitidos no subdiretório bip-XXXX.
Endereços de e-mail agora são obrigatórios para autores.
O cabeçalho Post-History pode ser fornecido como um link em vez de uma simples data.
O formato Markdown não é mais permitido para BIPs.
O cabeçalho Resolução foi eliminado, pois não é aplicável a um sistema descentralizado onde não existe autoridade para tomar decisões finais.
Veja também (não traduzidos)
BIP 1: BIP Purpose and Guidelines
BIP 123: BIP Classification
RFC 7282: On Consensus and Humming in the IETF