Bitcoin Core

Pavel vende livros em troca de bitcoin. Uma cliente mostra-lhe um comprovativo no telemóvel, mas ele quer saber se o pagamento realmente chegou e consta de um bloco válido. Pode consultar um explorador público ou usar uma carteira ligada ao seu próprio nó. Bitcoin Core é o programa que mantém esse nó: recebe dados de outros, mas avalia a sua validade por si. Aqui, um nó é um computador com um programa que verifica as regras de Bitcoin de forma independente; um bloco é um conjunto de transações acrescentado ao histórico partilhado. Pavel é um exemplo ilustrativo. O objetivo é substituir a simples confiança num aviso alheio por uma verificação própria. Instalar o programa não o torna minerador, não lhe oferece BTC nem permite reverter pagamentos de outras pessoas. O código é publicado sob a licença MIT, que permite estudá-lo, modificá-lo e redistribuí-lo segundo as suas condições. [1] [16]

É fácil confundir as funções porque Bitcoin Core pode desempenhar ambas. O nó verifica o histórico e os novos blocos. A carteira acompanha os fundos relevantes, cria endereços e prepara transações; se gerir chaves privadas, também pode assinar com elas. Uma chave privada é um dado secreto que a carteira usa para criar uma assinatura digital que autoriza gastar os bitcoins correspondentes. A chave em si não é enviada aos outros nós. Mas Core funciona igualmente sem carteira. Pavel pode usar outra aplicação compatível para pagar e o seu nó como fonte de dados verificados; algumas ligações exigem software adicional. Ter Core a funcionar não encaminha automaticamente todas as outras carteiras para esse nó. Para reconhecer os nomes: bitcoin-qt oferece a interface gráfica, bitcoind funciona em segundo plano e bitcoin-cli envia comandos ao programa. [12] [17]

Um nó novo precisa de recuperar o histórico. É a Initial Block Download, ou IBD, a transferência inicial de blocos. Na sincronização habitual, descarrega blocos e verifica a ligação entre eles, o trabalho dos mineradores e as regras das transações. Assim constrói o chainstate: o seu registo local de saídas ainda não gastas, chamadas UTXO. Uma saída de transação indica um montante e as condições para o gastar, como uma assinatura necessária. Permanece nesse registo até ser gasta por outra transação. Não é uma lista de nomes e contas bancárias. A velocidade depende do computador, disco e ligação; um início lento não significa necessariamente uma avaria. Pavel confirma que a sincronização terminou antes de verificar pagamentos atuais.

Há uma ressalva: assumevalid pode dispensar verificações de scripts, ou seja, condições de gasto, na parte mais antiga do histórico sob determinadas condições; -assumevalid=0 desativa esse atalho. Outra função, AssumeUTXO, permite começar com um instantâneo de estado verificado e processar o histórico anterior em segundo plano. O instantâneo guarda o estado dos UTXO num determinado bloco. Primeiro, o programa compara o seu hash, uma impressão digital, com o valor esperado no código; isso ainda não significa que tenha verificado de forma independente todo o histórico anterior. São pressupostos diferentes: nem todas as instalações fizeram exatamente as mesmas verificações desde o primeiro momento. [9] [10] [12] [17]

Depois de sincronizado, Core continua a receber dados dos nós ligados, conhecidos como peers. Guarda as transações não confirmadas que aceita no seu Mempool, uma sala de espera temporária. Estar ali não equivale a uma confirmação num bloco, e o conteúdo pode variar entre nós. Ao receber um bloco, Core verifica-o. Entre cadeias candidatas válidas, escolhe a que acumula mais trabalho, não a que tem mais votos de computadores ou simplesmente mais blocos. Pavel distingue, portanto, ver um pagamento de o ter confirmado. O seu nó não garante inclusão imediata nem elimina reorganizações, nas quais outro ramo válido substitui parte do histórico que estava a seguir. [16]

