• Ark as a Channel Factory: Compressed Liquidity Management for Improved Payment Feasibility
• Bithoven: A New Bitcoin Smart Contract Language Bridging Expressiveness and Formal Safety
  • Bitcoin-IPC: Scaling Bitcoin via PoS Subnet
  • Using Observable Mempools to Determine Transaction Timing and Fees
  • Hornet UTXO (1): A UTXO Database Optimized for Maximum Bitcoin Consensus Throughput
  • Global Lightning Network Snapshots: A Spatiotemporal Dataset from 2019–2023
  • OHMG: Improving Off-Chain Verification of Garbled Circuits by Changing Arithmetic Representation
  • Babylon: An Introduction to the Trustless BTCVault (TBV) Protocol
  • Risks Beyond Digital Assets: Real-World Attacks on Bitcoin Are Increasing

§Ark as a Channel Factory: Compressed Liquidity Management for Improved Payment Feasibility

René Pickhardt proposed and discussed the idea of using Ark as a channel factory, rather than as an end-user payment solution.

Pickhardt’s idea focuses on the possibility that many channel owners could batch their channel liquidity changes (opens, closes, and splices) using Ark’s vTXO (virtual Transaction Outputs) structure. This approach can significantly reduce the on-chain cost of operating the Lightning Network, at the expense of some additional liquidity overhead. This additional liquidity overhead primarily occurs during the period between when a channel is forfeited and when the Ark batch it belongs to fully expires. By using Ark batches as efficient channel factories, Lightning Service Providers (LSPs) can provision liquidity to a larger number of end users more efficiently. The built-in batch expiration mechanism also allows LSPs to reclaim liquidity from idle channels without resorting to costly, dedicated on-chain force closes.

Routing nodes can benefit as well: instead of performing frequent individual splices, they can periodically rebalance liquidity across channels using Ark batches, resulting in more efficient channel management.

In the follow-up discussion, Vincenzo Palazzo noted that he has already implemented a proof-of-concept Ark channel factory.

§Bithoven: A New Bitcoin Smart Contract Language Bridging Expressiveness and Formal Safety

The Bitcoin community is exploring a new smart contract language, Bithoven. Proposed as a response to Miniscript, its designers argue that while Miniscript provides essential abstractions for policy verification, it fails to model the full imperative logic required for complex contracts, leaving gaps in state management and resource liveness. By integrating a strict type checker and a resource liveness analyzer with a semantic control-flow analyzer, Bithoven eliminates major categories of consensus and logic defects defined in their fault model prior to deployment.

Paper: Bithoven: Formal Safety for Expressive Bitcoin Smart Contracts

§Bitcoin-IPC: Scaling Bitcoin via PoS Subnet

This research introduces Bitcoin-IPC, a software stack and protocol designed to enable Bitcoin to function as a universal Medium of Exchange by supporting permissionless creation of fully programmable PoS Layer-2 chains (subnets). Assets staked on the subnets are denominated in BTC on Bitcoin L1, upon which the system relies for information propagation, settlement, and security.

Inspired by SWIFT messaging and embedded within Bitcoin’s SegWit framework, the design allows value transfers between different L2 subnets to be routed and settled via Bitcoin L1. Notably, without requiring any changes to Bitcoin L1, this approach can reduce the virtual byte cost per transaction (vB/tx) by up to 23×, increasing monetary transaction throughput from roughly 7 TPS to over 160 TPS.

§Using Observable Mempools to Determine Transaction Timing and Fees

This study examines how transaction fees affect transaction inclusion priority. Currently, by inspecting their local mempool, a strategic user can delay transaction broadcasts and set fees as low as possible while remaining unconfirmed. However, due to the randomness of mining intervals, delayed broadcasts risk missing the next block. Meanwhile, fee bumping mechanisms allow users to increase fees before confirmation, introducing additional complexity.

The paper proposes a new transaction strategy that jointly determines broadcasting time and transaction fee It analyzes two representative scenarios:

• Ordinary users: who are unaware of mempool conditions and set fees according to a certain distribution;

• Semi-strategic users: who observe the mempool at a Poisson rate and update fees accordingly.

