Research at
Winnow.

Winnow already implements its wallet and Bitcoin transaction logic in Swift. At the revision we inspected, its curve operations use P256K, a Swift interface to C libsecp256k1. We want to investigate a small, independently reusable Swift library for that boundary.

The attraction is being able to follow the types and implementation all the way through: a key, a tweak, a signature, and the mathematics behind them. A focused library could make integration and maintenance easier to understand. Build time, binary size, and performance are questions to measure.

This comes with a substantial cost. libsecp256k1 is an established implementation with extensive testing and deliberate treatment of secret operations. Replacing it transfers that responsibility to us. Swift does not, by itself, establish correct arithmetic, safe nonce handling, or constant-time execution.

What is the minimum?

Schnorr still needs secp256k1. Schnorr is the signature scheme; secp256k1 is the curve used by Bitcoin's BIP340. Winnow also needs key parsing and public-key derivation, BIP32 and Taproot tweaks, and the point and scalar operations used by its existing MuSig2 shared-signing code.

The proposed library owns those operations. Transaction formats, wallet policy, networking, backups, and the interface remain in Winnow. The initial production scope does not call for ECDSA, key recovery, or a general-purpose big-integer API.

Use Apple where it fits. Keep the library independent.

CryptoKit supplies hashes and HMAC; Security supplies secure randomness. Apple's public P-256 APIs use a different curve from Bitcoin's secp256k1. They do not provide a drop-in BIP340 signer. Native Swift here means owning the Bitcoin curve implementation in Swift, while using supported platform services.

We want the package to build and test without Winnow, and to be useful beyond this app. A possible contribution to Apple's Swift Crypto project is one direction to explore. Its current contribution rules require maintainer agreement and a usable BoringSSL implementation for new APIs. A native Swift backend therefore needs an explicit upstream decision. Apple acceptance and future CryptoKit availability are open questions.

A backup can outlive the software that created it. Recovery means understanding its format, finding the right keys and outputs, and showing the owner exactly where the money will go. That work deserves a focused tool with explicit limits for every supported format.

Winnow Rescue is being developed separately, with an embeddable Rust core, a command-line interface, and a desktop graphical interface. Its intended destination is an existing Taproot account. Keeping recovery in its own tool lets it address older wallet formats without adding those formats to the everyday phone wallet.

BIP360 proposes P2MR: script-tree spending without Taproot's key-path spend. We want to understand the consequences for wallet policy, backups, interoperability, and an eventual opt-in migration.

Removing the exposed output key addresses one part of the long-term public-key exposure problem. It does not replace the signatures inside the scripts with post-quantum signatures. That distinction matters when explaining what the proposal could protect.

A separate signer can give a wallet a different boundary for key custody. That only helps if the phone and device agree on the account, receiving addresses, spending policy, and transaction being approved. We are researching compatibility with existing hardware wallets.

The full flow matters: what the device can display and verify, how signing messages travel, how shared-signing nonces are used once, and what happens when approval fails. Recovery must cover a lost phone, a replaced signer, and the backups needed to reconstruct the same policy.

BIP352 Silent Payments lets a recipient publish reusable payment information while senders derive separate on-chain output keys. The motivation is to make repeated receiving more practical without putting the same receiving address into every payment.

The tradeoff is discovery. A recipient needs to identify payments intended for them using transaction input information and their scanning key. For Winnow, the research question includes how that work fits its direct-to-peer design, the cost of restoring a wallet, and what the phone must download and compute. Ordinary compact filters alone do not provide everything needed for discovery.

Silent Payments also needs secret scalar multiplication with public points for a shared-secret calculation (ECDH). That would expand the native Swift library beyond the minimum required by current Winnow. We will evaluate that addition explicitly.