arxiv: 2605.06853 · v1 · submitted 2026-05-07 · 💻 cs.CR

Recognition: 2 theorem links

· Lean Theorem

The Cost of Quantum Resistance: A Hash-Based Commit-Reveal Alternative for Minimizing Blockchain Infrastructure Overhead

Keir Finlow-Bates , Markus Jakobsson , Hossein Siadati

Authors on Pith no claims yet

Pith reviewed 2026-05-11 02:11 UTC · model grok-4.3

classification 💻 cs.CR

keywords post-quantum cryptographyblockchaincommit-revealhash functionstransaction sizequantum resistanceauthorization security

0 comments

The pith

A commit-reveal pair of 32-byte hash transactions replaces one signature to secure blockchains against quantum computers.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that current post-quantum signature schemes create prohibitive costs in globally replicated blockchains because larger data sizes multiply across every node for storage, bandwidth, and validation. It proposes replacing a single signature transaction with two separate lightweight transactions that use ordinary 32-byte hashes in a commit step followed by a reveal step. This construction relies on standard hash functions such as SHA-256 to achieve security against quantum attacks without needing new mathematical assumptions. The net result is an increase in data footprint of only about 1.5 to 2 times per authorization rather than the much larger multipliers from lattice-based or stateless hash-based signatures. A reader would care because the approach suggests that quantum resistance can be added through changes in transaction format instead of waiting for major hardware or protocol overhauls.

Core claim

We propose a hash-based commit-reveal construction that replaces a single signature-bearing transaction with two lightweight transactions, each containing a fixed-size (32-byte) hash output derived from well-established primitives such as SHA-256, BLAKE, or Keccak. This approach achieves post-quantum security under standard hash assumptions while increasing the effective transaction footprint by only approximately 1.5 times to 2 times per authorization event. These results indicate that practical post-quantum migration may benefit from rethinking transaction semantics rather than directly adopting larger signature schemes, and that viable designs for decentralized systems must account for sy

What carries the argument

The hash-based commit-reveal construction in which one transaction commits a hash and a second reveals the preimage to authorize the action.

If this is right

Transaction semantics can be updated to support post-quantum security without adopting the full size of existing post-quantum signature schemes.
Storage and bandwidth demands across all network nodes grow by a bounded factor rather than scaling with the size of new cryptographic primitives.
Economic and infrastructural barriers to quantum-resistant migration become lower when authorization cost is measured per event rather than per signature.
System designs for decentralized networks must incorporate the multiplicative effect of any per-transaction size increase.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Existing blockchains could adopt the pattern by defining new transaction types without altering consensus rules on signature verification.
The method might generalize to other distributed ledgers facing similar quantum threats where transaction size directly affects operational costs.
Further work could test whether additional mechanisms are needed to prevent front-running between the commit and reveal steps in high-throughput environments.

Load-bearing premise

A two-transaction commit-reveal sequence provides equivalent authorization security and resistance to replay or front-running attacks as a single digital signature in a blockchain consensus setting.

What would settle it

A demonstration in a live or simulated blockchain that an adversary can forge authorization or succeed at a replay attack on the commit-reveal sequence without breaking the underlying hash function would falsify the security claim.

Figures

Figures reproduced from arXiv: 2605.06853 by Hossein Siadati, Keir Finlow-Bates, Markus Jakobsson.

**Figure 1.** Figure 1: Approximate transaction size under different signature schemes. Postquantum signatures increase transaction size by one to two orders of magnitude. As discussed in Section 2.3, techniques such as SegWit can adjust the accounting cost of certain types of data, but do not eliminate the need to physically store and propagate that data. Similarly, Ethereum’s gas model can abstract away per-byte pricing for c… view at source ↗

**Figure 2.** Figure 2: Projected storage requirements for Ethereum nodes under post-quantum signature schemes. Archive nodes approach the petabyte scale (1000 TB). Such increases represent a qualitative shift in infrastructure requirements rather than a marginal extension of current trends. Assuming typical hardware improvement rates, such as storage capacity doubling approximately every two years, accommodating a 50×–100× incr… view at source ↗

read the original abstract

The transition to post-quantum cryptography in blockchain systems such as Bitcoin and Ethereum is often framed as a purely cryptographic problem. In practice, it also presents significant economic and infrastructural challenges: in globally replicated networks, increases in transaction size and verification cost are multiplied across all participating nodes. Existing post-quantum signature schemes, including lattice-based constructions such as CRYSTALS-Dilithium and stateless hash-based schemes such as SPHINCS+, introduce substantial increases in signature size. At blockchain scale, these increases translate into higher storage, bandwidth, and validation requirements, potentially requiring multiple generations of hardware improvement to become operationally routine. Historical experience suggests that even moderate increases in data footprint can be contentious, as illustrated by the Bitcoin block size debates (2015--2017). We propose a hash-based commit--reveal construction that replaces a single signature-bearing transaction with two lightweight transactions, each containing a fixed-size (32-byte) hash output derived from well-established primitives such as SHA-256, BLAKE, or Keccak. This approach achieves post-quantum security under standard hash assumptions while increasing the effective transaction footprint by only approximately 1.5$\times$ to 2$\times$ per authorization event. These results indicate that practical post-quantum migration may benefit from rethinking transaction semantics rather than directly adopting larger signature schemes, and that viable designs for decentralized systems must account for system-wide cost amplification.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

