PaperlayerView exact revision on arXiv

Source-linked AI summary

Concurrency and Privacy with Payment-Channel Networks

Giulio Malavolta, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, Srivatsan Ravi

arXiv:1911.09148v1cs.CR

TL;DR

Bitcoin’s throughput and latency limits motivate PCNs, but privacy and concurrent-payment deadlocks remain insufficiently addressed. The paper formalizes these issues in the UC framework and develops Fulgor and Rayo around Multi-Hop HTLC. Fulgor offers privacy with blocking behavior, while Rayo provides non-blocking progress at the cost of weaker anonymity.

  • Problem

    PCNs need rigorous solutions for privacy and concurrent payments, whose handling is understudied and can produce deadlocks when shared-channel capacity is insufficient.

  • Method

    The paper formalizes two PCN concurrency modes in the UC framework and instantiates them with Fulgor and Rayo using Multi-Hop HTLC.

  • Results

    Fulgor provides privacy with blocking progress, whereas Rayo guarantees that some concurrent payment terminates; Multi-Hop HTLC is Bitcoin-compatible and improves prior efficiency results.

  • Takeaways & Limitations

    PCNs can support formally analyzed privacy and concurrency modes in practice, but non-blocking progress necessarily weakens sender and receiver anonymity.

  • Takeaways & Limitations

    The results assume no channel has both endpoints controlled by Byzantine users and model anonymous communication and the blockchain as ideal functionalities.

Abstract

from arXiv · show

Permissionless blockchains protocols such as Bitcoin are inherently limited in transaction throughput and latency. Current efforts to address this key issue focus on off-chain payment channels that can be combined in a Payment-Channel Network (PCN) to enable an unlimited number of payments without requiring to access the blockchain other than to register the initial and final capacity of each channel. While this approach paves the way for low latency and high throughput of payments, its deployment in practice raises several privacy concerns as well as technical challenges related to the inherently concurrent nature of payments, such as race conditions and deadlocks, that have been understudied so far. In this work, we lay the foundations for privacy and concurrency in PCNs, presenting a formal definition in the Universal Composability framework as well as practical and provably secure solutions. In particular, we present Fulgor and Rayo. Fulgor is the first payment protocol for PCNs that provides provable privacy guarantees for PCNs and is fully compatible with the Bitcoin scripting system. However, Fulgor is a blocking protocol and therefore prone to deadlocks of concurrent payments as in currently available PCNs. Instead, Rayo is the first protocol for PCNs that enforces non-blocking progress (i.e., at least one of the concurrent payments terminates). We show through a new impossibility result that non-blocking progress necessarily comes at the cost of weaker privacy. At the core of Fulgor and Rayo is Multi-Hop HTLC, a new smart contract, compatible with the Bitcoin scripting system, that provides conditional payments while reducing running time and communication overhead with respect to previous approaches.

1 Introduction

Payment-channel networks move many payments off-chain to improve Bitcoin’s scalability, but privacy and concurrent-payment handling remain unresolved. This work formalizes these challenges and introduces Fulgor and Rayo, which trade blocking behavior and privacy for non-blocking progress.

  • Scalability and PCNs: Off-chain payment channels reduce blockchain use by recording only channel opening and closing, while PCNs extend this model to multi-hop payments.Users locally agree on updated channel balances, and a path of channels can settle payments between nonadjacent sender and receiver.
  • Open challenges: PCNs face unresolved challenges involving liquidity, network formation, routing scalability, concurrency, and privacy as deployment grows.The paper identifies privacy and concurrency as foundational issues requiring formal study.
  • Privacy and concurrency: Current PCNs expose sensitive channel capacities and payment-path information, while concurrent capacity conflicts can cause deadlocks or starvation.Payments may abort when a channel lacks capacity, including capacity allocated to another in-flight payment.
  • Contributions: The paper formalizes PCN security and privacy in the UC framework, including balance security, value privacy, and sender/receiver anonymity.It also studies concurrency and presents Fulgor and Rayo as protocols using different strategies.
  • Contributions: Fulgor provides provable privacy and Bitcoin compatibility but is blocking, whereas Rayo guarantees non-blocking progress so at least one concurrent payment terminates.The paper proves that enforcing non-blocking progress inevitably reduces sender and receiver anonymity.
  • Contributions: Multi-Hop HTLC supports privacy-preserving conditional payments without changing Bitcoin scripting, while its instantiation reduces data and prover and verifier running times.The reported reductions are from 650 MB to 17 MB, 600 ms to 309 ms, and 500 ms to 130 ms; a prototype reports payments over 10 intermediate users in as few as 5 seconds with 17 MB communication overhead.

