Bitcoin full node and query server

Jun 6, 2026

View in context in the libbitcoin Slack #general mirror.

Vano Chkheidze20:05
That sounds like the right tradeoff. If the vertical layout is produced directly from mmap-backed physical tables, then collapsing to two logical tables (ECDSA and Schnorr) and keeping the correlation bytes in the stored row format is preferable to paying the horizontal-to-vertical transform cost. The extra ~3 unused bytes on single-signature rows is a small fixed storage overhead (~1.6% by your estimate), while avoiding the extra ~0.5TB copy/allocation over a full run is a much cleaner win. From the engine/bridge side I would keep the interface at the column level: - ECDSA: hashes, public keys, signatures, optional/retained correlation column - Schnorr: hashes, public keys, signatures, optional/retained correlation column The correlation column does not need to be passed into the core verify engine unless that specific call needs it. For normal single-sig rows it can just remain part of the caller-owned table layout and be ignored. For multisig/threshold correlation, the bridge can use the same physical format and select the correlation behavior internally. So I agree: two logical tables backed by vertical physical tables is simpler, avoids the row transform, reduces call complexity, and keeps the wasted bytes small enough that it is not worth optimizing separately until measured otherwise.
👍🏻 1