First-pass research results
Experiments recorded on . Results reviewed for publication on .
These are bounded experiments with public vectors and synthetic wallets. The counts below come from the recorded first-pass runs; they are not a fresh run of every experiment or measurements of test coverage. The Research page tracks subsequent branches separately, including the native Swift wallet, script-path multisig and the draft Ledger integration.
Protocol and recovery checks used Winnow revision 6566871 and BIPs revision 927b6de. Hardware tests used the older coordinator identified below. Machine-readable record and artifact hashes.
Recovery: restored keys are only one requirement
The source review separated signing authority, coin discovery, account policy and safe signing state. Winnow's import path uses saved records and scans forward from a saved height. Its historical range scanner is implemented library code, but the inspected app import path does not connect it into a complete words-only restore.
- 23 import tests and 23 range-scan tests passed. These exercise library behavior with synthetic chains and loopback peers; they do not demonstrate a phone, Keychain or live iCloud recovery.
- 18 synthetic model tests passed. A stale restore and an independent clone both reused a signing slot after an earlier signature record was exported but never appeared on-chain.
- The coordinated model avoided reuse by assuming one shared authority, atomic reservation before export, and refusal when the authority was unavailable. It burned a reserved slot after an injected interruption.
The model does not implement XMSS or LMS, produce cryptographic signatures, persist state across a real power failure, or prevent rollback of its authority. It demonstrates why those guarantees are needed. SP 800-208 describes the state requirement and its own hardware conformance profile; it is not a Bitcoin wallet backup format. SPHINCS+-based SLH-DSA avoids the evolving used-key index, while ordinary key, policy and discovery backups remain necessary.
Rescue was inspected at 79ffa4d. Its core, network adapter, CLI and GUI were scaffolds. No working recovery/sweep or Rust test run was established in this pass. The next step is one precisely defined backup format taken through discovery, review and a test-coin sweep, with privacy disclosures recorded.
P2MR: construction is not script enforcement
BIP360 v0.12.1 was a draft at the pinned revision. Its reference runner reported nine vectors: seven constructed outputs and two checks of expected-error metadata. The additional local harness passed 83 checks of construction, address boundaries and a partial rule model. It did not execute a script interpreter.
The draft's depth-zero rule matters: once the script commitment matches, that case succeeds without executing the script. A single-leaf CHECKSIG example therefore does not demonstrate that a signature is required. A future spend test needs a deliberately chosen policy and an implementation enforcing the full pinned rules.
A separate executable importing unchanged WalletCore matched the seven constructions and checked the address-based funding boundary. Its full 127-check run covered P2MR and Silent Payments, with 21 selected existing wallet tests also passing. P2MR destinations were refused. The low-level initializer accepting a raw output script remains generic; these results describe the address/payment gate.
The next milestone is a two-leaf policy restored from a versioned backup, with both accepted and corrupted witnesses tested against a complete draft-rule implementation. Ordinary regtest acceptance, a correct address, and a matching Merkle root are not evidence of Bitcoin activation or post-quantum signing.
Silent Payments: discovery needs complete information
The unchanged BIP352 reference runner passed 28 sending and 29 receiving cases across 28 scenarios. Sixteen additional discovery/recovery checks passed. Reusing the reference implementation establishes agreement with those fixtures, not independent wallet interoperability.
- The scan secret and spend public key found a payment. Wrong keys, input aggregation or input-hash data prevented discovery.
- A missing label numbered 1,001,337 hid a published payment; restoring it recovered the payment. Omitting change label 0 also lost a receipt.
- A correctly computed public tweak point could stand in for full input data. A different valid point hid the payment, illustrating the need to check helper correctness and completeness.
- Removing an earlier matching output hid a later output in the same fixture. Retaining only unspent outputs from a transaction is not automatically sufficient for discovery.
Ordinary compact filters do not supply all the transaction input and spent-output information needed for this calculation. A restore must specify its scan and spend keys, derivation conventions, labels and chain starting point. A server given scanning keys can identify receipts; a generic data feed avoids that disclosure but introduces completeness and request-metadata questions.
Silent Payments needs secret scalar multiplication by an arbitrary validated public point and the specified compressed shared-point encoding. The native Swift library's public-data operations do not, by themselves, establish a suitable secret ECDH implementation. Also, v0 eligibility rules exclude transactions spending witness versions above 1, including proposed P2MR inputs.
No seed-derived end-to-end wallet restore, transaction broadcast, iPhone throughput, bandwidth or battery measurement was performed. The next step is an independent test-coin send, discovery, spend and seed-plus-label restore with interruption and reorganization checks.
Hardware: historical simulation and current devices are separate
The reproduction used Winnow coordinator 3200521, Satochip applet v0.15-0.1, pysatochip v0.18.5, a corrected jCardSim 3.0.5.11 simulator, and Bitcoin Core 31.1 on local regtest.
Four variants passed signature checks and Core's mempool-acceptance check: baseline, restored phone, replacement simulated card from the same seed, and both restored. These used saved account and coin records. The candidate spends were not broadcast or confirmed, and no fresh coin-discovery scan was tested.
The stock historical applet failed at nonce counter 32,769. A temporary counter patch passed that boundary and wraparound checks. State was injected near the boundary; the test did not perform 32,769 physical-card operations. Both runs required the simulator correction. The stock run correctly reported a finding rather than overall success.
The later v0.16-0.1 source already contains an equivalent counter fix and other protocol changes. It was inspected but not executed in this pass. Neither that version nor a retail card inherits the old simulator result.
No physical hardware, iPhone Bluetooth or NFC flow was tested. A coordinator rejecting a changed signing message is also not evidence that a device displays or understands the recipient. The current hardware research section records the subsequent Ledger branch and its separate remaining device tests.