Conversation
Contributor
|
Should we drop the regenerated Swift bindings from this PR? They expect the new FFI symbols but Package.swift still points at the released v0.2.2 xcframework so root swift build breaks. (The release flow can regenerate bindings with the matching framework) |
Contributor
Author
Done, I’ve removed the Swift bindings from this PR |
Member
|
I did a quick review and can give this a concept ACK but need to try testing locally and give it a deeper look. |
notmandatory
approved these changes
Sep 16, 2026
Adds a public `sign_digest` wrapper on `TapSigner` and an FFI entry
point so Swift/Kotlin consumers can sign arbitrary digests (BIP-137
"Bitcoin Signed Message", proof-of-key challenges, generic
attestations) without going through `sign_psbt`.
The FFI returns `SignedDigest { signature, pubkey, rec_id }` — the
recovery id is computed at the boundary so callers can verify locally
or build a BIP-137 header byte without an extra round-trip.
Closes bitcoindevkit#70
Picks up `signDigest(digest:subPath:cvc:)`, `SignedDigest`, and `SignDigestError` from the FFI surface added in the previous commit. Also splits the bindings into `CKTap.swift` + `CKTapFFI.h` + `CKTapFFI.modulemap` (replacing the single `cktap_ffi.swift`).
uniffi-bindgen now derives Swift binding filenames from the UDL namespace (`CKTap`) instead of the cargo lib name (`cktap_ffi`), so the script was looking for `cktap_ffiFFI.h`/`.modulemap` and silently falling through — producing an xcframework whose modulemap pointed at a header that was never copied in. `swift build` then failed with hundreds of unresolved C symbols. Also place the header and modulemap directly at the top of the headers dir (not in a `<basename>/` subdir): the xcframework Info.plist exposes `HeadersPath = "Headers"`, and clang only auto-discovers `Headers/module.modulemap`. Remove the stray `CKTapFFI.h`/`CKTapFFI.modulemap` that were accidentally committed under `Sources/CKTap/` — they belong in `target/include/` and are now moved there by the script.
Add unit tests for the recovery-id derivation used by `sign_digest`, exercising the realistic branches without requiring a card: - `derive_recovery_id_matches_signer_rec_id` — round-trips a fixed secret/digest pair and asserts the derived id matches what the recoverable signer returned. - `derive_recovery_id_covers_both_compressed_ids` — sweeps seeds until both rec_id 0 and rec_id 1 are observed (the only ids reachable with compressed-pubkey ECDSA). - `derive_recovery_id_errors_when_pubkey_does_not_match` — passes a pubkey from a different key and asserts `SignDigestError::RecoveryId`.
…ework The regenerated CKTap.swift referenced sign_digest FFI symbols absent from the released v0.2.2 xcframework that root Package.swift points at, breaking root swift build. Bindings will be regenerated by the release flow against the matching framework.
r1b2ns
force-pushed
the
feat/public-sign
branch
from
September 17, 2026 00:14
b84ba25 to
d583436
Compare
Contributor
Author
tks @notmandatory, ok I keep watching #74 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
sign_digestonTapSignerand through the UniFFI surface so Swift/Kotlin consumers can sign arbitrary 32-byte digests (BIP-137 "Bitcoin Signed Message", proof-of-key challenges, generic attestations) without going throughsign_psbt.SignedDigest { signature, pubkey, rec_id }— the recovery id is computed at the FFI boundary so callers can verify locally or build a BIP-137 header byte without an extra round-trip.Closes #70.
Changes
lib/src/tap_signer.rs— publicsign_digest(digest, sub_path, cvc)wrapper around the existing crate-privateTapSignerShared::sign.lib/src/lib.rs— re-exportbitcoinso downstream FFI code can userust_cktap::bitcoin::secp256k1.cktap-ffi/src/tap_signer.rs— UniFFI entry point +SignedDigestrecord + brute-force recovery-id derivation against the returned compressed pubkey.cktap-ffi/src/error.rs— newSignDigestErrorwithCkTap,InvalidDigestLength { len: u32 }, andRecoveryId { msg }variants.Test plan
cargo build --all-features --all-targets(workspace)cargo test—cktap-ffirecovery-id coverage (derive_recovery_id_matches_signer_rec_id,derive_recovery_id_errors_when_pubkey_does_not_match,derive_recovery_id_covers_both_compressed_ids) passescargo test -p rust-cktap --features emulator -- --nocaptureagainst the coinkite emulatorsignDigest(digest:subPath:cvc:)and verify the returned signature against the returned pubkey using therec_id