In the former case, it computes the optimal broadcast timing and transaction fee under arbitrary mining interval distributions. With exponentially distributed block intervals, as in Bitcoin-like PoW systems, a strategic user could broadcast immediately upon creation; with fixed intervals, as in Ethereum-like PoS systems, it becomes optimal to wait until just before block production. In the latter case, researchers use a continuous-time Markov chain to characterize mempool dynamics, and derive the optimal fee adjustment frequency for a strategic user under exponentially distributed block intervals. Both theoretical analysis and simulations show that the user should immediately increase the transaction fee whenever it falls below the minimum fee required for inclusion.

§Hornet UTXO (1): A UTXO Database Optimized for Maximum Bitcoin Consensus Throughput

Developer tobysharp introduced Hornet UTXO (1), a new UTXO database specifically designed to maximize throughput in Bitcoin consensus validation.

Implemented in modern C++, the database exploits parallelism and is highly concurrent and lock-free.

Hornet UTXO (1) is a component of Hornet Node, an experimental Bitcoin client focused on declarative consensus specifications and high performance. More details can be found in: Hornet Node and the Hornet DSL: A Minimal, Executable Specification for Bitcoin Consensus

§Global Lightning Network Snapshots: A Spatiotemporal Dataset from 2019–2023

This study presents a curated dataset of Lightning Network snapshots from January 2019 to July 2023, comprising 336 geolocated LN topology snapshots. The snapshots were reconstructed from publicly available gossip message archives. The authors applied strict consistency checks and enriched node metadata using city-level geolocation derived from public IP addresses.

The resulting dataset captures both the temporal and spatial evolution of LN, filling a key research gap. The reconstructed snapshots were also cross-validated against independent statistics to establish a robust and reliable benchmark.

§OHMG: Improving Off-Chain Verification of Garbled Circuits by Changing Arithmetic Representation

Efficient verification of complex off-chain computation remains a major bottleneck for blockchain scalability. Garbled-circuit-based approaches typically rely on Boolean circuit representations, resulting in massive communication and storage requirements.

To address this inefficiency, a new garbling scheme OHMG (One-Hot Modular Garbling) is introduced. It improves efficiency by changing how arithmetic computation is represented. Instead of decomposing arithmetic operations into Boolean gates, OHMG natively processes small integers using one-hot encoding. As a result, the resulting garbling framework requires at most one ciphertext per arithmetic gate, independent of circuit size.

§Babylon: An Introduction to the Trustless BTCVault (TBV) Protocol

According to statistics from mid-to-late 2025, only about 1% of Bitcoin is currently used in DeFi. Babylon attributes this low participation to Bitcoin’s limited programmability, which forces users to rely on additional trust assumptions.

Babylon introduces a trustless BTCVault protocol (TBV), enabling native Bitcoin to participate in DeFi while remaining self-custodied and trust-minimized.

The core components of TBV include:

• SNARK: Used to succinctly verify arbitrary program execution. It is used to verify state transitions of TBV-related smart contracts on DeFi chains.

• Garbled circuits: Used to reduce program verification to secret revelation. Babylon encodes the SNARK verifier into a garbled circuit such that, when the proof is valid, evaluating the obfuscated circuit reveals a specific string that only the Bitcoin chain can process.

• Lamport signatures: A one-time signature scheme verifiable in Bitcoin Script, allowing Bitcoin L1 to resolve disputes.

• Bitcoin Script: Bitcoin’s programming language. Babylon particularly relies on: hash lock, time lock, and Taproot addresses.

At the product level, TBV turns Bitcoin into a universal, programmable collateral for any DeFi system. The Bitcoin is neither bridged, wrapped, pooled, fungible, nor rehypothecated.

§Risks Beyond Digital Assets: Real-World Attacks on Bitcoin Are Increasing

Haseeb Qureshi has visualized the data previously collected by Bitcoin developer/security researcher Jameson Lopp on real-world physical attacks against Bitcoin users (GitHub: Known Physical Bitcoin Attacks)

The visualization shows that attacks increased and are becoming more violent. The actual situation may be even worse, as many attacks likely go unreported. Victims may fear becoming targets again or distrust law enforcement’s ability to help, leading them to remain silent.

According to Qureshi’s analysis, the primary driver of these attacks is price: as Bitcoin’s price rises, attackers perceive greater opportunity (White: market cap; colors: violent incidents):

Geographically, the sharpest increases in reported attacks have occurred in Western Europe and parts of Asia: