Framework
P256K
P256K is a Swift package wrapping bitcoin-core’s libsecp256k1 in a type-safe API — ECDSA, Schnorr (BIP-340), MuSig2 (BIP-327), ECDH key agreement, and key recovery — for Bitcoin, Lightning, Nostr, and other open protocols built on the secp256k1 elliptic curve.
Overview
The P256K module wraps the libsecp256k1 C codebase with a type-safe Swift API designed to match the style of Apple’s swift-crypto framework. It surfaces cryptographic primitives for the underlying Bitcoin, Lightning Network, Nostr, and other open-protocol stacks.
All operations require a secp256k1 context. The package supplies a shared P256K.Context that is created and randomized once at process startup, protecting ECDSA signatures, Schnorr signatures, and public-key generation against timing and power-analysis attacks via base-point blinding.
Where to start
Arrived from CryptoKit and wondering why P256 doesn’t work for Bitcoin or Nostr? Why CryptoKit’s P256 Can’t Sign Bitcoin or Nostr answers that question and maps each CryptoKit call to its P256K equivalent. New to P256K? Begin with Getting Started with secp256k1 in Swift for a task-oriented walkthrough of ECDSA, BIP-340 Schnorr, and ECDH key agreement. Producing ECDSA signatures for Bitcoin transactions — DER encoding, lower-S, and the SIGHASH-flagged signature element — lives in ECDSA Signing on secp256k1 for Bitcoin Transactions in Swift. Aggregating contributions from multiple parties into a single Schnorr signature? Read MuSig2 Multi-Signatures for the BIP-327 protocol. The Elliptic Curve Diffie-Hellman guide covers ECDH end-to-end — the building block behind Nostr NIP-04, Lightning’s Noise XK handshake, and BIP-352 Silent Payments. Sending Bitcoin to a reusable receiver address without on-chain linkability lives in Silent Payments. Encoding keys across formats and deriving child keys via BIP-32, Taproot, or MuSig2 tweaks both live in Working with Keys. Recovering public keys from signatures (BIP-137 / BIP-322) lives in Recovering Public Keys. Production-readiness caveats — context randomization, nonce hygiene, comparison timing, secret zeroization, signature malleability — are in Security Considerations.
Topics
Guides
Getting Started with secp256k1 in Swift
Install P256K via Swift Package Manager, trust the SharedSourcesPlugin, and produce your first verified secp256k1 signature — the entry point for Swift developers building Bitcoin, Nostr, or Lightning Network functionality.
ECDSA Signing on secp256k1 for Bitcoin Transactions in Swift
Produce ECDSA signatures on secp256k1 in Swift with P256K, encode them in DER and compact form, verify incoming signatures, and assemble the SIGHASH-flagged element Bitcoin script expects.
Elliptic Curve Diffie-Hellman
Derive a shared secret between two parties over secp256k1 using ECDH key agreement, the foundation of Nostr NIP-04 encryption, BIP-352 Silent Payments, and Lightning’s Noise XK handshake.
Silent Payments
Send Bitcoin to a reusable static address without on-chain linkability or sender–receiver interaction, using the BIP-352 Silent Payments protocol.
MuSig2 Multi-Signatures
Combine partial contributions from a fixed group of co-signers into a single Schnorr signature using the BIP-327 MuSig2 protocol.
Working with Keys
Encode P256K secp256k1 keys in raw and x-only forms, import them from PEM and DER, and derive child keys via additive or multiplicative tweaks — the foundations under Bitcoin wallet storage, Lightning interop, Nostr key handling, BIP-32 derivation, BIP-341 Taproot output construction, and BIP-327 MuSig2 aggregation.
Recovering Public Keys
Recover an ECDSA public key from a recoverable signature and its recovery ID.
Concepts
Essentials
ECDSA Signatures
Schnorr Signatures
MuSig2 Multi-Signatures
Key Agreement (ECDH)
Key Recovery
Hashing
Supporting Types
Protocols
Structures
Type Aliases
Enumerations
Extended Modules