134 / 736SCHNORR

Schnorr Signature

Assinatura de Schnorr

Quando uma carteira assina um pagamento, não cria uma imagem de uma assinatura nem envia a sua chave privada. Produz uma prova que a rede consegue verificar. Schnorr Signature permite criar essa prova de forma compacta e também que várias pessoas assinem em conjunto. No Bitcoin, é utilizada com Taproot.

Schnorr Signature permite aprovar digitalmente uma mensagem específica sem revelar uma chave privada. A carteira cria a assinatura com essa chave secreta; os outros precisam apenas da chave pública correspondente para a verificar. No Bitcoin, a assinatura ajuda a demonstrar autorização para gastar moedas, mas não substitui as restantes verificações da transação. O BIP340 define a variante Bitcoin utilizada com Taproot.

Alice quer enviar bitcoin para Bob. Uma carteira é uma aplicação ou um dispositivo para receber e enviar bitcoins. A carteira prepara a transação e assina, com a chave privada, os dados exigidos pelo modo de assinatura escolhido. Depois, um nó verifica a assinatura e todas as outras condições de gasto. Um nó é um programa que verifica transações e blocos e troca dados com outros participantes da rede. Uma assinatura válida, por si só, não comprova a identidade civil de Alice, a escolha do destinatário certo nem a existência de fundos não gastos suficientes: são questões distintas. Um pagamento assinado ainda pode ser um erro involuntário. [5] [3] [10] [11]

O BIP340, de Pieter Wuille, Jonas Nick e Tim Ruffing, define com precisão a assinatura Schnorr do Bitcoin. O BIP341 integra-a nas regras de gasto de Taproot, ativadas na rede principal do Bitcoin (Mainnet) no bloco 709632, em 2021. Um bloco reúne transações num lote acrescentado ao histórico partilhado. São duas camadas: o algoritmo de assinatura e as condições de gasto. Saídas antigas e SegWit v0 continuam a utilizar ECDSA, o algoritmo de assinatura anterior; a atualização não substituiu retroativamente as suas assinaturas. [1] [2] [11]

Byte é uma unidade comum para medir dados. A variante Bitcoin utiliza a curva elíptica secp256k1, uma estrutura matemática para trabalhar com chaves e assinaturas. O BIP340 estabelece um formato fixo de assinatura com 64 bytes. A chave pública é representada pelos 32 bytes da coordenada x; x-only não significa omitir uma verificação de segurança. As regras também determinam sem ambiguidade qual variante do ponto da curva deve ser usada na verificação. Um formato menor e precisamente definido facilita o trabalho do software, mas esses dois números não indicam, por si só, o tamanho de uma transação inteira. [1] [12]

A carteira não assina um vago «concordo». O modo sighash determina quais os dados da transação que formam a mensagem assinada. SIGHASH_DEFAULT protege informações sobre todas as entradas e saídas, à semelhança de SIGHASH_ALL: que moedas recebidas anteriormente são gastas e que novos montantes com condições de gasto são criados. Alterar dados abrangidos invalida a assinatura. Isto não significa assinar cada byte, por exemplo as outras assinaturas. Outros modos permitidos têm um alcance diferente. A assinatura ocupa 64 bytes; num modo não predefinido acrescenta-se um byte de tipo, ficando esse elemento com 65 bytes. Continua a não ser o tamanho da entrada ou da transação inteira. [2]

Ao assinar, é criado um valor secreto chamado nonce. Reutilizá-lo para mensagens diferentes com a mesma chave pode revelar a chave privada. Por isso, o BIP340 especifica a sua derivação e recomenda dados aleatórios auxiliares como proteção adicional da implementação. O utilizador não inventa o nonce nem o escreve na cópia de segurança. Uma biblioteca de assinaturas bem verificada gere-o; improvisar aqui pode comprometer uma criptografia de resto correta. [1] [9]

A estrutura matemática das assinaturas Schnorr permite protocolos nos quais várias pessoas concordam com uma mensagem e produzem uma assinatura conjunta. Um exemplo é MuSig2, definido no BIP327. Na forma básica deste protocolo, todos os membros do grupo escolhido têm de contribuir. Exige coordenação, tratamento correto das chaves e um procedimento próprio e seguro para os nonce. Não basta somar assinaturas arbitrárias já concluídas. O suporte a Schnorr Signature, por si só, também não significa que uma carteira permita essa colaboração. [8]

Taproot oferece diferentes vias de gasto. Na key path, a rede verifica uma assinatura face à chave pública registada na saída. Essa chave pode representar uma pessoa ou um grupo que coopera. Na script path revela-se o script escolhido: um programa com condições que o pagamento deve cumprir. Tapscript é a versão dessa linguagem utilizada por Taproot. A sua instrução OP_CHECKSIGADD verifica uma assinatura e, em caso de sucesso, soma um a um contador. Repeti-la permite avaliar várias assinaturas separadas e verificar a quantidade exigida. Este Multisig por script é diferente de uma assinatura agregada. Para cada carteira, verifique quem precisa de colaborar, o que se torna público e que recuperação continua possível se uma chave for perdida. [7] [2]

Numa rede sem árbitro central, um nó não deve aceitar uma assinatura que outro rejeita por interpretar os bytes de forma diferente. O BIP340 define, por isso, as chaves válidas, as assinaturas e o procedimento de verificação em detalhe. Permite também batch verification: verificar várias assinaturas em conjunto para poupar cálculo. Isso não reescreve os seus registos na cadeia nem junta assinaturas de entradas diferentes de uma transação. [1]

Uma assinatura conjunta por key-path pode parecer a assinatura de uma única chave. Assim, a assinatura isolada pode não revelar quantas pessoas chegaram a acordo. No entanto, os montantes, as ligações entre entradas e saídas e o momento da transação continuam geralmente observáveis. Schnorr Signature não cifra o pagamento. A privacidade também depende da utilização de Taproot, do comportamento da carteira e das circunstâncias do pagamento. [2] [3]

Para o utilizador comum, importa uma carteira que mostre corretamente o destinatário, o montante e a taxa e permita uma recuperação fiável. O programador deve ainda verificar o suporte exato ao BIP340, os vetores de teste, o tratamento dos nonce e o comportamento em caso de falha. O nome do algoritmo não garante todo o produto. Uma boa biblioteca, como libsecp256k1, realiza o cálculo criptográfico; não decide se a pessoa deve realmente autorizar o pagamento apresentado. [4] [9] [6]

Para ter uma visão mais completa, leia este verbete junto com Taproot, MuSig2, Multisig, Bitcoin Script. Também há referências a este verbete em SHA-256, Opcode, MuSig2, Nostr.

DOC · 001BIP 340 — Schnorr SignaturesEspecificação DOC · 002BIP 341 — TaprootEspecificação DOC · 003Bitcoin Optech — Schnorr signaturesDocumentação DOC · 004Bitcoin Core — secp256k1 verificationDocumentação DOC · 005Bitcoin Core — Script interpreterDocumentação DOC · 006BIP 340 rendered specificationEspecificação DOC · 007BIP342 — Validation of Taproot ScriptsEspecificação DOC · 008BIP327 — MuSig2Especificação DOC · 009libsecp256k1 — Schnorr signature APIDocumentação DOC · 010Bitcoin Developer Guide — WalletsDocumentação DOC · 011Bitcoin Developer Guide — Block ChainDocumentação DOC · 012Bitcoin Developer Reference — TransactionsDocumentação
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento