Jul 1, 2026

might have a bug in one of my patches , but it raises another consideration: i think there should be a clear error code returned from ultrafast that indicates "I could not complete the operation / internal error," separate from consensus invalid. right now, if there is an issue inside the engine, it is treated as a consensus failure , which is the wrong treatment imo. I'm adding a patch now for that and running again, but wanted to mention here as a consideration

What would we do with an error from a math function?

i will take a look thanks

we are moving to direct integration without bridge or shim i also build direct integration part so i will take useful part from your patches and will integrate there

if a function with preconditions satisfied cannot satisfy its postconditions, it should throw an exception. since we can't throw an exception across a library boundary, it should translate to an error code. libbitcoin can then decide what to do, which in this case id argue execute a clean shutdown. it should not treat it as a consensus failure , which is not an error but a conclusion. in the case here, i was trying to get dynamic chunking working, ultrafast failed to acquire the memory it needed on the gpu and that was interpreted as the batch being consensus invalid by libbitcoin due to an array with all zeros

Agreed. We should keep consensus verdicts and engine/operational failures strictly separate. If verification completes, then a row can be valid or consensus-invalid. But if the engine cannot complete the operation due to GPU allocation, launch/copy failure, unsupported backend, cancellation, or an internal invariant failure, that must be reported as an operational error, not as “all signatures invalid”. For the direct libbitcoin integration we are moving toward a C++ status/result contract for the GPU/batch paths, so libbitcoin can decide whether to retry on CPU, abort cleanly, or shut down. The direct path will not go through the C ABI/bridge, but the same distinction will exist internally through GpuError/status propagation.

The design objective was of course not to pass GPU failures as invalids. And we could of course abort if the math cannot be completed. There is really no rational execution path at that point. If we cannot do the math, the process needs to terminate, just as I would expect it to do if we cannot do simple addition. The secp library isn't a GPU library, it's a math library. The GPU is one of the tools that it has available. If no GPU can be used, it should fall back to CPU verification. Because if it doesn't that is specifically what the caller is going to have to do. When we call libsecp256k1 we don't have any failure mode, this should not be any different.

This is also why we don't want the caller to have to chunk up the batch for GPUs, and why we do not want a distinct call for CPU or GPU. We arrange the data in an optimal form for either, and expect the call to always complete. There is not even any memory allocation required to execute the call (we don't allocate any when we invoke on the secp loop), so not even OOM should be a possible failure condition.

Agreed. We’ll align to that contract: libbitcoin should keep one secp-style verification call, with no CPU/GPU split and no caller-managed chunking or GPU recovery path. GPU will be treated as an internal engine accelerator. If it is unavailable or unsupported, the engine falls back to CPU. If the math cannot be completed, that is a fatal engine failure, not consensus invalid data.