O boletim informativo Bitcoin Optech fornece aos leitores um resumo de alto nível das notícias técnicas mais importantes que acontecem no Bitcoin, junto com recursos que os ajudam a aprender mais. Para ajudar nossos leitores a se manterem atualizados com o Bitcoin, estamos republicando a última edição deste boletim informativo abaixo. Lembre-se de se inscrever para receber este conteúdo diretamente em sua caixa de entrada.
O boletim informativo desta semana resume uma discussão sobre um novo opcode proposto e links para uma página wiki atualizada para acompanhar o suporte bech32m. Também estão incluídas nossas seções regulares com destaques de uma reunião do Bitcoin Core PR Review Club, sugestões sobre a preparação para a raiz principal e descrições de mudanças notáveis em projetos populares de infraestrutura de Bitcoin.
Notícias
Solicitação de design OP_CHECKSIGFROMSTACK sugestões: Jeremy Rubin postou no mailing Bitcoin-Dev liste um rascunho de especificação para um código de operação OP_CHECKSIGFROMSTACK e solicite feedback de qualquer desenvolvedor que prefira uma alternativa Projeto. Algumas alternativas foram discutidas, mas a discussão também se ramificou em uma discussão sobre se um OP_CAT opcode deve ser introduzido ao mesmo tempo. OP_CAT e OP_CSFS permitiriam a introspecção de transação arbitrária-a capacidade de receber bitcoins para um script que poderia verificar quase qualquer parte da transação que posteriormente gasta esses bitcoins. Isso pode ativar muitos recursos avançados (incluindo versões 1 de outros atualizações propostas como SIGHASH_ANYPREVOUT e OP_CHECKTEMPLATEVERIFY ), mas OP_CAT também torna possível criar convênios que poderiam restringir permanentemente a capacidade de compra de quaisquer bitcoins comprometidos com o convênio. Algumas pessoas se opuseram à permissão de convênios em Bitcoin, mas vários argumentos foram feito no sentido de que o pior caso de problemas de convênios recursivos já existem no Bitcoin hoje, então nós não deve se preocupar em habilitar OP_CAT ou um opcode semelhante. Apesar da discussão, Rubin decidiu que queria manter sua proposta OP_CSFS independente de qualquer proposta para adicionar OP_CAT, argumentando que OP_CSFS é útil o suficiente por si só. Acompanhamento de suporte bech32m: a página Wiki do Bitcoin para adoção do bech32 foi atualizado para rastrear quais softwares e serviços suportam os gastos ou recebendo em bech32m endereços para taproot. Bitcoin Core PR Review Club
Nesta seção mensal, resumimos uma reunião recente do Bitcoin Core PR Review Club , destacando algumas das questões importantes e respostas. Clique em uma pergunta abaixo para ver um resumo da resposta da reunião.
Use scripts de ajuda para criar P2 {PKH, SH , WPKH, WSH} scripts é um PR de Sebastian Falbesoner que substitui a criação manual de script por chamadas para funções auxiliares script_util em testes funcionais e corrige um erro na função get_multisig (). A reunião do clube de revisão dividiu a terminologia e cada um dos tipos de saída de script usados no PR. O que key_to_p2pkh_script, script_to_p2sh_script, key_to_p2wpkh_script e script_to_p2wsh_script em script_util.py fazem?
Estas são funções auxiliares para construir objetos CScript para Hash de chave pública , Pay to Script Hash, Pay to Witness Public Key Hash e Pay to Witness Script Hash de scripts de chaves públicas e scripts. ➚ Defina scriptPubKey, scriptSig e testemunha.
O scriptPubKey e scriptSig são campos na saída e entrada de uma transação, respectivamente, para especificar e satisfazer as condições de gasto. A testemunha é um campo adicional para o mesmo propósito introduzido com a Testemunha Segregada. Os requisitos de gastos são comprometidos em um scriptPubKey de saída e a entrada que gasta deve ser acompanhada por dados que satisfaçam essas condições no scriptSig e/ou testemunha. ➚ Defina o script de resgate e o script de testemunha. Qual é a relação entre eles?
Os tipos de saída P2SH e P2WSH são confirmados em um hash de script no scriptPubKey. Quando a saída é gasta, o gastador deve fornecer o próprio script, junto com quaisquer assinaturas ou outros dados necessários para fazê-lo passar. O script é chamado de redemScript quando contido no scriptSig e um script de testemunha quando na testemunha. Nesse sentido, eles são análogos; um redemScript é para uma saída P2SH o que um script testemunha é para uma saída P2WSH. Eles não são mutuamente exclusivos, entretanto, uma vez que uma transação que gasta uma saída P2SH-P2WSH contém ambos. ➚ Para enviar moedas a alguém com condições de gasto codificadas em um script, o que está incluído no scriptPubKey de a saída? O que precisa ser fornecido na entrada quando a moeda é gasta?
O scriptPubKey inclui o hash do script e opcodes para verificar uma correspondência: OP_HASH160 OP_PUSHBYTES_20 <20B script hash> OP_EQUAL. O scriptSig inclui o próprio script e a pilha inicial. ➚ Por que usamos Pay-To-Script-Hash em vez de Pay-To-Script?
A principal motivação, conforme declarado em BIP16 é criar um forma genérica de financiar transações arbitrariamente complexas, colocando o ônus de fornecer as condições de gasto sobre quem resgata os fundos. Os participantes também mencionaram que manter o script fora do scriptPubKeys significa que suas taxas associadas não são pagas até o resgate e resulta em um conjunto UTXO menor. ➚ Quando um nó não segwit valida uma entrada P2SH-P2WSH, o que ele faz? O que um nó habilitado para segwit faz além do procedimento executado por um nó não segwit?
O nó não segwit nunca vê a testemunha; ele simplesmente impõe regras P2SH verificando se o redemScript corresponde ao hash confirmado no scriptPubKey. Um nó segwit reconhece esses dados como um programa testemunha e usa os dados testemunha e o scriptCode apropriado para impor regras segwit. ➚ O que há de errado com o script P2SH-P2WSH no original get_multisig () função?
Ele usa o script de testemunha em vez da função?
seu hash no script de resgate P2SH-P2WSH. ➚ Preparação para a raiz principal nº 4: de P2WPKH para P2TR de assinatura única
Uma série semanal sobre como os desenvolvedores e provedores de serviço podem se preparar para a ativação futura da raiz principal na altura do bloco 709.632.
Para carteiras que já suportam o recebimento e o gasto de saídas v0 segwit P2WPKH, atualizar para v1 segwit P2TR para assinatura única deve ser fácil. Aqui estão as etapas principais: Use um novo caminho de derivação de chave BIP32: você não precisa alterar seu BIP32 Código Hierárquico Determinístico (HD) e seus usuários não precisam mudar suas sementes. 2 No entanto, você é fortemente encorajado a usar um novo caminho de derivação para suas chaves públicas P2TR (como definido por BIP86 ); se você não fizer isso, haverá um possível ataque que pode ocorrer se você usar as mesmas chaves com ECDSA e assinaturas schnorr .Tweak sua chave pública por seu hash: embora tecnicamente não seja necessário para assinatura única, especialmente quando todas as suas chaves são derivadas de uma semente BIP32 escolhida aleatoriamente, BIP341 recomenda que sua chave seja enviada para uma árvore de scripthash que não pode ser gasta. Isso é tão simples quanto usar uma operação de adição de curva elíptica que soma sua chave pública com o ponto da curva do hash dessa chave. As vantagens de cumprir essa recomendação são que você poderá usar o mesmo código se posteriormente adicionar multisignature suporte ou se você adicionar suporte para descritores tr () .Crie seus endereços e monitore-os: use bech32m para criar seus endereços. Os pagamentos serão enviados para o scriptPubKey OP_1
Lançamentos e candidatos a lançamento
Novos lançamentos e candidatos a lançamento para projetos populares de infraestrutura de Bitcoin. Considere atualizar para novos lançamentos ou ajudar a testar os candidatos a lançamento. LND 0,13.1-beta.rc2 é uma versão de manutenção com pequenas melhorias e correções de bugs para recursos introduzidos em 0.13.0-beta.
Código notável e mudanças na documentação
Mudanças notáveis esta semana em Bitcoin Core , C-Lightning , Eclair , LND , Rust-Lightning , libsecp256k1 , Hardware Wallet Interface (HWI) , Rust Bitcoin , Servidor BTCPay , Bitcoin Improvement Proposals (BIPs) e Lightning BOLTs . C-Lightning # 4625 atualiza sua implementação de ofertas LN para corresponder às últimas alterações de especificação . Notavelmente, as ofertas não precisam mais conter uma assinatura. Isso encurta significativamente a string codificada para ofertas, melhorando a capacidade de reconhecimento do código QR. Eclair # 1746 adiciona suporte para replicar dados para um banco de dados PostgreSQL em paralelo ao banco de dados SQLite primário. O recurso visa facilitar o teste de servidores que desejam fazer uma eventual transição de back-end. No ano passado, o engenheiro da Suredbits Roman Taranchenko descreveu a personalização do Eclair para uso empresarial com um back-end PostgreSQL em um campo Optech relatório . LND # 5447 adiciona um documento que descreve como configurar vários nós LND em um cluster com um banco de dados alternativo que é replicado entre os nós do cluster e que permite failover automático. Os leitores interessados podem comparar isso com a abordagem adotada pela Eclair e descrita em Boletim informativo nº 128 . Libsecp256k1 # 844 faz várias atualizações na API para assinaturas schnorr . O mais notável é um commit que permite assinar e verificar mensagens de qualquer comprimento. Todos os usos atuais de assinaturas em Bitcoin assinam um hash de 32 bytes, mas permitir a assinatura de dados de comprimento variável pode ser útil para aplicativos fora do Bitcoin ou para habilitar um novo opcode, como OP_CHECKSIGFROMSTACK para verificar assinaturas criadas para sistemas não Bitcoin. Espera-se que a especificação BIP340 de assinaturas schnorr para Bitcoin seja atualizado para descrever a assinatura segura de dados de comprimento variável. BIPs # 943 atualizações BIP118 para construir em taproot e tapscript que logo serão ativados em vez de SegWit v0. Além disso, esta revisão renomeia o título para SIGHASH_ANYPREVOUT de SIGHASH_NOINPUT para refletir que a sinalização sighash agora é referida como “ANYPREVOUT”, visto que, embora qualquer prevout possa ser potencialmente usado com a assinatura, alguns aspectos da entrada ainda estão comprometidos. BTCPay Server # 2655 sinaliza aos navegadores da web que eles não devem enviar o campo de referência HTTP quando o usuário clicar em um link para uma transação em um block explorer . Isso evita dizer ao explorador de blocos de qual servidor BTCPay o usuário veio-essa informação é uma forte evidência de que o servidor originou ou recebeu a transação que está sendo visualizada no explorador de blocos. Mesmo com essa mudança, os usuários que desejam privacidade forte ainda devem evitar procurar suas próprias transações em exploradores de blocos de terceiros. Notas de rodapé Usando OP_CHECKSIGFROMSTACK (OP_CSFS) para implementar o recurso principal de propostas como BIP118 do SIGHASH_ANYPREVOUT ou O OP_CHECKTEMPLATEVERIFY de BIP119 exigiria mais espaço de bloco do que as propostas otimizadas se o scriptpath fosse gasto é usado. O argumento a favor do OP_CSFS é que ele permite começando com uma construção genérica e provando que as pessoas realmente usarão o recurso antes que uma mudança de consenso seja usada para adicionar uma implementação mais eficiente. Além disso, com a introdução dos gastos do caminho-chave taproot , qualquer script pode ser resolvido com o uso mínimo de bloquear espaço em alguma situação, possivelmente reduzindo a necessidade de construções específicas que economizam espaço em situações não ideais. ↩ Quando Electrum atualizou para o segwit v0, exigiu que qualquer pessoa queria receber endereços de bech32 para gerar novas sementes. Isso não era tecnicamente necessário, mas permitiu aos autores do Electrum introduzir alguns novos recursos em seu método de derivação de sementes personalizado. Um desses recursos era a capacidade de um número de versão do seed especificar com quais scripts um seed deve ser usado. Isso permite a depreciação segura de scripts antigos (por exemplo, uma versão futura do Electrum pode ser lançada que não suporta mais o recebimento de endereços P2PKH legados).
Na mesma época em que os desenvolvedores Electrum estavam implantando suas sementes versionadas, os desenvolvedores Bitcoin Core começaram usando descritores de script de saída para resolver o mesmo problema de permitir a suspensão de uso do script (além para resolver outros problemas). A tabela a seguir compara as sementes versionadas do Electrum e os descritores do Bitcoin Core ao método de scripts implícito anteriormente usado por ambas as carteiras e ainda em uso comum entre a maioria das outras carteiras.
Encontre o postagem original aqui.
assine o boletim informativo Bitcoin Optech diretamente para receber este conteúdo diretamente em sua caixa de entrada todos os meses.
