# Bitcoin core

O Bitcoin Core (antigo Bitcoin-Qt) é o terceiro cliente Bitcoin, desenvolvido por Wladimir van der Laan baseado no código de referência original de Satoshi Nakamoto. O software foi publicado, inicialmente, sob o nome "Bitcoin", e depois renomeado para "Bitcoin Core" para distingui-lo da rede Bitcoin. Por esta razão, também é conhecido como o Cliente Satoshi. A partir de 2018, os repositórios do Bitcoin Core são mantidos por uma equipe de mantenedores, com Wladimir J. van der Laan liderando o processo de lançamento. A Iniciativa de Moeda Digital do MIT financia parte do desenvolvimento do Bitcoin Core. O projeto também mantém a biblioteca de criptografia libsecp256k1.
O Bitcoin Core pode ser usado como um cliente de desktop para pagamentos regulares ou como um utilitário de servidor para comerciantes e outros serviços de pagamento.

## Nome Controverso

Algumas pessoas como Peter Todd, Luke-jr e Greg Maxwell alertaram contra a renomeação para o Bitcoin Core porque isso implicava uma centralização.

## Características

O Bitcoin Core inclui um mecanismo de verificação de transação e se conecta à rede bitcoin como um nó completo. Além disso, uma carteira de criptomoeda, que pode ser usada para transferir fundos, é incluída por padrão. A carteira permite o envio e recebimento de bitcoins. Não facilita a compra ou venda de bitcoin. Ele permite que os usuários gerem QR codes para receber pagamento.
O software valida todo o blockchain, que inclui todas as transações bitcoin de todos os tempos. Esta lista distribuído, que atingiu mais de 155 gigabytes de tamanho, deve ser baixada ou sincronizada antes que ocorra a participação total do cliente. Embora o blockchain completo não seja necessário de uma só vez, uma vez que é possível executar no modo de remoção. Um daemon baseado em linha de comando com uma interface JSON-RPC, é empacotado com o Bitcoin Core. Ele também fornece acesso ao "testnet", um ambiente de teste global que imita a rede principal do bitcoin usando uma blockchain alternativa, na qual são usados "bitcoins de teste" sem valor. "Regtest" ou "Regression Test Mode" cria um blockchain privado que é usado como um ambiente de teste local. Finalmente, o cliente bitcoin, um programa simples que permite aos usuários enviar comandos RPC para bitcoind, também está incluído.
Os pontos de verificação que foram codificados no cliente são usados apenas para impedir ataques de negação de serviço contra nós que estão inicialmente sincronizando a cadeia. Por esta razão, os pontos de verificação incluídos são apenas datados de há alguns anos. Um limite de tamanho de bloco de um megabyte foi adicionado em 2010 por Satoshi Nakamoto. Isso limitou a capacidade máxima da rede a cerca de três transações por segundo. Desde então, a capacidade da rede foi melhorada de forma incremental, tanto através de aumentos de tamanho de bloco quanto de melhor comportamento da carteira. Um sistema de alerta de rede foi incluído por Satoshi Nakamoto como forma de informar os usuários sobre notícias importantes sobre o bitcoin. Em novembro de 2016, foi aposentado. Tornou-se obsoleto porque as notícias sobre o bitcoin são agora amplamente divulgadas.
O Bitcoin Core inclui uma linguagem de script inspirada em Forth que pode definir transações e especificar parâmetros. "ScriptPubKey" é usado para "bloquear" transações com base em um conjunto de condições futuras. O "scriptSig" é usado para atender a essas condições ou "desbloquear" uma transação. As operações nos dados são executadas por vários 'OP_Codes". Duas pilhas são usadas: "main" e "alt". Laço de repetição é proibido.

## Funcionalidades

* Implementação de software mais popular de um nó completo bitcoin. Fornece validação confiável de que todas as regras de consenso do bitcoin estão sendo seguidas.
* Tem uma interface RPC que permite aos desenvolvedores interagir com o Core e acessar a moeda bitcoin sem confiança.
* Tem uma interface GUI, Bitcoin-Qt, permitindo que usuários comuns usem bitcoin com validação completa.
* Compatibilidade com o Linux (ambos GNOME e KDE), Mac OS X e Windows
* Todas as funcionalidades do cliente wxWidgets original
* Solicita confirmação antes de enviar moedas
* Exportação de transações em CSV
* Lista de transações mais clara com ícones de status e filtragem em tempo real
* Barra de progresso no download do bloco inicial
* Idiomas: holandês, inglês, alemão, chinês e muito mais. As traduções estão sendo feitas por voluntários no Transifex.
* Suporte Sendmany na interface do usuário (enviar para vários destinatários em uma transação)
* Suporte a várias unidades, pode mostrar bitcoins subdivididos (mBTC, µBTC) para usuários que gostam de números grandes (apenas unidades decimais)
* Tela inicial que detalha o progresso
* Janela de depuração
* Pedidos de pagamento (BIP 70)
* Controle de moeda