2 Background

Payment-channel networks extend off-chain payment channels from direct links to multi-hop paths, reducing blockchain use while introducing atomicity, privacy, and concurrency challenges.

  • Payment Channels: A payment channel enables multiple payments between two users off-chain after bitcoins are deposited into a jointly controlled address.The channel is later closed by recording final balances on the blockchain, while an expiration guarantee refunds the bitcoins at an agreed time.
  • Payments in PCNs: A successful routed payment requires sufficient capacity on every link and an initial value covering the payment plus forwarding fees.In the example, Alice starts a 3-bitcoin payment to deliver 2 bitcoins to Bob, with intermediate capacities adjusted for fees.
  • Concurrency and Atomicity: PCN payment updates must be atomic: either every channel on the path changes or none does, because partial updates can cause users to lose bitcoins.Concurrent payments sharing channels make this requirement difficult, and existing approaches may abort payments when shared-channel balances are insufficient, potentially causing deadlock.
  • Privacy: HTLCs enforce conditional multi-hop payments, but their shared hash can reveal which users participated in the same payment and help colluding intermediaries infer sender and receiver identities.The paper introduces Multi-Hop HTLC to avoid this privacy problem while ensuring intermediate users do not lose bitcoins.
  • Open Challenges: The paper frames privacy and concurrency as connected PCN properties with an inherent trade-off between them.It studies these foundations in response to challenges including liquidity, routing scalability, concurrency, and privacy.

3 Problem Definition: Computation and Attacker model

The paper models PCNs as channel graphs with open, close, and payment operations, and formalizes an attacker plus balance, concurrency, and privacy goals. Its ideal functionality captures serializable execution and relationship anonymity, while the model excludes channels whose two endpoints are Byzantine.

  • A PCN is a graph of Bitcoin accounts and currently open payment channels, defined relative to a blockchain.
  • PCN operations: The openChannel and closeChannel operations respectively add authorized channels to the blockchain and remove them while recording final balances.
  • PCN operations: The pay operation succeeds only when the specified channels form a sender-to-receiver path with sufficient balances; otherwise, no channel balance changes.
  • Attacker model: The attacker can adaptively spawn and corrupt users, while communication between two non-compromised channel users remains confidential.
  • Security and privacy goals: The security goals include balance security, serializability, off-path value privacy, and on-path relationship anonymity.
  • Ideal functionality: The ideal functionality represents concurrent payments serializably, and relationship anonymity prevents corrupted intermediate users from identifying sender-receiver pairs better than probability 1/2 when an honest intermediate exists.
  • Model boundary: Non-blocking progress and serializability cannot coexist when a payment channel has two Byzantine users, so the paper excludes such channels from its claims.

4 Fulgor: Our Construction

Fulgor constructs privacy-preserving PCN payments around Multi-Hop HTLC, using zero-knowledge proofs to unlink hop contracts while retaining Bitcoin compatibility. It formally defines and proves the protocol’s security properties.

  • 4.2 Multi-Hop HTLC: The sender samples secrets, derives hash values from suffix XOR combinations, and distributes per-hop values and proofs to intermediate users.The receiver checks the final preimage, while intermediate users verify corresponding proofs before proceeding.
  • 4.2 Multi-Hop HTLC: Adjacent users establish HTLCs only after comparing matching payment values and hash-derived values, with staggered timeouts differing by ∆.The receiver can claim the payment after the final contract settles, releasing information needed to fulfill upstream contracts.
  • 4.4 Security and Generality: Fulgor UC-realizes its ideal functionality under a random-oracle hash function and zero-knowledge proof system.Only the hash function is required on-chain, enabling full compatibility with current Bitcoin script; the protocol is also applicable to other PCNs meeting its channel requirements.

5 Non-blocking Payments in PCNs