The paper proposes a commit-reveal hash scheme to cut post-quantum signature overhead in blockchains to 1.5-2x, but the security equivalence to atomic signatures is not shown.

read the letter

The main takeaway is that this work tries to sidestep the size explosion from post-quantum signatures by splitting an authorization into two 32-byte hash transactions instead of one large signed one. It uses standard hashes like SHA-256 or Keccak and claims post-quantum security under ordinary hash assumptions while limiting the network-wide cost increase. That framing is the useful part: it treats the infrastructure multiplication across nodes as the real constraint, not just the crypto primitive itself, and it nods to the block-size fights as evidence that even moderate growth can stall adoption. The approach is straightforward and builds on existing commit-reveal patterns, so the engineering direction is clear enough to evaluate. The soft spot is the missing security argument. A single signature gives atomic binding and non-malleability in one step. Splitting into commit then reveal leaves the first hash visible in the mempool, which opens replay or front-running vectors unless the construction adds tight bindings to transaction IDs, block heights, or nonces. The abstract states the size and security claims but supplies no reduction, attack model, or comparison data, so it is not possible to tell whether the 1.5-2x footprint actually preserves authorization strength under standard blockchain threats. This paper is aimed at people working on practical post-quantum upgrades for replicated systems rather than pure cryptographers. A reader focused on deployment costs would get something concrete to think about. It deserves peer review because the problem it targets is genuine and the proposed direction is testable, even though the security details will need substantial work to hold up.

Referee Report

1 major / 1 minor

Summary. The paper proposes a hash-based commit-reveal construction that replaces a single signature-bearing blockchain transaction with two lightweight 32-byte hash transactions (using primitives such as SHA-256). It claims this achieves post-quantum security under standard hash assumptions while increasing transaction footprint by only 1.5×–2× per authorization event, as an alternative to larger post-quantum signatures like CRYSTALS-Dilithium or SPHINCS+.

Significance. If the security equivalence and attack resistance claims hold, the result would be significant for blockchain systems by offering a lower-overhead path to post-quantum migration that avoids network-wide amplification of storage, bandwidth, and validation costs.

major comments (1)

[Abstract] Abstract: the central claim that the two-transaction commit-reveal sequence provides authorization security and attack resistance (replay, front-running) equivalent to a single digital signature is unsupported; no security reduction, attack model, or binding mechanism (e.g., to transaction ID, block height, or nonce) is supplied to justify the equivalence under standard hash assumptions.

minor comments (1)

[Abstract] Abstract: the factor 'approximately 1.5× to 2×' is stated without an explicit baseline transaction size or breakdown of the two-hash overhead relative to a typical signature transaction.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We appreciate the referee's thorough evaluation of our work. Below we respond to the major comment and outline the revisions we will make to strengthen the security presentation.

read point-by-point responses

Referee: [Abstract] Abstract: the central claim that the two-transaction commit-reveal sequence provides authorization security and attack resistance (replay, front-running) equivalent to a single digital signature is unsupported; no security reduction, attack model, or binding mechanism (e.g., to transaction ID, block height, or nonce) is supplied to justify the equivalence under standard hash assumptions.

Authors: We concur that the abstract, due to its brevity, does not include a formal security reduction or explicit attack model. Our construction draws on the standard security properties of cryptographic hash functions—namely, preimage resistance—to ensure that only the party knowing the preimage can produce a valid reveal transaction matching the committed hash. Regarding attack resistance, replay attacks can be countered by incorporating a unique nonce or timestamp in the reveal value, and front-running can be mitigated by the atomic nature of the commit-reveal pair within the blockchain's consensus rules. However, to make these arguments rigorous, we will add a new subsection in the revised manuscript that defines the security model, outlines potential attacks (including replay and front-running), and provides an informal reduction to the hash function assumptions. This will support the central claim of authorization security equivalence to digital signatures in this context. revision: yes

Circularity Check

0 steps flagged

No circularity: proposal rests on external hash assumptions, not self-definition or fitted inputs

full rationale