## Desenvolvimento

O criador original do cliente bitcoin descreveu sua abordagem à autoria do software como sendo escrita primeiro para provar a si mesma que o conceito de dinheiro eletrônico puramente ponto a ponto era válido e que um papel com soluções poderia ser escrito. Enquanto a maioria dos pares na rede pode usar o Bitcoin Core, a influência dos desenvolvedores sobre o bitcoin é limitada pela escolha de qual implementação as pessoas voluntariamente decidem usar. O principal desenvolvedor é Wladimir J. van der Laan, que assumiu o cargo em 8 de abril de 2014. Gavin Andresen foi o antigo responsável pela manutenção do cliente de software. Andresen deixou o cargo de desenvolvedor líder de bitcoin para trabalhar no desenvolvimento estratégico de sua tecnologia. Ele foi embora porque não queria se envolver com decisões triviais.
O código foi originalmente armazenado no Sourceforge antes de estar disponível no GitHub. Como não há estrutura formal, o desenvolvimento é baseado em Propostas de Melhoria de Bitcoin ou BIPs, que são semelhantes a Solicitação de Comentários. Listas de discussão públicas são usadas para examinar expressões iniciais de ideias. Se houver suporte suficiente, um documento BIP será gravado. Este é o padrão para compartilhar ideias e obter feedback da comunidade sobre a melhoria do bitcoin e foi iniciado por Amir Taaki em 2011.

## Histórico

Bitcoin 0.1 foi lançado em 9 de janeiro de 2009 por Satoshi Nakamoto com apenas o Windows suportado. Isto foi seguido por algumas pequenas versões de correção de bugs. Em 16 de dezembro de 2009, o Bitcoin 0.2 foi lançado. Ele incluiu uma versão Linux pela primeira vez e fez uso de processadores multi-core para mineração. Na versão 0.3.2, Nakamoto incluiu pontos de verificação como uma salvaguarda. Após o lançamento da versão 0.3.9, Satoshi Nakamoto deixou o projeto e logo depois parou de se comunicar em fóruns online. Por esta altura, o desenvolvimento do software estava sendo realizado por um amplo grupo de desenvolvedores independentes, que é referido como uma comunidade, muitos dos quais tinham várias ideias de como melhorar o bitcoin.
Entre 2011 e 2013, novas versões do software foram lançadas no Bitcoin.org. Os desenvolvedores queriam se diferenciar como criadores de software em vez de defensores do bitcoin e agora manter o bitcoincore.org apenas para o software.
Bitcoin-Qt versão 0.5.0 foi lançado em 1 de novembro de 2011. Ele introduziu um front-end que usa o kit de ferramentas de interface do usuário Qt. O software usava anteriormente o Berkeley DB para gerenciamento de banco de dados. Os desenvolvedores mudaram para o LevelDB no release 0.8 para reduzir o tempo de sincronização do blockchain. A atualização para este lançamento resultou em um fork blockchain menor no 11 de março de 2013. O fork foi resolvido logo em seguida. Os nós de propagação através do IRC foram descontinuados na versão 0.8.2. Nesta liberação, as taxas de transação, também conhecidas como taxas de revezamento, foram reduzidas de 50.000 satoshis para 10.000 satoshis. A partir da versão 0.9.0 o software foi renomeado para Bitcoin Core. As taxas de transação foram reduzidas novamente por um fator de dez, como forma de incentivar as microtransações. Embora o Bitcoin Core não use o OpenSSL para a operação da rede, o software utilizou o OpenSSL para chamadas de procedimento remoto. A versão 0.9.1 foi lançada para remover a vulnerabilidade da rede ao bug "Heartbleed".
A versão 0.10 foi divulgada em 16 de fevereiro de 2015. Introduziu uma biblioteca de consenso que deu aos programadores acesso fácil às regras que governam o consenso na rede. Na versão 0.11.2, os desenvolvedores adicionaram um novo recurso que permitia que as transações ficassem inoperantes até uma hora específica no futuro. Bitcoin Core 0.12.1 was released on April 15, 2016 and enabled multiple soft forks to occur concurrently. Cerca de 100 colaboradores trabalharam no Bitcoin Core 0.13.0 que foi lançado em 23 de agosto de 2016. Ele introduziu mais de dez mudanças significativas.
Em julho de 2016, o garfo flexível CheckSequenceVerify foi ativado.
Em outubro de 2016, a versão 0.13.1 do Bitcoin Core apresentava o soft fork "Segwit", que incluía uma melhoria de dimensionamento com o objetivo de otimizar o blockize de bitcoin. TO patch que foi originalmente finalizado em abril, e 35 desenvolvedores foram contratados para implantá-lo. Este lançamento incluiu o Segregated Witness (SegWit), que teve como objetivo exercer pressão sobre as taxas de transação, bem como aumentar a capacidade máxima de transação da rede. A versão 0.13.1 foi submetida a extensos testes e pesquisas, levando a alguns atrasos em sua data de lançamento. O SegWit impede várias formas de maleabilidade das transações. O SegWit foi ativado por mineradores em 24 de agosto de 2017, no bloco 481.824.
Lançada em fevereiro de 2018, a versão 0.16.0 suporta testemunhas segregadas como o formato de endereço nativo, também chamado de endereços bech32, que foram originalmente desenvolvidos por Peter Wuille e Greg Maxwell.