Rayo modifies Fulgor to guarantee non-blocking progress for concurrent PCN payments. The paper proves that this guarantee requires shared global payment state and weakens relationship anonymity.

  • 5 Non-blocking Payments in PCNs: Rayo guarantees that at least one payment terminates among a set of concurrent payments, unlike blocking protocols that can deadlock.Its design orders conflicting payments using payment identifiers and queues payments when capacity is unavailable.
  • 5.1 Concurrency vs Privacy: No strictly serializable disjoint-access-parallel payment-channel implementation can provide non-blocking progress.Achieving non-blocking progress therefore requires global state associated with each payment.
  • 5.1 Concurrency vs Privacy: Rayo uses one Txid across all channels in a payment path and queues payments whose identifiers exceed the currently active payment.This shared identifier models the global state needed for non-blocking progress.
  • 5.2 Ideal World Functionality: Non-blocking progress weakens relationship anonymity because intermediate users can correlate the same payment identifier across the path.In the example, blocking payments leave S1’s possible receivers as {R1, R2}, whereas non-blocking handling identifies R1 as the only possible receiver.
  • 5.4 Security and Privacy Analysis: Rayo UC-realizes its modified ideal functionality and remains compatible with Bitcoin and generally applicable to PCNs.It provides relationship anonymity only when none of the intermediate nodes is compromised.

6 Performance Analysis

The evaluation measures Fulgor’s computation and communication overhead using a proof-of-concept implementation and a simulated linear payment-channel network. The reported costs remain below five seconds and approximately 17 MB for paths with ten intermediate users.

  • Implementation and Testbed: The proof-of-concept implementation uses Python, lnd APIs, SHA-256, and Sphinx for anonymous communication and padded forwarding.Experiments use simulated users connected in a linear network with pre-established channels.
  • Performance: 309 ms is required to compute each intermediate-user proof, each proof is 1.65 MB, and each intermediate user needs 130 ms to verify it.The evaluation focuses on zero-knowledge proofs as the most expensive operation.
  • Performance: 1.32 seconds is the total computation overhead for lnd pay plus Multi-Hop HTLC, while communication overhead is less than 5 MB for the tested path.The Fulgor pay operation requires less than two seconds of computation and less than five megabytes of communication among users in that path.
  • Scalability: 3.09 seconds is the sender’s proof-generation time per intermediate user in the scalability analysis.Proof generation can be parallelized across current multi-core systems, while intermediate-user verification requires 130 ms.
  • Scalability: Less than 5 seconds and approximately 17 MB are reported for a payment with 10 intermediate users.Sphinx padding makes forwarded messages the same size at every intermediate user.
  • Non-blocking payments (Rayo): Rayo adds cur and Q data structures for in-flight and queued payments, imposing fairly small computation overhead.Its performance evaluation otherwise carries over from Fulgor because the protocol definitions are similar.

7 Related Work

Prior work addresses payment channels, privacy, and collateral cost, but the paper identifies unresolved challenges for generic multi-hop PCNs. Fulgor and Rayo combine privacy, Bitcoin compatibility, and concurrency guarantees in this setting.

  • Payment channels: Earlier payment-channel extensions primarily focus on single channels, leaving their extension to PCNs as an open challenge.Bidirectional channels and trusted-platform approaches are examples of this line of work.
  • Privacy-preserving payments: TumbleBit and Bolt provide privacy properties for off-chain path payments but are restricted to single-hop payments.The paper contrasts these limitations with its treatment of generic multi-hop PCNs.
  • Payment-channel networks: Lightning Network, Thunder, Eclair, and Raiden use HTLCs that leak a common identifier and lack a non-blocking solution for concurrent payments.Fulgor and Rayo are presented as addressing these limitations.
  • Credit networks: Credit-network protocols provide privacy definitions and privacy-preserving constructions, but PCNs additionally require accountability against an underlying blockchain.That requirement restricts the cryptographic operations available for PCN design.
  • Collateral cost: Miller et al. study collateral cost with blocking concurrency and Ethereum-compatible contracts, rather than privacy, non-blocking progress, or Bitcoin scripting compatibility.Their focus is reducing the time funds remain locked at intermediate channels.
  • Zero-knowledge HTLCs: Towns’s zk-SNARK-based HTLC variation addresses path linkability but was considered inefficient; this work revisits the idea using a formal protocol and ZK-Boo.The paper reports an efficient instantiation with provable security.

8 Conclusion

