Bidirectional Payment Channel Mechanisms

Updated 13 November 2025

Bidirectional payment channels are cryptographic state channels that let two parties exchange off-chain payments by securely updating shared, locked collateral.
They use mutual authentication with commitment transactions, hash/time-lock contracts, and innovative schemes like one-time signatures to ensure fairness and penalize outdated states.
Empirical studies and protocol comparisons reveal that these channels improve scalability and resource efficiency while supporting advanced features such as privacy and conditional payments.

A bidirectional payment channel is a cryptographic state channel that allows two parties to exchange payments off-chain, redistributing fixed locked collateral in either direction via a series of mutually authenticated state updates. Extensively employed in scalability solutions (notably the Lightning Network), bidirectional channels enforce off-chain state consistency and punish equivocation through cryptographically linked revocation mechanisms or monotonic sequence control. Modern constructions extend the core protocol to support privacy, conditional payments (HTLCs/PTLCs), and efficient watchtower services, with performance validated in both public blockchain overlays and specialized contract platforms.

1. Formal Construction and Update Protocols

The bidirectional payment channel operates with an initial funding transaction locking assets into a jointly controlled UTXO (commonly 2-of-2 multisig or taproot), denoted as

$\texttt{2 \; <Pub_A> \; <Pub_B> \; 2 \; OP\_CHECKMULTISIG}$

for Bitcoin or similar primitives for other blockchains. Initial balances $(b_A, b_B)$ , where $b_A+b_B=C$ , reflect the collateral available for both parties.

State updates occur off-chain through mutually signed commitment transactions containing current balance allocations and revocation primitives. In Poon-Dryja Lightning, each commitment embeds a sequence number and encodes outputs:

"Local" output: Timelock ( $t$ ) plus revocation script.
"Remote" output: Immediate spend for the counterparty. HTLC outputs introduce hash-locked, time-locked branches.

OTS-PC (Lerner et al., 6 Nov 2025) generalizes this with one-time signatures (OTS) over strictly monotonic sequence numbers $S(i)$ , removing revocation secret chains. At each update:

Parties exchange signatures on exit/punish transactions for state $i+1$ .
Commitments $(sk^{A},\bar pk^{A})$ are used to sign the next state index.
Punishment is automated by requiring a valid OTS signature for a strictly older sequence ( $j < i$ ), checked by script.

The Lightning Network empirical paper (Grötschla et al., 24 Sep 2024) verifies that commitment indices are veiled using hashed locktimes for privacy, and mutual agreement is ensured through continuous signature exchange and revocation key release, with on-chain dispute resolution possible if off-chain consensus breaks down.

2. On-Chain Dispute Resolution and Closure

Channels can be closed cooperatively or unilaterally:

Cooperative close: Both parties sign and publish a transaction returning the current balances directly from the funding output ($\texttt{<Pub_A> OP_CHECKSIG}$, $\texttt{<Pub_B> OP_CHECKSIG}$).
Unilateral close: One party may broadcast its latest commitment, triggering a time-locked challenge period during which the counterparty can respond with a revocation secret or, in OTS-PC, a punish transaction showing a one-time signature from an older state.

Timeout enforcement is achieved via script primitives (e.g., OP_CHECKSEQUENCEVERIFY), often augmented by secret preimages or hashlocks to allow the honest counterparty to claim all funds if a cheater stalls. The validity of the latest state is enforced by checked sequence numbers, and in OTS-PC, old secret keys are erased immediately after use.

Empirical data (Grötschla et al., 24 Sep 2024) shows ~51% of Lightning channels close cooperatively; unilateral closes comprise the balance, with a small but significant portion requiring explicit on-chain fraud punishment. Resurrected channels—where closure outputs are used to fund new channels—make up 56% of cooperative public channel closures.

3. Security, Correctness, and Impossibility Results

Bidirectional payment channels achieve strong Byzantine Sequential Consistency (BSC): no funds are created or destroyed, and every off-chain history is sequentially consistent with the on-chain model. Safety is enforced through cryptographic punishments: if a party broadcasts an outdated commitment, the counterparty, holding a proper secret (or an older OTS signature in OTS-PC), is able to sweep all outputs.

For asynchronous models, a fundamental impossibility result (Naor et al., 2022) establishes that deterministic, wait-free, purely asynchronous message-passing cannot implement bidirectional payment channels under crash-fail or Byzantine failures—equivalent to violating the FLP limit. Real-world implementations circumvent this by assuming partial synchrony (timeouts, watchdog services), as in Lightning, with penalty scripts keyed to dispute-response intervals.

In IoT-oriented frameworks (Hannon et al., 2018), economic incentives and lightweight BIP-32 key derivation minimize computational and storage overhead. The game-theoretic model guarantees equilibrium under rational strategies: cheating leads to complete loss, rendering honest behavior strictly dominant.

4. Extensions: Conditional Payments, Privacy, Smart Contracts