Suponha que o nó de Pavel não admite uma transação não confirmada no Mempool. Isso não implica que ela nunca possa aparecer num bloco válido. As regras de consenso definem blocos e gastos válidos para o nó. A relay policy local acrescenta condições sobre as transações não confirmadas que aceita e retransmite, por exemplo para proteger os seus recursos contra sobrecarga. Essa política não se aplica da mesma forma às transações dentro de um bloco recebido: aí conta a validade segundo o consenso. Configurações diferentes do Mempool não dividem, por si só, a rede. Esta distinção ajuda a acompanhar debates sobre Core sem confundir cada ajuste com uma alteração das regras monetárias. [13]

Core guarda dados de blocos, o estado do nó e, se forem usadas, carteiras. Pruning poupa espaço eliminando ficheiros antigos de blocos e dados necessários para desfazer os seus efeitos depois do processamento. O nó continua a verificar novos blocos; apenas deixa de ter todo o arquivo disponível. Consultas históricas ou novas pesquisas de pagamentos antigos podem exigir outra transferência de dados. Os índices aceleram pesquisas; txindex, por exemplo, é incompatível com pruning. Devem ser escolhidos em função do serviço pretendido. A diferença fundamental é esta: os blocos públicos podem ser descarregados novamente, mas não recuperam chaves privadas perdidas. Uma carteira Core precisa da sua própria cópia de segurança. Com o programa em funcionamento, use a função de cópia, como backupwallet, em vez de copiar uma base de dados enquanto está a ser escrita. [11] [12]

Pavel começa no site oficial e lê as instruções da versão escolhida. Uma soma SHA-256 é a impressão digital do ficheiro descarregado: deteta diferenças face ao esperado. Sozinha, não identifica quem publicou essa impressão. Por isso também é necessário verificar assinaturas digitais e a identidade das respetivas chaves. Se um atacante fornecer o programa e a sua própria soma, a coincidência entre ambos não impede o ataque. Para uma verificação mais profunda, o projeto usa compilações reproduzíveis: pessoas independentes podem obter ficheiros idênticos a partir do mesmo código e comparar resultados. Guix ajuda a uniformizar o ambiente de compilação. Isso reforça a verificação da origem do programa, mas não prova que o código esteja livre de erros. [8] [7]

Core disponibiliza JSON-RPC, uma interface através da qual outros programas o podem controlar. Permite consultar o estado e ligar serviços, mas, conforme as carteiras e permissões disponíveis, também pode permitir operações com fundos. As credenciais não devem ser entregues a um suposto ajudante. A interface não cifra por si o tráfego e não foi concebida para exposição à Internet. As ligações normais aos outros nós Bitcoin são diferentes da abertura destes controlos. Para acesso local, Core também usa credenciais temporárias no ficheiro .cookie. A administração remota exige uma ligação protegida e acesso limitado, segundo a documentação. Experimentar um nó não obriga a abrir a sua administração ao mundo. [14]

Qualquer pessoa pode propor alterações ao código. Outros colaboradores leem, testam e discutem a proposta; os responsáveis pelo repositório, os maintainers, podem integrar alterações aceites. Isso não lhes dá controlo remoto sobre o nó de Pavel. O operador escolhe o programa que executa. Essa escolha também não é um voto que permita a uma pessoa mudar as regras de todas as outras: uma alteração incompatível pode separar o seu nó do resto. Bitcoin Core é uma implementação importante das regras, não uma empresa dona da rede inteira. Ao ler anúncios, distinga proposta, integração no código, publicação de uma versão e adoção real. Entre essas etapas pode haver um longo percurso. [15]

Pode começar por manter um nó sem guardar nele chaves privadas. Pavel verifica o ficheiro e as assinaturas, deixa a IBD terminar e confirma que a carteira escolhida utiliza mesmo os dados do seu nó. Depois acompanha ligações, progresso dos blocos e espaço livre. Antes de atualizar, lê as release notes, que explicam alterações e possíveis condições de migração; se usar uma carteira, verifica a cópia de segurança e a recuperação. O ficheiro de diagnóstico debug.log ajuda a investigar problemas, mas não deve ser publicado sem ponderação. Pruning, índices e RPC devem corresponder ao uso, não a um guia copiado cegamente. Um nó próprio deve ser uma ferramenta de verificação compreensível. Não é obrigatório numa primeira compra pequena, mas faz sentido para perceber por que considera válidos os seus pagamentos. [12] [14]