The work establishes formal foundations for privacy and concurrency in PCNs and presents formally proven protocols offering a tradeoff between non-blocking progress and anonymity. Evaluation indicates that Fulgor and Rayo are feasible to deploy and can scale.

  • The paper formally defines two PCN operation modes based on how concurrent payments are handled: blocking and non-blocking.
  • Fulgor and Rayo provide formally proven instantiations for the two modes, trading off non-blocking progress against anonymity.
  • Evaluation results demonstrate that deploying Fulgor and Rayo in practice is feasible and that the protocols can scale.

A Security Analysis

The security analysis describes simulator-based proofs for PCN operations, including channel opening, closing, and payment execution involving senders, receivers, and intermediate users. It argues that the simulation is efficient and statistically or computationally indistinguishable from the real execution, with negligible abort probability.

  • The simulator handles corrupted users by simulating real-world execution while interacting with the ideal functionality, spawning honest users until corruption occurs.
  • The simulation uses secure channels for honest-to-honest communication and lazy-samples the random oracle without exposing additional information beyond communication occurrence.
  • Channel opening and closing are simulated through ideal-functionality requests and two-user agreement protocols, with channel state initialized and retrieved from stored records.
  • The proof models sender, receiver, and intermediate-user payment cases separately, checking payment conditions and updating channel records when payments confirm.
  • The indistinguishability argument relies on statistically close real and simulated distributions, with analogous reasoning for receiver and intermediate-user simulations.
  • The simulator's abort probability is negligible because sender aborts are ruled out and intermediate-user aborts require finding a fresh hash pre-image.
  • For the non-blocking solution, the ideal functionality leaks payment identifiers to intermediate users, requiring consistent identifiers and simulated payment queueing.

B Agreement between Two Users

The agreement protocol lets two users deterministically reconcile concurrent channel events and update their shared channel state consistently. Its correctness follows because both users sort and apply the same events in the same order.

  • Two users sharing a channel run an agreement protocol to reach agreement on channel state at each point in time.
  • The protocol assumes a total order on events and users, with blocking state represented by capacity and non-blocking state by current payments, a queue, and capacity.
  • In the first round, users exchange event sets and deterministically sort the aggregate using user identifiers, event types, and payment identifiers.
  • Before the second round, each user applies events through a deterministic function that produces forwarding instructions, which are then exchanged with the corresponding users.
  • Lemma 3 states that 2ProcCons ensures channel-state agreement given the event set.
  • Correctness follows because deterministic sorting and deterministic state updates lead both users to the same channel state and forwarding tuples.

C Ideal World Functionality for Non-Blocking Payments

The non-blocking ideal-world functionality extends the blocking functionality to handle concurrent payments without blocking progress. It tracks where payments are queued and models unidirectional channels for simplicity.

  • The functionality models concurrent payments in a non-blocking manner and identifies changes relative to the blocking ideal-world functionality.
  • A queued variable tracks where payments are in the non-blocking functionality.
  • The model considers unidirectional channels and initializes the functionality with empty locally stored lists.

D Proof for Concurrency Lemmas

The proofs show that concurrent PCN payments can conflict at shared channels and that non-blocking, disjoint-access implementations cannot preserve strict serializability. In particular, Byzantine behavior can make both payments appear successful despite insufficient shared capacity, while cyclic concurrent payments can leave only partial channel updates.

  • The ideal functionality models channel opening by recording initial capacity and a hidden value after the counterparty authorizes the operation.It validates channel identifiers, rejects duplicates, appends the channel state, and returns a random h to both users.
  • Channel closing updates the recorded balance only when the channel and timing checks succeed, then marks the channel closed and notifies both users.The functionality parses the opening and latest balance records, aborts on invalid conditions, and appends the final balance.
  • A shared Alice–Bob channel with capacity for one payment prevents both concurrent payments from being successfully executed in a serializable PCN.If Alice and Bob are Byzantine, they can report incorrect capacities and allow both payments to appear successful, contradicting the sequential specification.
  • In a cyclic network, two concurrent multi-channel payments can reach executions indistinguishable from executions where either payment alone succeeds.Disjoint-access parallelism supports indistinguishability for the corresponding executions, including the case where the second payment is successful.
  • Those executions violate all-or-nothing semantics because only a proper subset of a payment’s channels has its capacity decreased.This partial update cannot match a strictly serializable sequential execution, yielding the contradiction used in the proof.
Loading 1911.09148v1…