Payment channels routinely compose HTLCs (hashed timelock contracts) or PTLCs (proposition timelock contracts) for conditional payments and multi-hop routing:

HTLC script (Lightning/OTS-PC) encodes

$\texttt{OP\_IF} \;\;<\!H(x)\!>\;\;\texttt{OP\_EQUALVERIFY}\;\; \texttt{OP\_CHECKSIG} \;\texttt{OP\_ELSE}\;\;<t\!>\;\texttt{OP\_CSV}\;\texttt{OP\_CHECKSIG}$

In PTLCs (Brown et al., 10 Sep 2025), a bet is placed on whether proposition $P$ is proven by time $T$ , with payout contingent on an on-chain proof or time-lapse.

Privacy enhancements are achieved in OTS-PC by Level-2/Level-3 watchtower schemes encrypting punishment bundles with per-state keys, revealing minimal information unless on-chain dispute occurs.

Smart-contract based platforms (Niji (Watanabe et al., 2018), xLumi (Ying et al., 2021)) adopt bidirectional or paired unidirectional channels, instantiate off-chain updates as state-monotonic signed messages, and delegate verification to on-chain logic. Niji's transaction template enables non-interactive payment updating in the "normal" direction and supports atomic service invocation cross-chain. xLumi leverages monotonic counters and joint digital signatures (Eltoo-style) for bidirectionality, obviating the need for punishment transactions.

5. Resource Efficiency, Scalability, Routing Algorithms

OTS-PC (Lerner et al., 6 Nov 2025) achieves $O(1)$ storage per channel for both peers and watchtowers—a significant advancement over Poon-Dryja (which requires $O(N)$ per channel). Key exhaustion bounds total permissible updates (e.g., $2^{32}$ ), while revocation-secret-based (Lightning, IoT) channels require careful management of chains or trees of secrets.

Routing in payment channel networks is optimized via stochastic models (Varma et al., 2019) mapping each channel to a two-sided queue structure. The capacity region $\mathcal{C}$ is characterized by linear constraints on per-channel flow and rebalancing operations. Routing is performed with MaxWeight-style algorithms, minimizing per-path aggregate imbalance and load. Small per-channel randomized on-chain rebalancing suffices to attain strong positive-recurrence stability, confirmed in simulation for both synthetic and real-world overlays (e.g., Ripple's Lightning-style graph). Water-filling variants and k-shortest-path heuristics are shown to improve both off-chain success ratios and mean imbalances over fluid (static-split) policies.

6. Protocol Comparison and Practical Considerations

A summary table delineates major bidirectional channel constructions:

Feature	Poon-Dryja Lightning	OTS-PC (Lerner et al., 6 Nov 2025)	Niji (Watanabe et al., 2018)	xLumi (Ying et al., 2021)
State revocation	Per-commitment secrets	One-time OTS signatures	Hash/time-lock refund	Eltoo-style sequence
Watchtower storage	O(N) per channel	O(1) per channel	None (non-interactive)	None
On-chain weight	~2,500 wu/exit	~2,405 wu/exit	~300–500 vbytes/open/close	~100–200 vbytes
Complexity	Multiple timelocks	Simpler DAG, few branches	Template signing	Monotonic counters

Upgrade paths are non-disruptive; OTS-PC leverages existing opcodes (OP_HASH256; OP_CHECKSEQUENCEVERIFY). Incentive alignment in watchtower models is achieved through fee or reward outputs; non-interactive channels like Niji and xLumi minimize monitoring requirements. Limitations include key exhaustion, script support dependencies, and finality guarantees on external chains or smart contract platforms.

7. Empirical Findings and Future Directions

Channel lifetimes exhibit high variance (public channels: ≈143 days (Grötschla et al., 24 Sep 2024)), with closure imbalances indicating usage as unidirectional rails until depleted. Fee-update patterns reveal that only a minority of channels are active for routing at any given time. Sparse revocation events and rapid on-chain legging indicate robust protocol-level fraud prevention.

Open questions concern the scalability of OTS key schemes, interoperability across heterogeneous channel constructions, multi-party or channel-factory generalizations, and asynchronous deployment feasibilities. The formal impossibility of fully asynchronous bidirectional channels (Naor et al., 2022) motivates further investigation into relaxations via synchrony assumptions or novel cryptographic primitives.

Bidirectional payment channels remain a foundational primitive in off-chain scaling, cryptographic contract composition, and decentralized routing for blockchains. Recent constructions, notably OTS-PC (Lerner et al., 6 Nov 2025), advance the art by minimizing the update protocol complexity, storage requirements, and privacy leakage, while rigorous stochastic routing models (Varma et al., 2019) underpin reliable network-wide operation. As deployment broadens—from resource-constrained IoT devices to smart-contract–driven cross-chain systems—protocol design continues to emphasize provable security, economic soundness, and robust interoperability.