The manuscript presents a design proposal for a two-transaction hash-based commit-reveal scheme to replace signature-bearing transactions. No equations, parameter fits, or derivations appear in the provided text. The security claim is explicitly grounded in 'standard hash assumptions' for primitives such as SHA-256 rather than any self-referential definition, renaming of known results, or load-bearing self-citation. The 1.5–2× footprint increase is stated as an empirical observation of transaction sizes, not a fitted prediction. The construction is therefore self-contained against external cryptographic benchmarks and does not reduce to its own inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Abstract-only review; no explicit free parameters, axioms, or invented entities are stated. Full paper required for complete ledger.

pith-pipeline@v0.9.0 · 5564 in / 1086 out tokens · 33635 ms · 2026-05-11T02:11:32.576942+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Cost/FunctionalEquation.lean (Jcost uniqueness, Aczél classification) washburn_uniqueness_aczel unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

We propose a hash-based commit–reveal construction that replaces a single signature-bearing transaction with two lightweight transactions, each containing a fixed-size (32-byte) hash output derived from well-established primitives such as SHA-256, BLAKE, or Keccak.
IndisputableMonolith/Foundation/AlphaCoordinateFixation.lean (higher-derivative calibration of CostAlphaLog) J_uniquely_calibrated_via_higher_derivative unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

Total Cost∝Transaction Size×Number of Nodes.

What do these tags mean?

matches: The paper's claim is directly supported by a theorem in the formal canon.
supports: The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends: The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses: The paper appears to rely on the theorem as machinery.
contradicts: The paper's claim conflicts with a theorem or certificate in the canon.
unclear: Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

33 extracted references · 33 canonical work pages

[1]

7BlockLabs,Ethereum full node storage requirements (2026), 2026,https: //www.7blocklabs.com/blog/ethereum-full-node-disk-size-2026-e 17 thereum-full-node-storage-requirements-2026-and-ethereum-ful l-node-size-2026

work page 2026
[2]

Bernstein, Andreas H¨ ulsing, Stefan K¨ olbl, Ruben Niederhagen, Joost Rijneveld, and Peter Schwabe,The SPHINCS+ signature framework, 2019

Daniel J. Bernstein, Andreas H¨ ulsing, Stefan K¨ olbl, Ruben Niederhagen, Joost Rijneveld, and Peter Schwabe,The SPHINCS+ signature framework, 2019

work page 2019
[3]

Accessed 29 April 2026

Bitcoin Core,Segregated witness wallet development guide,https://bitc oincore.org/en/segwit_wallet_dev/, 2016, Developer guide describing SegWit transaction serialization, witness relay, virtual size, and activation at block height 481824. Accessed 29 April 2026

work page 2016
[4]

Accessed 29 April 2026

Bitcoin Optech,Transaction size calculator,https://bitcoinops.org /en/tools/calc-size/, 2026, Technical reference for Bitcoin transac- tion byte sizes, weight units, and virtual-byte treatment of witness data. Accessed 29 April 2026

work page 2026
[5]

Bitcoin Wiki,Transaction, 2024,https://en.bitcoin.it/wiki/Transac tion

work page 2024
[6]

Accessed 29 April 2026

Bitnodes,Global bitcoin nodes,https://bitnodes.io/nodes/all/, 2026, Estimated size of the Bitcoin peer-to-peer network including reachable and unreachable nodes. Accessed 29 April 2026

work page 2026
[7]

Accessed 29 April 2026

Blockchair,Dogecoin node explorer,https://blockchair.com/dogecoi n/nodes, 2026, Publicly accessible Dogecoin node count. Accessed 29 April 2026

work page 2026
[8]

Accessed 29 April 2026

,Litecoin node explorer,https://blockchair.com/litecoin/no des, 2026, Publicly accessible Litecoin node count. Accessed 29 April 2026

work page 2026
[9]

Vitalik Buterin,A next-generation smart contract and decentralized appli- cation platform, 2014,https://ethereum.org/en/whitepaper/

work page 2014
[10]

Cherry Servers,Ethereum node requirements: Full vs archive nodes, 2024, https://www.cherryservers.com/blog/ethereum-node-requirements

work page 2024
[11]

Accessed 29 April 2026

Coin Dance,Bitcoin cash nodes summary,https://cash.coin.dance/no des, 2026, Publicly accessible Bitcoin Cash node count, corrected to omit duplicate and non-listening nodes. Accessed 29 April 2026

work page 2026
[12]

1, 238–268

