Port Android's OkHttpFactory pattern to desktop — creates a custom
Fetcher.Factory<Uri> that calls DesktopHttpClient.currentClient() per
image request, routing all image loads through the SOCKS proxy when
Tor is active.
Avoids the OkHttpNetworkFetcher.factory() import issue by directly
constructing NetworkFetcher with the Tor-aware Call.Factory, matching
the proven Android implementation.
This closes the last network leak — ALL egress paths now route through
Tor when enabled.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
SECURITY: With Tor ON, all HTTP traffic now routes through SOCKS proxy.
Previously only relay WebSocket connections used Tor; 8 other egress
paths created bare OkHttpClient() instances bypassing Tor entirely.
Fail-closed behavior:
- When Tor expected but bootstrapping → dead SOCKS proxy on port 1
(requests fail instead of leaking IP)
- lateinit var crashes on misconfiguration (loud failure vs silent leak)
Leak sites fixed (all use DesktopHttpClient.currentClient()):
- AnimatedGifImage: GIF fetch
- SaveMediaAction: media downloads
- EncryptedMediaService: NIP-17 DM media
- ServerHealthCheck: Blossom server probes
- NoteActions: zap/lightning LNURL resolution
- DesktopBlossomClient: media uploads
- AccountManager: NIP-46 bunker relay connections
- Coil image loader: TODO (OkHttpNetworkFetcher import issue)
Also:
- Relay reconnect on Tor Active (prevents stale clearnet connections)
- isTorExpected() for fail-closed logic
- Tests updated for new torTypeProvider parameter
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Shield was getting pushed off screen when RelayHealthIndicator ("x s ago")
appeared above it. Moved to very last position (after BunkerHeartbeat)
so it's always visible at the bottom edge.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Shield icon was only in DeckSidebar (deck mode) but missing from
SinglePaneLayout's NavigationRail. Added between RelayHealthIndicator
and BunkerHeartbeatIndicator. Clicking navigates to Settings.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
UX improvements based on manual testing feedback:
- Default TorType changed from OFF to INTERNAL (Tor on by default)
- Default preset changed to Full Privacy (all routing via Tor)
- Shield icon always visible in sidebar (not hidden when Off)
- Shield icon clickable — opens Settings
- TorSettingsDialog Cancel/Save buttons sticky at bottom (don't scroll away)
- HorizontalDivider above buttons for visual separation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 6: Polish and wiring.
Per-relay routing:
- TorRelayEvaluation wired into DesktopHttpClient with actual settings
- shouldUseTorForRelay uses real evaluation instead of { false }
- Settings changes propagate to torTypeFlow/externalPortFlow reactively
CompositionLocal for Tor state:
- LocalTorState provides TorState (status, settings, onSettingsChanged)
- Avoids threading Tor params through every composable layer
- DeckColumnContainer reads from LocalTorState for RelaySettingsScreen
.onion relay badge:
- RelayStatusCard shows "Requires Tor" (red) when Tor is off
- Shows "via Tor" (green) when Tor is active
- Only on .onion relay URLs
Shutdown hook:
- activeTorManager.stopSync() in existing shutdown hook
- Ensures no orphaned Tor processes on app exit
- Set via volatile var from App composable
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 5: Desktop settings UI for Tor.
TorStatusIndicator:
- Shield icon in sidebar footer (gray/yellow/green/red)
- Tooltip shows status (no port number for security)
- Only visible when Tor is not Off
TorSettingsSection:
- Inline in settings screen between Media Server and Dev Settings
- Mode selector (Off/Internal/External) with segmented buttons
- External SOCKS port input with validation (1-65535)
- "Advanced..." button opens full dialog
TorSettingsDialog:
- Full DialogWindow with preset selector (radio buttons)
- 4 relay routing toggles + 7 content routing toggles
- Preset auto-detection (whichPreset)
- Save/Cancel with DesktopTorPreferences persistence
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mirror TorSettingsTest and TorRelayEvaluationTest in commons/commonTest
using kotlin.test for KMP compatibility. Tests verify the shared types
directly without going through Android typealiases.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New shared types in commons/commonMain/tor/:
- TorServiceStatus: clean sealed class with Off, Connecting, Active(port),
Error(message). Uses data object for stateless variants. No TorControlConnection
dependency (Android keeps its own version for now).
- ITorManager: reactive interface with status flow + dormant/active/newIdentity
- ITorSettingsPersistence: load/save interface for platform persistence
Android TorServiceStatus unchanged — will migrate to commons version when
RelayProxyClientConnector is refactored to use ITorManager signals.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move relay routing logic to shared commons module:
- TorRelaySettings data class
- TorRelayEvaluation with useTor() routing logic
Android files replaced with typealiases for backward compatibility.
All tests pass.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move core Tor data models and preset logic to shared commons module:
- TorSettings data class, TorType enum, TorPresetType enum
- parseTorType, parseTorPresetType, isPreset, whichPreset functions
- All preset constants (torOnlyWhenNeededPreset, etc.)
R.string resource IDs removed from enums in commons. Android retains
resourceId/explainerId as extension properties in ui.tor package.
15 Android files updated to import from commons.tor. All 69 tests pass.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Correctness (C):
- scalar_mul: rewrite with a loop-driven fold so the 512-bit product is
fully reduced regardless of the pre-existing third-fold carry-drop bug;
also fixes the portable (!HAVE_INT128) fallback which was returning
(a*b) mod 2^256 instead of (a*b) mod n.
- fe_mul / reduce_wide: loop the final carry fold in a while(carry) rather
than a single if(carry), so a secondary carry-out is never silently
dropped for adversarial or deeply lazy-reduced inputs.
- scalar_add: reuse the precomputed SCALAR_NC constant instead of
recomputing n's two's-complement arithmetically each call.
- fe_negate: remove the data-dependent early-return for a == 0; compute
P - a unconditionally and fold P back to 0 with a final fe_normalize,
matching the Kotlin FieldP.neg path and dropping a branch.
Performance (C):
- Add a dedicated 10-mul fe_sqr_inline using __int128 (4 diagonal + 6
doubled cross products, three-pass structure mirroring Kotlin
U256.sqrWide). The previous fe_sqr delegated to fe_mul(a, a) using all
16 schoolbook products; the new path saves ~37% of the multiplications
at every squaring, and doublePoint/addPoints do ~9 sqrs each in the hot
Jacobian loop. Col-3 mixes two products so the accumulator is split
explicitly to avoid a uint128 overflow; the bug was caught by the C
benchmark's self-test.
- Enable LTO (CMAKE_INTERPROCEDURAL_OPTIMIZATION) when the toolchain
supports it, recovering cross-TU inlining of fe_mul/fe_sqr into point.c
and schnorr.c.
- jni_bridge: replace the pinning GetByteArrayElements path (which blocks
GC compaction) with a stack-or-heap copy_msg_bytes helper that uses
GetByteArrayRegion. Short messages (32 B event digests, the common case
for Nostr) hit a 512 B on-stack buffer.
Correctness (Kotlin):
- FieldP.neg: remove the early-return on zero for the same reasons as the
C side, with a trailing reduceSelf(out) to collapse the P result back
to 0 when the input was zero.
- Secp256k1.signSchnorrInternal / privKeyTweakAdd: switch the crypto-
edge-case failure modes from generic require() to check() with clear
messages, documenting them as invariants rather than argument errors
and matching the C side's return-code semantics.
Tests & benchmarks:
- Add Secp256k1CrossValidationTest (jvmTest) that byte-for-byte compares
Kotlin, ACINQ, and the custom C implementation across pubkey creation,
Schnorr signing (incl. variable message lengths on the Kotlin side),
privKeyTweakAdd, and x-only ECDH. This is the strongest parity check we
can run without a third reference, and it's deterministic for
reproducibility (fixed LCG seed).
- Add adversarial FieldPTest cases that chain lazy adds into mul/sqr/inv
to exercise the new fe_mul fold loop and the dedicated fe_sqr path.
- Fix pre-existing FieldPTest/GlvTest failures (addNearP, addNegIsZero,
halfOfOdd, invMulIsOne, invOfTwo, reduceWideWithMaxValues, betaCubedIsOne)
that were asserting on raw limbs of lazy-reduced values; they now
reduceSelf before comparing, consistent with the rest of the suite.
- Secp256k1Benchmark: document the intentional apples-to-apples
asymmetries (signSchnorrWithPubKey vs signSchnorr, ecdhXOnly vs
pubKeyTweakMul, privKeyTweakAdd's copyOf() penalty) and add a
taggedHash benchmark since NIP-44 leans heavily on it.
All 188 secp256k1 Kotlin tests pass; the C library builds cleanly with
LTO enabled and the secp256k1_bench self-verification succeeds.
https://claude.ai/code/session_01KExJURZATpL59ZKXP6AVP6
Move fe_mul/fe_sqr to static inline in field.h when ASM is available
(FE_MUL_ASM=1). This allows the compiler to inline the entire field
multiply directly into gej_double and gej_add_ge, eliminating function
call boundaries.
Before: gej_double had 9 function calls (to fe_mul/fe_sqr)
After: gej_double has 2 function calls (fe_half only)
The compiler can now:
- Keep intermediate results in registers across multiply boundaries
- Schedule MULX instructions across adjacent field operations
- Eliminate push/pop register saves at call boundaries
gej_double: 738 → 1311 instructions (larger but no call overhead)
Impact:
verifyFast: 35.1µs → 31.6µs (10% faster, 1.19x vs ACINQ)
verify: 39.7µs → 38.4µs (0.98x vs ACINQ — essentially tied!)
sign: 15.2µs → 14.2µs (1.48x vs ACINQ)
batch(200): 6.2µs → 4.5µs per event (7.9x vs ACINQ)
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Remove fe_normalize/reduceSelf from the end of field multiply and
square. After reduceWide, the output is in [0, 2^256) which may
include values in [P, P+C) where C = 2^32+977. This is the same
"unreduced" range that lazy fe_add produces, and is safe because:
- mul/sqr: mulWide handles any 256-bit input via reduceWide ✓
- add: carry fold handles overflow past 2^256 ✓
- sub: P-add-back on underflow produces correct field element ✓
- neg/half: already normalize input via reduceSelf ✓
- isZero/cmp/toBytes: caller normalizes before use ✓
Native C-to-C results (x86_64, vs ACINQ):
verifyFast: 0.95x → 0.99x (essentially tied with ACINQ!)
sign (cached): 1.18x → 1.24x faster
ECDH: 1.05x → 1.06x faster
batch(200)/event: 7.2µs → 6.4µs
Kotlin JVM results (vs previous lazy-add-only):
Kotlin numbers stable — reduceSelf in reduceWide was already
cheap on JVM since the branch is almost never taken.
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Analyzed lazy fe_sub: on underflow, the unsigned-wrapped value
(a - b + 2^256) differs from (a - b + P) by C = 2^32 + 977.
When multiplied: (a-b+2^256)*x ≠ (a-b)*x mod p (off by x*C mod p).
The P-add-back on underflow is mandatory for correctness.
This is a fundamental difference from 5x52 lazy reduction where
magnitude tracking keeps values representable. With 4x64 fully-packed
limbs, sub MUST add P back, but add CAN skip reduceSelf since values
in [P, 2^256) differ from [0, C) which is handled by mulWide+reduceWide.
Also evaluated:
- WINDOW_G 12→14: only 1.2µs savings for 4x memory (128→512KB).
Not worth it on phones where L1 cache is 128-256KB.
- fe_sqrt optimization: only 831ns overhead over theoretical minimum
of 5.85µs. The addition chain is already near-optimal.
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Remove reduceSelf from FieldP.add, making it lazy (same approach as
the C implementation). Values may be in [0, 2^256) between additions.
Safety analysis:
- mul/sqr: reduceWide handles any 256-bit input ✓
- neg: added reduceSelf before P - a (prevents underflow) ✓
- half: added reduceSelf before conditional add P ✓
- sub: already adds P back on borrow (self-normalizing) ✓
- isZero/cmp: called on sub outputs (normalized) or after mul ✓
- verifySchnorrCore: added reduceSelf before Jacobian x-check ✓
- toBytes: only called on toAffine outputs (from mul, normalized) ✓
JVM benchmark results (ops/sec, HotSpot C2):
pubkeyCreate: 32,096 → 37,211 (+15.9%)
signXOnly: 31,149 → 34,507 (+10.8%)
sign: 16,137 → 17,822 (+10.4%)
verify: 12,733 → 14,027 (+10.2%)
verifyFast: 14,734 → 15,449 (+4.9%)
ECDH: 10,975 → 12,102 (+10.3%)
batch(200): 91,611 → 102,354 (+11.7%)
The improvement is larger than expected (10-16% vs estimated 6%)
because HotSpot's branch prediction overhead for reduceSelf
(virtual dispatch + 4 Long comparisons) is higher than the
~2.5ns estimated for native code.
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
LightCompressor-enhanced 1.9.0 bundles the GIF-to-MP4 converter originally
contributed upstream from amethyst. Drop the duplicated copies and delegate
to the library, adapting GifToMp4Result -> MediaCompressorResult.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Three SHA-256 implementations benchmarked on the same phone:
- sha256Android: Android's MessageDigest (BoringSSL + ARM64 CE hardware)
- sha256OurC: Our C SHA-256 (ARM64 CE hardware via JNI)
- sha256Kotlin: Kotlin's sha256 (platform MessageDigest on Android)
Also add nativeSha256 JNI method to expose our hardware SHA-256.
Why our C matches ACINQ on ARM64 despite different architectures:
- Our 4x64: 16 MUL+UMULH pairs per field mul
- ACINQ 5x52: 25 MUL+UMULH pairs per field mul
- We save 9 multiply pairs (~27ns on Cortex-X3) per fe_mul
- ACINQ saves ~6 normalizations with lazy reduction (~6ns)
- Net advantage: ~21ns per mul × 500 muls/verify > 0
- Plus our SHA-256 uses hardware CE, ACINQ's is software
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Add build_android.sh that cross-compiles the C secp256k1 library for
ARM64 using the Android NDK and places the .so in benchmark/src/main/
jniLibs/ where the benchmark APK will package it.
Usage:
cd quartz/src/main/c/secp256k1
./build_android.sh
cd ../../../../..
./gradlew :benchmark:connectedAndroidTest
Also:
- Fix Secp256k1InstanceC.android.kt to use Secp256k1C JNI binding
class (same pattern as JVM) so the JNI method names match
Java_com_vitorpamplona_quartz_utils_Secp256k1C_native*
- Add benchmark/src/main/jniLibs/ to .gitignore
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Two major optimizations targeting ARM64 mobile phones:
1. LAZY FIELD ADDITION (both platforms):
fe_add no longer calls fe_normalize. Values may be in [0, 2^256)
between operations. This is safe because:
- fe_mul/fe_sqr reduction handles any 256-bit input
- fe_negate normalizes its input before P - a
- fe_is_zero/fe_equal/fe_to_bytes normalize their copies
Saves ~6 normalize calls per gej_double (called 130x per verify).
Impact: gej_add_ge 372→316ns (15%), gej_double 224→206ns (8%).
2. FULL ARM64 ASM fe_mul (ARM64 only):
Complete 4x4 multiply + reduction in inline assembly using:
- LDP/STP for load/store pairs (halves memory instructions)
- MUL+UMULH with interleaved scheduling across columns
(hides 3-cycle multiply latency behind independent additions)
- Full reduction in ASM with MUL+UMULH+ADDS carry chain
- 20 registers used (ARM64 has 31 — zero stack spills)
- Row 1 and 3 interleave b0+b2 products with b1+b3 for ILP
Expected ARM64 improvement: fe_mul ~20-25ns → ~13-15ns
x86_64 benchmark (measured on this machine):
gej_add_ge: 372→316ns (15% faster)
ECDH: 35.4→32.6µs (8% faster, now tied with ACINQ)
batch(200): 1596→1437µs (10% faster, 7.2µs/event)
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
The Arti data directory (<filesDir>/arti/) accumulates stale consensus
and relay descriptors over time. When this cached data becomes invalid,
TorClient::create_bootstrapped() either bootstraps with stale guards
(leading to circuit failures) or fails outright. Since the native
TorClient persists for the process lifetime, force-closing and reopening
the app re-reads the same corrupted data. Only clearing all app data
(which deletes the arti/ dir) would recover — matching the user report.
- Clear arti/cache/ on each fresh initialization (new process) so Arti
always downloads fresh consensus and relay descriptors
- On initialize() failure, clear ALL arti data (state + cache) and
retry once, recovering from corrupted state without requiring the
user to manually clear app data
https://claude.ai/code/session_01VFAypytKGzdmuoJAXrb72G
Direct comparison with no JNI/JVM overhead, both libraries called
from the same C program on the same machine (x86_64, BMI2).
Results (x86_64, same machine, cached pubkey pattern):
Operation ACINQ Ours Speedup
pubkeyCreate 21.2µs 20.3µs 1.04x
signSchnorr 23.5µs 39.3µs 0.60x (*)
verify (BIP-340) 42.8µs 46.8µs 0.91x
verifyFast (Nostr) 42.8µs 39.1µs 1.10x
ECDH (cached) 44.4µs 39.7µs 1.12x
batch(200) 47.2µs 10.1µs 4.7x per event
(*) sign is slower because ACINQ's keypair API pre-stores the pubkey,
avoiding ecmult_gen during sign. Our API derives pubkey each time.
A keypair-style API would match ACINQ's sign performance.
Cross-verification confirms both produce compatible signatures.
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
The ECDH operation was 0.7x ACINQ (55µs vs 40µs) because:
1. P-table built from scratch every call: 9.8µs
2. liftX (sqrt) for pubkey decompression: 5.5µs
Both are redundant for the Nostr use case where the same peer key
is used repeatedly (NIP-44 encrypted DMs).
Fixes:
- Share the P-table cache (1024 entries) between ecmult and
ecmult_double_g. Same pubkey → cache hit → skip table build.
- Use lift_x_cached in ecdh_xonly. Same pubkey → skip sqrt.
ECDH: 55.2µs → 33.9µs (1.63x faster, now 1.18x faster than ACINQ)
Full benchmark (x86_64, cached pubkey pattern):
signXOnly: 17.6µs (56,818 ops/s) — 2.1x faster than ACINQ
verifyFast: 35.0µs (28,571 ops/s) — 1.2x faster than ACINQ
pubkeyCreate: 15.8µs (63,291 ops/s) — 1.2x faster than ACINQ
ecdhXOnly: 33.9µs (29,499 ops/s) — 1.2x faster than ACINQ
batch(200): 1596µs (125,313 ev/s) — 12x faster than ACINQ
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Optimize the ARM64 code path (the primary target for Nostr clients):
1. fe_mul_asm: Use LDP/STP (load/store pair) to load all 8 limbs in
4 instructions instead of 8 individual LDR. Row 0 in hand-tuned
ASM with MUL+UMULH+ADDS/ADC. Rows 1-3 in __int128 C (ARM64 gcc
generates optimal MUL+UMULH+ADDS/ADCS and MADD from this).
2. fe_normalize: Branchless on ARM64 using mask-based conditional
subtract (compiles to CSEL/AND on ARM64, avoiding branch
misprediction on mobile Cortex-A76+ SoCs). x86_64 keeps the
branching version since its branch predictor handles the >99.99%
non-taken case perfectly.
3. Document ARM64-specific instruction usage:
- MUL + UMULH: 64×64→128 product (1 cycle throughput on A76+)
- LDP/STP: load/store pair (2 regs per instruction)
- ADDS/ADCS: carry chain for accumulation
- MADD: fused multiply-add (generated by gcc from __int128)
These changes don't affect x86_64 correctness or performance
(verified: all keys pass, benchmark matches previous numbers).
The ARM64 improvements will be measurable when built with the
Android NDK for actual phone testing.
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Replace MULQ with MULX in the inline assembly for fe_mul on x86_64.
MULX advantages over MULQ:
- Uses RDX as implicit input (not RAX), outputs to two arbitrary regs
- Does NOT clobber flags, enabling better instruction scheduling
- Enables the compiler to interleave multiplies with carries
Requires BMI2 (available on Haswell+ / Zen+). Added -mbmi2 to
CMakeLists.txt for x86_64 builds.
Note: ADCX/ADOX (ADX extension) for dual carry chains was investigated
but the compiler doesn't auto-generate them from __int128 code, and
hand-encoding in inline ASM requires restructuring the entire multiply
to express two independent carry chains. The MULX-only approach still
gives a measurable improvement.
fe_mul: 17.2ns → 15.5ns (10% faster)
pubkeyCreate: 16.7µs → 15.5µs (7% faster)
verifyFast: 36.5µs → 36.1µs (1% faster, 27,700 ops/s)
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Fix garbled batch verify names in the C benchmark (static char buffer
was shared across calls). Use string literals per batch size instead.
Fix batch verify self-test: use sign() (safe path) instead of
sign_xonly() since the test key has odd-y pubkey.
Add batch sizes 4 and 64 to the benchmark for finer granularity.
Batch verification results (x86_64 standalone, same pubkey):
Batch µs/event events/sec vs individual
1 36.6 27,322 1.0x
4 15.2 66,007 2.4x
8 11.1 89,787 3.3x
16 9.2 109,290 4.0x
32 8.6 115,942 4.2x
64 8.3 120,960 4.4x
200 7.8 127,689 4.7x
vs Kotlin: C batch is 1.3-1.7x faster across all batch sizes.
At 200 events: 127K ev/s (C) vs 96K ev/s (Kotlin).
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Remove redundant fe_normalize calls from gej_add_ge (the verify hot
path, called ~60 times per verify). Since fe_add/fe_mul/fe_sqr all
normalize their output, the extra fe_normalize calls on h, rr, r->x,
r->y, r->z were no-ops.
Use __builtin_expect to hint the aliasing check (r == p) as unlikely
in the hot path, helping branch prediction.
Also remove redundant normalizations from gej_add for consistency.
Performance (x86_64 standalone, µs/op):
signXOnly: 19.2 µs (52K ops/s) — 1.9x faster than ACINQ
verifyFast: 37.2 µs (27K ops/s) — 1.05x faster than ACINQ
pubkeyCreate: 16.7 µs (60K ops/s) — matching ACINQ
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Three performance optimizations:
1. Inline fe_mul: merge mul_wide + reduce_wide into a single function
body to keep intermediates in registers and eliminate call overhead.
Saves ~1-2ns per fe_mul call (~200 calls per verify).
2. Restore fast signXOnly: assume even-y (BIP-340 convention) instead
of deriving y-parity via ecmult_gen each time. This is correct for
Nostr keys which are pre-processed to have even-y pubkeys.
signXOnly: 36µs → 19µs (1.9x faster).
3. Fix benchmark: use sign() (safe, derives y-parity) for self-test
since the test key has odd-y pubkey.
Performance (x86_64 standalone, µs/op):
signXOnly (cached pk): 19.0 µs (52,524 ops/s) — 1.9x faster than ACINQ
signSchnorr: 36.7 µs (27,282 ops/s) — matches ACINQ
verifyFast (cached pk): 37.0 µs (27,013 ops/s) — faster than ACINQ
pubkeyCreate: 16.6 µs (60,250 ops/s) — matches ACINQ
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Replace fe_half's normalize-then-branch approach with a branchless
mask-based conditional add of P. This eliminates the fe_normalize_full
call and branch prediction penalty.
Note: dedicated fe_sqr with cross-product doubling was attempted but
reverted — with 4x64 limbs, each 64x64 product is 128 bits and
doubling overflows uint128. The 5x52 representation wouldn't have this
issue (104-bit products, 105 bits doubled) but was rejected earlier for
having more total products (25 vs 16). This is a fundamental tradeoff.
Performance (x86_64 standalone, µs/op):
verifyFast: 51.5 µs (19,422 ops/s)
pubkeyCreate: 16.7 µs (59,925 ops/s)
signSchnorr: 35.5 µs (28,164 ops/s)
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
Fix batch_to_affine to handle infinity points by skipping them in the
cumulative Z product chain. The comb table has infinity entries at
index 0 of each block (representing "no teeth set"), and the old code
multiplied by Z=0 which corrupted all subsequent Z products.
Re-enable the comb method for ecmult_gen: only 3 doublings + ~43 table
lookups vs GLV+wNAF's ~130 doublings + ~32 additions.
Performance improvement (x86_64 standalone):
pubkeyCreate: 54.4 µs → 17.0 µs (3.2x faster)
signSchnorr: 109 µs → 36.2 µs (3.0x faster)
signXOnly: 109 µs → 35.9 µs (3.0x faster)
verify/ECDH: unchanged (don't use comb)
https://claude.ai/code/session_011KVZhDcV2G7idNWEBz12GY
nrobi144