## Propostas de melhoria de Bitcoin

Uma Proposta de Melhoria de Bitcoin (BIP) é um documento de design, tipicamente descrevendo um novo recurso para Bitcoin com uma especificação técnica concisa do recurso e a justificativa para isso. Isso é muito semelhante ao modo como a Internet "Request for Comments" (RFCs) e "Python Enhancement Proposals" (PEPs) da linguagem de computador Python são usados.
O processo em si é documentado no BIP 2 e o BIP 123 fornece uma categorização.

### 2 Processo BIP, revisado

    BIP 2 especifica o processo BIP. Os números do BIP são concedidos liberalmente. A partir de fevereiro de 2017, foram atribuídos 152 números BIP, mas apenas 27 BIPs atingiram os estágios ativo / final.

### 9 Bits de versão com tempo limite e atraso

    O BIP especifica uma máquina de estados para determinar o consenso de 95% de garfos moles. Houve um garfo flexível do BIP 9 com sucesso, e um deles, a partir de 2017, está aberto para votação.

### 16 Pague ao hash de script

    Permite que as transações sejam enviadas para um hash de script (endereço iniciando com 3) em vez de um hash de chave pública (endereços que começam com 1). Para gastar bitcoins enviados via P2SH, o destinatário deve fornecer um script correspondente ao hash do script e dados que fazem com que o script seja avaliado como verdadeiro. O destinatário pode precisar das assinaturas de várias pessoas para gastar esses bitcoins, ou uma senha pode ser necessária ou os requisitos podem ser completamente exclusivos.

### 32 Define carteiras HD

    Essas carteiras HD ('Hierárquico Determinístico') podem ser compartilhadas parcial ou totalmente com diferentes sistemas.

### 39 Código mnemônico ou sentenças

    Para a geração de carteiras determinísticas.

### 43 Adiciona um "campo de propósito" para uso de carteiras HD

    Determinar a estrutura adicional; por exemplo, o esquema descrito no BIP44 deve usar o valor 44 'como o "propósito".

### 44 Hierarquia lógica para carteiras determinísticas

    com base no algoritmo descrito no BIP32 e no esquema de "finalidade" descrito no BIP43.

### 65 "CHECKLOCKTIMEVERIFY"

    O CLTV permite que uma saída de transação seja inoperante até algum ponto específico no futuro.

### 112 "CHECKSEQUENCEVERIFY"

    O CSV permite fazer um endereço (começando com 3) que não pode gastar o bitcoin recebido, por um período de tempo especificado após o recebimento. Pode-se ter um endereço de 2-de-3 multisig, que atinge a regra de backup, a menos que haja 2-de-3 consenso.

### 141, 143, 144

    Ver SegWit

### 152 Blocos compactos

    Mesclado em 22 de junho de 2016, o Compact Blocks permite uma propagação de bloco mais rápida e foi usado em 97% dos nós em novembro de 2017.