L´ eo Ducas, Eike Kiltz, Tancr` ede Lepoint, Vadim Lyubashevsky, Peter Schwabe, Gregor Seiler, and Damien Stehl´ e,Crystals-dilithium: A lattice- based digital signature scheme, IACR Transactions on Cryptographic Hard- ware and Embedded Systems2018(2018), no. 1, 238–268

work page 2018
[13]

Accessed 29 April 2026

ethereum.org,Ethereum archive node,https://ethereum.org/develop ers/docs/nodes-and-clients/archive-nodes/, 2026, Documentation describing Ethereum full and archive node storage behavior. Accessed 29 April 2026. 18

work page 2026
[14]

Accessed 29 April 2026

Ethernodes,Ethereum mainnet statistics: Execution layer and consensus layer clients,https://ethernodes.org/, 2026, Ethereum node and client statistics. Accessed 29 April 2026

work page 2026
[15]

Accessed 29 April 2026

Etherscan,Ethereum node tracker,https://etherscan.io/nodetracker, 2026, Public tracker reporting detected Ethereum nodes. Accessed 29 April 2026

work page 2026
[16]

Tiago M. Fern´ andez-Caram´ es and Paula Fraga-Lamas,Towards post- quantum blockchain: A review on blockchain cryptography resistant to quan- tum computing attacks, IEEE Access8(2020), 21091–21116

work page 2020
[17]

Financial Stability Board,Annual progress report on meeting the targets for cross-border payments,https://www.fsb.org/uploads/P191224.pd f, 2024, SWIFT connects over 11,500 institutions across more than 200 countries and territories; accessed April 2026

work page 2024
[18]

Available viaht tps://mybook.to/sci

Keir Finlow-Bates,Smart contract innovation: How code, law, and value converge on ethereum, Artema Labs, 2026, First edition. Available viaht tps://mybook.to/sci

work page 2026
[19]

Patent Application

Keir Finlow-Bates and Bjorn Markus Jakobsson,Systems and methods for performing secure transactions on blockchain, December 2025, U.S. Patent Application

work page 2025
[20]

Alison Gon¸ calves Schemitt, Henrique Fan da Silva, Roben Castagna Lu- nardi, Diego Kreutz, Rodrigo Brand˜ ao Mansilha, and Avelino Fran- cisco Zorzo,Assessing the impact of post-quantum digital signature algo- rithms on blockchains, arXiv preprint arXiv:2510.09271 (2025)

work page arXiv 2025
[21]

Accessed 29 April 2026

L2BEAT,L2beat: The state of the layer two ecosystem,https://l2be at.com/, 2026, Analytics and risk data for Ethereum Layer-2 protocols. Accessed 29 April 2026

work page 2026
[22]

24, 4885

Ruiguang Li, Lihuang Zhu, Chao Li, Fudong Wu, and Dawei Xu,Bns: A detection system to find nodes in the bitcoin network, Mathematics11 (2023), no. 24, 4885

work page 2023
[23]

Accessed 29 April 2026

Eric Lombrozo, Johnson Lau, and Pieter Wuille,BIP 141: Segregated wit- ness (consensus layer),https://github.com/bitcoin/bips/blob/mas ter/bip-0141.mediawiki, 2015, Bitcoin Improvement Proposal defining Segregated Witness, block weight, witness serialization, and virtual trans- action size. Accessed 29 April 2026

work page 2015
[24]

Accessed 29 April 2026

Eric Lombrozo and Pieter Wuille,BIP 144: Segregated witness (peer ser- vices),https://github.com/bitcoin/bips/blob/master/bip-0144.me diawiki, 2016, Bitcoin Improvement Proposal defining peer-to-peer relay support for Segregated Witness data. Accessed 29 April 2026. 19

work page 2016
[25]

Satoshi Nakamoto,Bitcoin: A peer-to-peer electronic cash system, Cryp- tography Mailing List (2008),https://bitcoin.org/bitcoin.pdf

work page 2008
[26]

National Institute of Standards and Technology,Post-quantum cryptogra- phy standardization, 2024,https://csrc.nist.gov/projects/post-qua ntum-cryptography

work page 2024
[27]

Shor,Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer, SIAM Journal on Computing 26(1997), no

Peter W. Shor,Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer, SIAM Journal on Computing 26(1997), no. 5, 1484–1509

work page 1997
[28]

SWIFT and Craft.co,Swift financials and revenue (fy2024),https://cr aft.co/society-for-worldwide-interbank-financial-telecommuni cation/financials, 2024, Annual revenue approximately€1.1 billion in 2024; accessed April 2026

work page 2024
[29]

Wikipedia contributors,Bitcoin cash,https://en.wikipedia.org/wiki/ Bitcoin_Cash, 2026, Accessed: 2026-04-08

work page 2026
[30]

,Bitcoin scalability problem,https://en.wikipedia.org/wiki/ Bitcoin_scalability_problem, 2026, Accessed: 2026-04-08

work page 2026
[31]

,Segregated witness,https://en.wikipedia.org/wiki/SegWit, 2026, Accessed: 2026-04-08

work page 2026
[32]

Gavin Wood,Ethereum: A secure decentralised generalised transaction ledger, 2014,https://ethereum.github.io/yellowpaper/paper.pdf

work page 2014
[33]

YCharts,Bitcoin blockchain size, 2026,https://ycharts.com/indicato rs/bitcoin_blockchain_size. 20

work page 2026