Regras de consenso

Imagine que alguém usa os mesmos fundos de um pagamento anterior para lhe pagar a si e depois a uma loja. Os dois gastos não podem fazer parte de um histórico válido. Para o verificar, o nó acompanha as saídas das transações: registos de montantes e das condições necessárias para os gastar. Quando recebe um bloco, o nó verifica se o bloco cumpre as regras que aplica, não quem o recomendou. Verifica, por exemplo, a disponibilidade das saídas a gastar, as condições de Bitcoin Script e as assinaturas exigidas, Proof of Work e a recompensa permitida ao minerador. Uma violação implica a rejeição. O apoio de uma empresa ou uma maioria de votos na internet não altera o resultado. [1]

O minerador escolhe transações e procura um bloco; o Full Node verifica o resultado de forma independente. Os programadores podem propor uma alteração e publicar software, mas isso, por si só, não muda as regras dos outros nós. Cada operador escolhe o software que executa. Essa escolha determina o que o seu próprio nó aceita, não o que todos os outros têm de aceitar. [2] [1]

O nó também tem regras para transações não confirmadas: quais guarda no Mempool, o seu conjunto local de transações à espera de confirmação, e quais transmite a outros nós. Estas regras locais, chamadas policy, podem ser mais exigentes do que o consenso. A rejeição de uma transação pelo mempool não significa, por si só, que seria inválida num bloco. A política de retransmissão não se aplica à validação de blocos. [3]

Um Soft Fork torna as regras mais restritivas: os blocos válidos segundo as novas regras também cumprem as antigas. Contudo, os nós antigos não verificam as novas condições. Um Hard Fork pode, pelo contrário, permitir um bloco que os nós antigos rejeitam. O mecanismo de ativação ajuda a coordenar a mudança; não garante o acordo de todos nem substitui a decisão dos operadores sobre o software a usar. [4]

Ter o seu próprio Full Node permite verificar os blocos recebidos em vez de confiar num site de exploração de blocos. Um nó pode conhecer vários ramos, ou seja, diferentes continuações de um histórico comum. Entre os ramos válidos, escolhe pelo chainwork, a soma do trabalho atribuído a cada bloco de acordo com a sua dificuldade de mineração. Não se trata de medir a eletricidade realmente consumida nem de contar apenas os blocos. Mais trabalho não justifica violar as regras. Para chegarem ao mesmo resultado, os nós têm de aplicar as regras de forma coerente, mesmo em situações pouco habituais. Um erro no programa pode levá-los a aceitar blocos diferentes. [4] [5]

Um nó pode recusar a retransmissão de uma transação cuja taxa seja demasiado baixa. Mas, se um minerador a incluir num bloco e tanto a transação como o bloco cumprirem o consenso, o nó aceita o bloco. Se o minerador atribuir a si próprio mais do que a quantidade permitida de novos bitcoins, chamada Block Subsidy, mais as taxas das transações do bloco, o nó rejeita o bloco mesmo com Proof of Work válido. A diferença está no motivo da rejeição, não na reputação do minerador. [3] [1]