Jun 6, 2026

Correct. With the current UF GPU verification ABI, the GPU-facing input is columnar: message hashes, public keys, and signatures are passed as separate contiguous buffers. So if the source table is stored as horizontal rows, some row-to-column transformation is currently required before calling the existing GPU path. What I meant by “no copy” was only that the bridge does not interpret or copy the correlation tail into the verification core. That was too broad as written. The packed-row path still de-interleaves the verified record bytes into the existing columnar GPU ABI. The clean way to avoid that bridge-side transformation is to expose both formats: 1. keep the current packed-row API for callers that naturally produce `[record | key]` rows; 2. add a columnar API for callers that can store/produce `hashes[]`, `pubkeys[]`, `sigs[]`, and optional `keys[]` directly. Then libbitcoin can choose the storage layout. If you keep the row table, the transform is necessary for the current GPU ABI. If you produce vertical columns, the bridge can forward them directly to UF’s existing GPU calls and skip the row-to-column copy. I agree that the multisig correlation pass itself should not be the bottleneck if it is O(n), allocation-free, and runs after per-row signature verdicts are known. The expensive part to avoid is streaming the signature records through an extra host-side de-interleave pass.