Miniscript

Anna quer utilizar as suas moedas normalmente com a própria chave. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Uma carteira é uma aplicação ou um dispositivo para receber e enviar bitcoins. Anna também quer preparar uma alternativa para Peter, que poderá gastá-las com a chave dele depois de 144 blocos desde a confirmação daquela saída. Esta intenção chama-se spending policy: as regras de gasto. Miniscript ajuda a dar-lhe uma forma precisa com que a carteira consegue trabalhar. Peter continua a precisar da chave; esperar não a substitui. É um exemplo simples de caminhos alternativos de acesso, não uma transferência automática nem um mecanismo que deteta a perda da chave de Anna. [1] [2] [10]

Uma regra escrita em palavras ainda não é o programa que a rede verifica. Um compilador pode escolher um Miniscript concreto e convertê-lo em Bitcoin Script. Um Output Descriptor descreve depois os scripts com as chaves e eventuais caminhos de derivação; pode também incluir uma soma de verificação para detetar erros de cópia. Ao gastar, a rede verifica o script e os dados apresentados, não a frase original. Miniscript não acrescenta instruções nem altera o consenso, as regras comuns de validade. Não consegue representar qualquer Bitcoin Script imaginável. [1] [3] [6]

Um bloco reúne transações num lote acrescentado ao histórico partilhado. No exemplo de Peter, os 144 blocos contam desde a confirmação da saída, uma quantia específica com condições de gasto. Não correspondem a um dia exato nem ao tempo desde a criação da carteira. Miniscript escreve a espera relativa como older(n), usando CSV e o campo nSequence da entrada que gasta essa saída, cujo significado para verificar a idade é definido por BIP 68. Já after(n) usa CLTV e o nLockTime absoluto: uma altura ou um limite temporal fixos. A carteira deve configurar corretamente os campos da transação e cumprir as restantes condições. Bloqueios por altura e por tempo não podem ser combinados de forma incompatível; esperar, por si só, não envia nada. [1] [7] [8] [9] [11]

Mostrar a descrição das regras não chega. A carteira precisa de fornecer dados que satisfaçam um caminho permitido, como assinaturas ou um segredo cujo hash corresponda ao exigido, chamado preimage. Um hash é uma impressão digital dos dados; aqui verifica-se se o segredo apresentado produz a impressão exigida. Esse cumprimento chama-se satisfaction; os dados necessários fazem parte do witness da transação. Ao combinar ramos, pode ser preciso tornar uma subcondição falsa da forma prevista para seguir outro caminho. Isso é uma dissatisfaction, não a invalidade do pagamento inteiro. O software pode preparar o percurso adequado, mas não inventar uma chave privada em falta nem um segredo desconhecido. [1] [12]

PSBT é um formato para passar uma transação preparada e informação complementar entre a carteira e os dispositivos de assinatura. Suportar PSBT não basta: o programa e a Hardware Wallet têm de compreender o descriptor e as suas condições. Bitcoin Core acrescentou a observação de Miniscript em P2WSH na versão 24, a assinatura na versão 25 e a utilização em descriptors Taproot na versão 26. Observar moedas não é o mesmo que conseguir gastá-las. Na configuração, confirme num ecrã de confiança as chaves, as assinaturas necessárias, os prazos e todos os caminhos alternativos, conforme as capacidades reais do dispositivo. [3] [4] [5]

Uma Seed Phrase recupera chaves, mas numa condição personalizada pode não revelar como foram combinadas com outras chaves e com o script. Esta cópia de segurança é uma sequência de palavras a partir da qual a carteira pode derivar as suas chaves. Guarde o descriptor exato com a soma de verificação, o mapa de chaves, os caminhos de derivação e a distinção entre endereços de receção e de troco. Registe separadamente a rede, o intervalo de endereços e o ponto de início da pesquisa no histórico. Um descriptor público não é uma chave privada, mas pode revelar o histórico de pagamentos. Antes de usar este esquema, teste a recuperação de uma carteira de observação e cada caminho de gasto previsto num ambiente Regtest ou Signet. [5] [6]

pk(), older(), after() e sha256() representam assinaturas, esperas ou a exigência de um segredo. and_v(), or_d() e thresh() combinam condições. Invólucros como v: ajustam a avaliação, preservando o significado da subexpressão. Os tipos B, V, K e W controlam como as partes passam elementos na pilha, a área de trabalho do script; nem todas as peças encaixam. A verificação de tipos pode detetar uma composição incompatível. Não decide, porém, em quem Anna deve confiar nem se escolheu uma alternativa sensata. [1] [2]

A estrutura permite analisar antecipadamente o tamanho do script e do witness, as operações, as verificações de assinaturas e os elementos da pilha. Isso ajuda a estimar os custos dos vários caminhos e a detetar limites excedidos. O contexto importa: P2WSH coloca as condições em SegWit, enquanto Tapscript designa os scripts usados em Taproot. Os seus limites diferem em alguns aspetos. Além do consenso, aplicam-se as regras habituais de retransmissão de transações. O resultado da análise não certifica que qualquer carteira execute o procedimento pretendido. [1]

A chave pública serve para verificar assinaturas e não precisa de ser mantida em segredo. A análise de malleability verifica se alguém de fora pode transformar uma satisfaction válida noutra também válida. As garantias têm pressupostos específicos: o atacante não possui chaves privadas dos participantes, não conhece mais preimages do que o utilizador honesto e vê apenas uma satisfaction. Pressupõem-se também chaves públicas não repetidas e as regras habituais de aceitação; um mineiro pode ter opções indisponíveis a um nó comum de retransmissão. Não é uma garantia contra todos os participantes maliciosos, a perda de cópias ou um mau esquema de custódia. Essas questões precisam de avaliação própria. [1]

Um compilador pode exprimir as mesmas regras de várias formas, com tamanhos diferentes de script e witness. Escolhe segundo um modelo de custos. Uma marca como 9@ num ramo da linguagem de políticas indica a probabilidade relativa de utilização; não é um número de assinaturas nem uma autorização da rede. Outra compilação pode produzir outro script e, portanto, outros endereços. Para recuperar a carteira, não basta voltar a descrever as regras por palavras próprias e compilá-las. São importantes a representação exata guardada, a verificação dos endereços derivados e um caminho de assinatura testado. [2] [5]