A newsletter desta semana compartilha uma análise sobre sincronização de full-nodes sem witness antigas. Também incluídas estão nossas seções regulares com descrições de discussões sobre mudanças de consenso, anúncios de novos lançamentos e candidatos a lançamento, e resumos de mudanças notáveis em software popular de infraestrutura do Bitcoin.

Notícias

  • ● Sincronizando nós completos sem dados de testemunha (witness): Jose SK postou no Delving Bitcoin um resumo de uma análise que ele fez sobre os tradeoffs de segurança de permitir que nós completos recém-iniciados com uma configuração em particular evitem baixar alguns dados da blockchain. Por padrão, nós Bitcoin Core usam a configuração assumevalid que pula a validação de scripts em blocos criados mais de um mês ou dois antes do lançamento da versão do Bitcoin Core sendo executada. Embora desabilitado por padrão, muitos usuários do Bitcoin Core também definem uma configuração prune que exclui blocos algum tempo após validá-los (por quanto tempo os blocos são mantidos depende do tamanho dos blocos e da configuração específica selecionada pelo usuário).

    SK argumenta que dados de testemunha (witness), que são usados apenas para validar scripts, não deveriam ser baixados por nós prunados para blocos assumevalid porque eles não os usarão para validar scripts e eventualmente serão excluídos. Pular o download de testemunhas “pode reduzir o uso de banda em mais de 40%”, ele escreve.

    Ruben Somsen argumenta que isso muda o modelo de segurança até certo ponto. Embora scripts não sejam validados, os dados baixados são validados contra o commitment da raiz merkle do cabeçalho do bloco para a transação coinbase para os dados da testemunha. Isso garante que os dados estavam disponíveis e não corrompidos no momento em que o nó foi inicialmente sincronizado. Se ninguém rotineiramente valida a existência dos dados, eles poderiam eventualmente ser perdidos, como aconteceu com pelo menos uma altcoin.

    A discussão estava em andamento no momento da escrita.

Mudando consenso

Uma seção mensal resumindo propostas e discussões sobre mudanças nas regras de consenso do Bitcoin.

  • ● Relatório de computação quântica: Clara Shikhelman postou no Delving Bitcoin o resumo de um relatório que ela co-autorou com Anthony Milton sobre os riscos para usuários Bitcoin de computadores quânticos rápidos, uma visão geral de várias vias para resistência quântica, e uma análise de tradeoffs envolvidos na atualização do protocolo do Bitcoin. Os autores encontraram 4 a 10 milhões de BTC potencialmente vulneráveis a roubo quântico, alguma mitigação é agora possível, e é improvável que a mineração do Bitcoin seja ameaçada pela computação quântica no curto ou médio prazo, e atualizar requer acordo generalizado.

  • ● Limite de peso de transação com exceção para prevenir confisco: Vojtěch Strnad postou no Delving Bitcoin a proposta de uma ideia de mudança de consenso para limitar o peso máximo da maioria das transações em um bloco. A regra simples apenas permitiria uma transação maior que 400.000 unidades de peso (100.000 vbytes) em um bloco se fosse a única transação naquele bloco além da transação coinbase. Strnad e outros descreveram a motivação para limitar o peso máximo da transação:

    • Otimização de template de bloco mais fácil: é mais fácil encontrar uma solução quase ótima para o problema da mochila quanto menores forem os itens comparados ao limite geral. Isso é parcialmente devido à minimização da quantidade de espaço sobrado no final, com itens menores deixando menos espaço não utilizado.

    • Política de retransmissão mais fácil: a política para retransmitir transações não confirmadas entre nós prevê quais transações serão mineradas para evitar desperdiçar largura de banda. Transações gigantes tornam previsões precisas mais difíceis, pois mesmo uma pequena mudança na taxa de topo pode causar que sejam atrasadas ou removidas.

    • Evitando centralização de mineração: garantir que nós completos de retransmissão sejam capazes de lidar com quase todas as transações impede que usuários de transações especiais precisem pagar taxas fora de banda, o que pode levar à centralização de mineração.

    Gregory Sanders notou que poderia ser razoável simplesmente fazer um soft fork de limite de peso máximo sem exceções baseado na política de retransmissão consistente de 12 anos do Bitcoin Core. Gregory Maxwell adicionou que transações gastando apenas UTXOs criados antes do soft fork poderiam ter uma exceção permitida para prevenir confisco, e que um soft fork transitório permitiria que a restrição expirasse se a comunidade decidisse não renová-la.

    Uma discussão adicional examinou as necessidades de partes querendo transações grandes, principalmente usuários BitVM no curto prazo, e se abordagens alternativas estavam disponíveis para eles.

  • ● Removendo saídas do conjunto UTXO baseado em valor e tempo: Robin Linus postou no Delving Bitcoin para propor um soft fork para remover saídas de baixo valor do conjunto UTXO após algum tempo. Várias variações da ideia foram discutidas, sendo as duas principais alternativas:

    • Destruir fundos antigos não econômicos: saídas de pequeno valor que não foram gastas por muito tempo se tornariam ingastáveis.

    • Requerer que fundos antigos não econômicos sejam gastos com prova de existência: utreexo ou um sistema similar poderia ser usado para permitir que uma transação prove que as saídas que ela gasta são parte do UTXO set. Saídas antigas e não econômicas precisariam incluir esta prova, mas saídas mais novas e de maior valor ainda seriam armazenadas no conjunto UTXO.

    Qualquer solução efetivamente limitaria o tamanho máximo do conjunto UTXO (assumindo um valor mínimo e o limite de 21 milhões de bitcoins). Vários aspectos técnicos interessantes de um design foram discutidos, incluindo alternativas às provas Utreexo para esta aplicação que poderiam ser mais práticas.

