LtHash is an experimental alternative for maintaining a cryptographic summary of Kaspa’s unspent coins. Aglovale is testing its performance and exploring security choices motivated by future quantum computers. On 15 September 2026, Aglovale reported running the revised design alongside the existing system on two development-network nodes, and warned: “It's not audited/reviewed”. [1]
What the summary does
Kaspa records spendable coins as unspent transaction outputs, or UTXOs. Its existing summary uses MuHash, which supports updating the summary as the set changes, rather than rebuilding it from scratch. [2]
The important design choice is efficient updates to the whole set. In a discussion on 26 February 2026, Michael Sutton explained: “We sacrifice membership proofs for faster rolling updates via multiplicative hashing.” He said the main use case was proving the full set. [2]
That distinction matters: a compact summary of all unspent coins is not automatically a way to provide a small proof that one particular coin belongs to the set. Maxim Biryukov explained that Kaspa’s UTXO set uses MuHash, not a Merkle tree, the structure commonly used for those individual membership proofs. [2]
LtHash explores a different approach to an updateable summary. In the same discussion, Biryukov described an LtHash-based approach as using vector addition and subtraction with modular arithmetic: lists of numbers are combined, with values wrapping around at a fixed limit. [2]
Why test it?
Aglovale’s experiments address two questions: whether the alternative is cheaper to maintain, and which parameters might provide sufficient long-term security against quantum attacks. [3]
On 11 September 2026, Aglovale reported these details:
- The experimental configuration was LtHash(1024,16), with a 2,048-byte state. [3]
- Each element was hashed with Blake2b-256 and expanded using ChaCha20Rng. [3]
- That version measured about 4% cheaper block validation than MuHash, but added 1,664 bytes of state per chain block. These were Aglovale’s experimental measurements, not a promised mainnet improvement. [3]
- The tests compared UTXO state and checked that separate nodes produced matching summaries. [3]
Security was an open question. Aglovale explicitly asked whether the parameters were sufficient for long-term post-quantum security, and whether pursuing a higher security target justified additional storage and computation. [3]
How the experiment changed
After Biryukov asked whether Blake2Xb had been tried, Aglovale explained that the earlier benchmark had used a hand-rolled Blake2b-512 counter mode rather than Blake2Xb itself, and that ruling Blake2X out on that basis had been a mistake. Aglovale then ran further comparisons. [4]
On 15 September, Aglovale reported retaining LtHash(1024,16), but switching to Blake2b-512 followed by two ChaCha20 instances. Each instance receives one 256-bit half of the 512-bit root and produces half the state. [1]
Aglovale described this as raising the “seed funnel” from approximately 2^128 to 2^256, while remaining faster than MuHash in the benchmarks performed. That is a claim about this construction’s seed limitation, not an audited guarantee of overall post-quantum security. [1]
The reported deployment was a shadow experiment on two devnet nodes, not an announced mainnet replacement. The implementation and its security parameters still required review. [1] The central distinction is therefore between a promising measurement and a reviewed protocol change: Aglovale presented this work as experimental research and invited scrutiny. [1][3]