Bitcoin full node and query server

Jul 1, 2026

View in context in the libbitcoin Slack #general mirror.

nice work regarding the vert tables! was also starting to suspect it was increasing io. i went down a different route with my benching and tried to understand the ultrafast internals a bit better. i came up with a few patches ive been running that have shown measurable improvements. namely, i want to move anything that can be considered sig verification to the GPU, i.e., no CPU marshalling batches and instead columns are streamed directly into reusable GPU buffers, verified on device, and copied back. i dont think we can ever truly get zero copy since we have to cross a device memory boundary. but if that is possible and the goal, i think this at least is a good step toward it anyways. @Vano Chkheidze you can see the patches i am using here: github.com/josibake/…/patches

Vano Chkheidze18:17

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.