Computing on Bitcoin #111
October 16, 2026 - Week 42
Welcome to a new edition of Computing on Bitcoin News! Let's dive into this week's roundup.
A new paper proposes Trustless Bitcoin Vaults, a primitive for collateral-based applications in which the depositor or known counterparties can withdraw BTC without trusting a third party. It notes that all bridges to date, including state-of-the-art BitVM bridges, rely on trust in a committee or centralized party, and it instantiates the primitive for a lending application.
eprint.iacr.org
🔗
Trustless Bitcoin Vaults
Bitcoin (BTC) is the largest crypto asset, yet the Bitcoin blockchain offers few applications in which BTC can be used. A standard approach to make BTC useful is bridging: BTC is deposited on the Bitcoin chain and a wrapped asset is minted on a chain such as Ethereum, where it can be used in smart contract applications. Unfortunately, all Bitcoin bridges to date require trust assumptions on a centralized party or a committee running the bridge to enable withdrawals of the deposited BTC, including state-of-the-art BitVM bridges.
eprint.iacr.org
🔗
Trustless Bitcoin Vaults
Bitcoin (BTC) is the largest crypto asset, yet the Bitcoin blockchain offers few applications in which BTC can be used. A standard approach to make BTC useful is bridging: BTC is deposited on the Bitcoin chain and a wrapped asset is minted on a chain such as Ethereum, where it can be used in smart contract applications. Unfortunately, all Bitcoin bridges to date require trust assumptions on a centralized party or a committee running the bridge to enable withdrawals of the deposited BTC, including state-of-the-art BitVM bridges.
A new paper by Alpen Labs researchers examines the post-quantum security and costs of garbled-circuit Bitcoin bridges, analyzing designs including BitVM3, Glock, and Mosaic.
eprint.iacr.org
🔗
The Post-Quantum Cost of Garbled-Circuit Bitcoin Bridges
Recent Bitcoin bridge designs rely on verification of succinct proofs to process withdrawals. This requires off-chain garbled circuit evaluation of a succinct proof, the input labels for which must be encoded on chain in a manner compatible with malicious security. We assess the post-quantum vulnerability of these cryptographic components, and examine the costs of secure alternatives.
eprint.iacr.org
🔗
The Post-Quantum Cost of Garbled-Circuit Bitcoin Bridges
Recent Bitcoin bridge designs rely on verification of succinct proofs to process withdrawals. This requires off-chain garbled circuit evaluation of a succinct proof, the input labels for which must be encoded on chain in a manner compatible with malicious security. We assess the post-quantum vulnerability of these cryptographic components, and examine the costs of secure alternatives.
An overview of BIP-446 explains OP_TEMPLATEHASH, a proposed Bitcoin opcode for committing to transaction templates, its trade-offs compared with CTV, and implications for BitVM constructions.
spark.money/glossary
🔗
BIP 446 (OP_TEMPLATEHASH)
A Taproot-native alternative to CTV that provides transaction template verification with a cleaner implementation. BIP 446 is a draft Bitcoin Improvement Proposal that defines a new opcode called OP_TEMPLATEHASH for use within Tapscript.
A new paper by Fairgate's Sergio Lerner introduces FlatMerkle, a construction that enables logarithmic-size inclusion proofs and verification over a single linear hash stream, without requiring a traditional Merkle tree structure. The paper explores applications to Bitcoin transaction commitments, data availability, and optimistic rollups.
eprint.iacr.org
🔗
FlatMerkle: Logarithmic-Space Inclusion Proofs over a Single Linear Hash Stream
Merkle trees are the standard way to obtain logarithmic-size, logarithmic-time inclusion proofs over a large dataset, but they require a tree-shaped hash structure distinct from the ordinary, linear (Merkle–Damgård) hashing that most deployed systems — including Bitcoin's own transaction and witness hashing — actually perform. We present FlatMerkle, a construction that achieves the same asymptotic guarantees, O(log N) proof size and O(log N) verification time, over a single ordinary linear hash stream, by periodically re-injecting the hash function's own past internal states (“checkpoints”) back into the stream as ordinary message content.
That's all for this week's Computing on Bitcoin News. We'll be back with more research, ideas, and developments from across the Bitcoin ecosystem.
Until next time,
The Fairgate Team