A libsecp256k1 implementa uma única curva, e com cuidado: assinatura em tempo constante, testes exaustivos e verificação formal de partes da aritmética do corpo. Ela é usada pelo Bitcoin Core, por muitas carteiras e por bindings como o coincurve e o backend cgo do go-ethereum. Os fatos desta página foram verificados no pacote do Alpine 3.24.2, versão 0.5.0 com os módulos recovery, extrakeys e schnorrsig; na época, o projeto original já estava na 0.8.0.
As assinaturas ficam em uma struct opaca; a codificação é escolhida na serialização — serialize_compact gera 64 bytes de r‖s, serialize_der gera DER —, e a análise é igualmente explícita. parse_der é estrito: aceitou DER mínimo e recusou a mesma assinatura com um zero à esquerda redundante em r, seguindo as regras do BIP-66 do Bitcoin. Assinaturas históricas fora desse rigor precisam do parser permissivo mantido no diretório contrib do repositório.
Para assinar, a biblioteca recebe um hash de 32 bytes — ela nunca calcula o hash da sua mensagem —, usa a RFC 6979 (o resultado do teste coincidiu com o de uma implementação independente) e sempre produz low-S. A verificação é a parte estrita: a forma high-S espelhada de uma assinatura válida falhou, e secp256k1_ecdsa_signature_normalize existe justamente para corrigir assinaturas de signatários de uso geral. Quando uma assinatura vinda do OpenSSL, do Java ou de um KMS de nuvem passa na verificação em cerca de metade dos casos, a causa é high-S; o exemplo normaliza antes de verificar.
As chaves públicas são pontos SEC1, com 65 bytes na forma não comprimida ou 33 na forma comprimida; um x‖y de 64 bytes é recusado, e não há suporte a SPKI, PEM nem JWK. O módulo recovery recupera a chave pública a partir de uma assinatura — a base dos endereços Ethereum —, e o módulo schnorrsig implementa o BIP-340. Confira assinaturas de mensagens Bitcoin no verificador de mensagens Bitcoin e eventos Nostr no verificador de eventos Nostr.