Lançamentos e candidatos a lançamento

Novos lançamentos e candidatos a lançamento para projetos populares de infraestrutura do Bitcoin. Por favor, considere atualizar para novos lançamentos ou ajudar a testar candidatos a lançamento.

  • ● Core Lightning 25.05rc1 é um candidato a lançamento para a próxima versão principal desta implementação popular de nó LN.

  • ● LND 0.19.1-beta.rc1 é um candidato a lançamento para uma versão de manutenção desta implementação popular de nó LN.

Mudanças notáveis em código e documentação

Mudanças recentes notáveis no Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, e BINANAs.

  • ● Bitcoin Core #32582 adiciona novo logging para medir o desempenho da reconstrução de bloco compacto rastreando o tamanho total de transações que um nó solicita de seus pares (getblocktxn), o número e tamanho total de transações que um nó envia para seus pares (blocktxn), e adicionando um timestamp no início de PartiallyDownloadedBlock::InitData() para rastrear quanto tempo apenas o passo de busca no mempool leva (em modos de alta e baixa largura de banda). Veja Newsletter #315 para um relatório de estatísticas anterior sobre reconstrução de bloco compacto.

  • ● Bitcoin Core #31375 adiciona uma nova ferramenta CLI bitcoin -m que envolve e executa os binários multiprocesso bitcoin node (bitcoind), bitcoin gui (bitcoinqt), bitcoin rpc (bitcoin-cli -named). Atualmente, estes funcionam da mesma forma que os binários monolíticos, exceto que suportam a opção -ipcbind (veja Newsletter #320), mas melhorias futuras permitirão que um operador de nó inicie e pare componentes independentemente em diferentes máquinas e ambientes. Veja Newsletter #353 para um Bitcoin Core PR Review Club cobrindo este PR.

  • ● BIPs #1483 incorpora BIP77 que propõe payjoin v2, uma variante assíncrona sem servidor na qual o remetente e receptor entregam seus PSBTs criptografados para um servidor de diretório payjoin que apenas armazena e encaminha mensagens. Como o diretório não pode ler ou alterar as cargas úteis, nenhuma carteira precisa hospedar um servidor público ou estar online ao mesmo tempo. Veja Newsletter #264 para contexto adicional sobre payjoin v2.