Concurrency and Privacy with Payment-Channel Networks∗

Giulio Malavolta†

Friedrich-Alexander-University Erlangen-Nurnbergmalavolta@cs.fau.de

Pedro Moreno-Sanchez†

Purdue Universitypmorenos@purdue.edu

Aniket KatePurdue Universityaniket@purdue.edu

Matteo MaffeiTU Wien

matteo.maffei@tuwien.ac.at

Srivatsan RaviUniversity of Southern California

srivatsr@usc.edu

Abstract

Permissionless blockchains protocols such as Bitcoin are inherently limited in transaction throughputand latency. Current efforts to address this key issue focus on off-chain payment channels that can becombined in a Payment-Channel Network (PCN) to enable an unlimited number of payments withoutrequiring 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 inpractice raises several privacy concerns as well as technical challenges related to the inherently concurrentnature of payments that have not been sufficiently studied so far.

In this work, we lay the foundations for privacy and concurrency in PCNs, presenting a formal definitionin 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 provableprivacy guarantees for PCNs and is fully compatible with the Bitcoin scripting system. However, Fulgoris a blocking protocol and therefore prone to deadlocks of concurrent payments as in currently availablePCNs. Instead, Rayo is the first protocol for PCNs that enforces non-blocking progress (i.e., at least oneof the concurrent payments terminates). We show through a new impossibility result that non-blockingprogress necessarily comes at the cost of weaker privacy. At the core of Fulgor and Rayo is Multi-HopHTLC, a new smart contract, compatible with the Bitcoin scripting system, that provides conditionalpayments while reducing running time and communication overhead with respect to previous approaches.Our performance evaluation of Fulgor and Rayo shows that a payment with 10 intermediate users takesas few as 5 seconds, thereby demonstrating their feasibility to be deployed in practice.

1 Introduction

Bitcoin [57] is a fully decentralized digital cryp-tocurrency network that is widely adopted todayas an alternative monetary payment system. In-stead of accounting payments in a ledger locallymaintained by a trusted financial institute, these arelogged in the Bitcoin blockchain, a database repli-cated among mutually distrusted users around theworld who update it by means of a global consensusalgorithm based on proof-of-work. Nevertheless, thepermissionless nature of this consensus algorithm

∗This is the revision 6 September 2017. The most recentversion is available at https://eprint.iacr.org/2017/820†Both authors contributed equally and are considered to

be co-first authors.

limits the transaction rate to tens of transactionsper second whereas other payment networks suchas Visa support peaks of up to 47,000 transactionsper second [18].

In the forethought of a growing number of Bitcoinusers and most importantly payments about them,scalability is considered today an important concernamong the Bitcoin community [67, 3]. Several re-search and industry efforts are dedicated today toovercome this important burden [3, 62, 60, 32, 4, 2].

The use of Bitcoin payment channels [6, 32] to re-alize off-chain payments has flourished as a promis-ing approach to overcome the Bitcoin scalabilityissue. In a nutshell, a pair of users open a pay-ment channel by adding a single transaction to theblockchain where they lock their bitcoins in a de-

1

posit secured by a Bitcoin smart contract. Severaloff-chain payments can be then performed by locallyagreeing on the new distribution of the deposit bal-ance. Finally, the users sharing the payment chan-nel perform another Bitcoin transaction to add thefinal balances in the blockchain, effectively closingthe payment channel.

In this manner, the blockchain is required to openand close a payment channel but not for any of the(possibly many) payments between users, therebyreducing the load on the blockchain and improvingthe transaction throughput. However, this simpleapproach is limited to direct payments between twousers sharing an open channel. Interestingly, it is inprinciple possible to leverage a path of opened pay-ment channels from the sender to the receiver withenough capacity to settle their payments, effectivelycreating a payment-channel network (PCN) [60].

Many challenges must be overcome so that sucha PCN caters a wide deployment with a growingnumber of users and payments. In particular, to-day we know from similar payment systems such ascredit networks [36, 37, 15, 17] that a fully-fledgedPCN must offer a solution to several issues, suchas liquidity [29, 55], network formation [30], rout-ing scalability [61, 71], concurrency [49], and pri-vacy [56, 54, 49] among others.

The Bitcoin community has started to identifythese challenges [47, 41, 40, 48, 43, 22, 3, 67]. Nev-ertheless, current PCNs are still immature and thesechallenges require to be thoroughly studied. In thiswork, we lay the foundations for privacy and con-currency in PCNs. Interestingly, we show that thesetwo properties are connected to each other and thatthere exists an inherent trade-off between them.

The Privacy Challenge. It seems that pay-ment channels necessarily improve the privacy ofBitcoin payments as they are no longer logged inthe blockchain. However, such pervading idea hasstarted to be questioned by the community and itis not clear at this point whether a PCN can of-fer sufficient privacy guarantees [68, 22, 43]. Recentresearch works [47, 41, 40] propose privacy preserv-ing protocols for payment hub networks, where allusers perform off-chain payments through a uniqueintermediary. Unfortunately, it is not clear how toextend these solutions to multi-hop PCNs.

Currently, there exist some efforts in order to de-fine a fully-fledged PCN [19, 60, 13, 10]. Among

them, the Lightning Network [60] has emerged asthe most prominent PCN among the Bitcoin com-munity [1]. However, its current operations do notprovide all the privacy guarantees of interest in aPCN. For instance, the computation of the max-imum possible value to be routed through a pay-ment path requires that intermediate users revealthe current capacity of their payment channels tothe sender [62, Section 3.6], thereby leaking sensi-tive information. Additionally, the Bitcoin smart-contract used in the Lightning Network to enforceatomicity of updates for payment channels includedin the payment path, requires to reveal a commonhash value among each user in the path that can beused by intermediate users to derive who is payingto whom [60]. As a matter of fact, while a plethoraof academic papers have studied the privacy guar-antees offered by current Bitcoin payments on theBitcoin blockchain [52, 25, 66, 45, 64, 21, 51], thereexists at present no rigorous analysis of the pri-vacy guarantees offered by or desirable in PCNs.The lack of rigorous definitions for their protocols,threat model and privacy notions, hinders a formalsecurity and privacy analysis of ongoing attempts,let alone the development of provably secure andprivacy-preserving solutions.

The Concurrency Challenge. The consensusalgorithm, e.g., proof-of work in Bitcoin, eases theserialization of concurrent on-chain payments. Aminer with access to all concurrent payments at agiven time can easily serialize them following a setof predefined rules (e.g., sort them by payment fee)before they are added to the blockchain. However,this is no longer the case in a PCN: The bulk of off-chain payments are not added to the blockchain andthey cannot be serialized during consensus. More-over, individual users cannot avoid concurrency is-sues easily either as a payment might involve severalother users apart from payer and payee.

In current PCNs such as the Lightning Network,a payment is aborted as soon as a payment channelin the path does not have enough capacity (possi-bly allocated for another in-flight payment concur-rently). This, however, leads to deadlock (and star-vation) situations where none of the in-flight pay-ments terminates. In summary, although concur-rent payments are likely to happen when currentPCNs scale to a large number of users and off-chainpayments, the inherent concurrency issues have not

2

been thoroughly investigated yet.

Our Contribution. This work makes the follow-ing contributions:

First, we formalize for the first time the securityand privacy notions of interest for a PCN, namelybalance security, value privacy and sender/receiveranonymity, following the universal composability(UC) framework [27].

Second, we study for the first time the concur-rency issues in PCNs and present two protocols Ful-gor and Rayo that tackle this issue with differentstrategies. Fulgor is a blocking protocol in line withconcurrency solutions proposed in somewhat similarpayment networks such as credit networks [49, 15]that can lead to deadlocks where none of the concur-rent payments go through. Overcoming this chal-lenge, Rayo is the first protocol for PCNs guaran-teeing non-blocking progress [42, 20]. In doing so,Rayo ensures that at least one of the concurrentpayments terminates.

Third, we characterize an arguably surprisingtradeoff between privacy and concurrency in PCNs.In particular, we demonstrate that any PCN thatenforces non-blocking progress inevitably reducesthe anonymity set for sender and receiver of a pay-ment, thereby weakening the privacy guarantees.

Fourth, we formally describe the Multi-Hop HashTime-Lock Contract (Multi-Hop HTLC), a smartcontract that lies at the core of Fulgor and Rayoand which, in contrast to the Lightning Network,ensures privacy properties even against users in thepayment path from payer to payee. We formallydefine the Multi-Hop HTLC contract and providean efficient instantiation based on the recently pro-posed zero-knowledge proof system ZK-Boo [38],that improves on previous proposals [69] by reduc-ing the data required from 650 MB to 17 MB, therunning time for the prover from 600 ms to 309 msand the running time for verifying from 500 ms to130 ms. Moreover, Multi-Hop HTLC does not re-quire changes to the current Bitcoin scripting sys-tem, can thereby be seamlessly deployed in currentPCNs, and is thus of independent interest.

Finally, we have implemented a prototype of Ful-gor and Rayo in Python and evaluated the runningtime and communication cost to perform a pay-ment. Our results show that a privacy-preservingpayment in a path with 10 intermediate users canbe carried out in as few as 5 seconds and incurs

on 17 MB of communication overhead. This showsthat our protocols for PCN are in line with withother privacy-preserving payment systems [54, 49].Additionally, our evaluation shows that Fulgor andRayo can scale to cater a growing number of userswith a reasonably small overhead that can be fur-ther reduced with an optimized implementation.

Organization. Section 2 overviews the requiredbackground. Section 3 defines the problem wetackle in this work and overviews Fulgor and Rayo,our privacy preserving solution for PCNs. Section 4details the Fulgor protocol. Section 5 describes ourstudy of concurrency in PCNs and details the Rayoprotocol. Section 6 describes our implementationand the evaluation results. Section 7 discusses therelated work and Section 8 concludes this paper.

2 Background

In this section, we first overview the notion ofpayment channels and we then describe payment-channel networks.

2.1 Payment Channels

A payment channel enables several Bitcoin pay-ments between two users without committing ev-ery single payment to the Bitcoin blockchain. Thecornerstone of payment channels is depositing bit-coins into a multi-signature address controlled byboth users and having the guarantee that all bit-coins are refunded at a mutually agreed time if thechannel expires. In the following, we overview thebasics of payment channels and we refer the readerto [60, 32, 50] for further details.

In the illustrative example depicted in Figure 1,Alice opens a payment channel with Bob with aninitial capacity of 5 bitcoins. This opening trans-action makes sure that Alice gets the money backafter a certain timeout if the payment channel is notused. Now, Alice can pay off-chain to Bob by ad-justing the balance of the deposit in favor of Bob.Each off-chain payment augments the balance forBob and reduces it for Alice. When no more off-chain payments are needed (or the capacity of thepayment channel is exhausted), the payment chan-nel is closed with a closing transaction includedin the blockchain. This transaction sends the de-posited bitcoins to each user according the most re-cent balance in the payment channel.

3

Figure 1: Illustrative example of payment chan-nel. White solid boxes denote Bitcoin addresses andtheir current balance, dashed boxes represent Bitcointransactions, the clock denotes a time lock contract [7],a user name along a tick denotes her signature to vali-date the transaction and colored boxes denote the stateof the payment channel. Dashed arrows denote tempo-ral sequence. Alice first deposits 5 bitcoins opening apayment channel with Bob, then uses it to pay Bob off-chain. Finally, the payment channel is closed with themost recent balance.

The payment channel depicted in Figure 1 is anexample of unidirectional channel: it can be usedonly for payments from Alice to Bob. Bidirectionalchannels are defined to overcome this limitation asoff-chain payments in both directions are possible.Bidirectional payment channels operate in essenceas the unidirectional version.1 The major techni-cal challenge consists in changing the direction ofthe channel. In the running example, assume thatthe current payment channel balance bal is {Alice:4, Bob: 1} and further assume that Bob pays off-chain one bitcoin back to Alice. The new paymentchannel balance bal′ is {Alice: 5, Bob: 0}. At thispoint, Alice benefits from bal′ balance while Bobbenefits from bal. The solution to this discrepancyconsists on that Bob and Alice make sure that anyprevious balance has been invalidated in favor ofthe most recent one. Different “invalidation” tech-niques have been proposed and we refer the readerto [60, 32, 65] for details.

The Bitcoin protocol has been updated recentlyto fully support payment channels. In particular,transaction malleability [8], along with a set of otherinteresting new features, have been added to theBitcoin protocol with the recent adoption of Segre-

1Technically, a bidirectional channel might require thatboth users contribute funds to the deposit in the openingtransaction. However, current proposals [39] allow bidirec-tional channels with single deposit funder.

Figure 2: Illustrative example of a payment in aPCN. Non-bold (bold) numbers represent the capacityof the channels before (after) the payment from Alice toBob. Alice wants to pay 2 bitcoins to Bob via Carol,Edward and Fabi. Therefore, she starts the paymentwith 3 bitcoins (i.e., payment amount plus fees).

gated Witness [16]. This event paves the way to theimplementation and testing of PCNs on the mainBitcoin blockchain as of today [70].

2.2 A Payment Channel Network (PCN)

A PCN can be represented as a directed graphG = (V,E), where the set V of vertices repre-sents the Bitcoin accounts and the set E of weightededges represents the payment channels. Every ver-tex u ∈ V has associated a non-negative numberthat denotes the fee it charges for forwarding pay-ments. The weight on a directed edge (u1, u2) ∈ Edenotes the amount of remaining bitcoins that u1can pay to u2. For ease of explanation, in the restof the paper we represent a bidirectional channel be-tween u1 and u2 as two directed edges, one in eachdirection.2 Such a network can be used then to per-form off-chain payments between two users that donot have an open channel between them but areconnected by a path of open payment channels.

The success of a payment between two users de-pends on the capacity available along a path con-necting the two users and the fees charged by theusers in such path. Assume that s wants to pay αbitcoins to r and that they are connected througha path s → u1 → . . . → un → r. For their pay-ment to be successful, every link must have a ca-

2In practice, there is a subtle difference: In a bidirectionalchannel between Alice and Bob, Bob can always return toAlice the bitcoins that she has already paid to him. However,if two unidirectional channels are used, Bob is limited to payto Alice the capacity of the edge Bob → Alice, independentlyof the bitcoins that he has received from Alice. Nevertheless,our simplification greatly ease the understanding of the restof the paper and proposed algorithms can be easily extendedto support bidirectional channels.

4

pacity γi ≥ α′i, where α′i = α −∑i−1

j=1 fee(uj) (i.e.,the initial payment value minus the fees charged byintermediate users in the path). At the end of asuccessful payment, every edge in the path from sto r is decreased by α′i. To ensure that r receivesexactly α bitcoins, s must start the payment witha value α∗ = α+

∑nj=1 fee(uj).

In the illustrative example of payment shownin Figure 2, assume that Alice wants to pay Bob2 bitcoins. For that she needs to start a paymentfor a value of 3 bitcoins (2 bitcoins plus 1 bitcoinfor the fees charged by users in the path). Then thepayment is settled as follows: capacity in the linkAlice → Carol is reduced by 3. Additionally, Carolcharges a fee if 0.25 bitcoins by reducing the capac-ity of the link Carol → Edward by 2.75 instead of3 bitcoins. Following the same reasoning, the linkEdward → Fabi is set to capacity 3.75 and the linkFabi → Bob is set to 5.

2.3 State-of-the-Art PCNs

The concepts of payment channels [41, 47, 32] andPCNs [50] have already attracted attention from theresearch community. In practice, there exist severalongoing implementations for a PCN in Bitcoin [11,12, 10, 19]. Among them, the Lightning Networkhas emerged as the most prominent example in theBitcoin community and an alpha implementationhas been released recently [1]. The idea of a PCNhas been proposed to improve scalability issues notonly in Bitcoin, but also in other blockchain-basedpayment systems such as Ethereum [13].

2.3.1 Routing in PCNs

An important task in PCNs is to find paths withenough capacity between sender and receiver. Inour setting, the network topology is known to ev-ery user. This is the case since the opening of eachpayment channel is logged in the publicly availableblockchain. Additionally, a gossip protocol betweenusers can be carried out to broadcast the existenceof any payment channel [62]. Furthermore, the feescharged by every user can be made public by similarmeans. Under these conditions, the sender can lo-cally calculate the paths between the sender and thereceiver. In the rest of the paper, we assume thatthe sender chooses the path according to her owncriteria. Nevertheless, we consider path selection as

an interesting but orthogonal problem.

2.3.2 Payments in PCNs

A payment along a path of payment channels iscarried out by updating the capacity of each pay-ment channel in the path according to the paymentamount and the associated fees (see Section 2.2).Such an operation rises the important challenge ofatomicity : either the capacity of all channels in thepath is updated or none of the channels is changed.Allowing changes in only some of the channels inthe path can lead to the loss of bitcoins for a user(e.g., a user could pay certain bitcoins to the nextuser in the path but never receive the correspondingbitcoins from the previous neighbor).

The current proposal in the Lightning Networkconsists of a smart contract called Hash Time-LockContract (HTLC) [60]. This contract locks x bit-coins that can be released only if the contract isfulfilled. The contract is defined, in terms of a hashvalue y := H(R) where R is chosen uniformly atrandom, the amount of bitcoins x and a timeout t,as follows:

HTLC (Alice, Bob, y, x, t):1. If Bob produces the condition R∗ such thatH(R∗) = y before t days,3Alice pays Bob xbitcoins.2. If t days elapse, Alice gets back x bitcoins.

An illustrative example of the use of HTLC in apayment is depicted in Figure 3. For simplicity, we

3We use days here as in the original description [60]. In-stead, recent proposals use the sequence numbers of blocksas they appear in the Bitcoin blockchain [35].

Figure 3: Illustrative example of a payment fromAlice to Fabi for value 1 using HTLC contract.First, the condition is sent from Fabi to Alice. Thecondition is then forwarded among users in the path tohold 1 bitcoin at each payment channel. Finally, thereceiver shows R, releasing the held bitcoin at each pay-ment channel. For simplicity, we assume that there areno payment fees in this example.

5

assume that there are not payment fees in this ex-ample. First, the payment amount (i.e., 1 bitcoin)is set on hold from the sender to the receiver andthen released from the receiver to the sender. In abit more detail, after the receiver (Fabi) sends thecondition to the sender (Alice), Alice sets an HTLCwith her neighbor, effectively setting the paymentvalue (i.e., 1 bitcoin) on hold. Such HTLC is thenset at each payment channel in the path to the re-ceiver. At this point, the receiver knows that thepayment value is on hold at each payment channeland thus she reveals the value R, that allows her tofulfill the contract and to settle the new capacity ateach payment channel in the path.

It is important to note that every user in the pathsets the HTLC in the outgoing payment channelwith a timeout smaller than the HTLC in the in-coming payment channel. In this manner, the usermakes sure that she can pull bitcoins from her pre-decessor after her bitcoins have been pulled from hersuccessor. An offline user can outsource the moni-toring of fulfillments corresponding to open HTLCcontracts associated to her payment channels [33].

Although HTLC is fully compatible with Bitcoin,its use in practice leads to important privacy leaks:It is easy to see that the value of the hash H(R)uniquely identifies the users that took part in aspecific transaction. This fact has two main im-plications. First, any two colluding users in a pathcan trivially derive the fact that they took part inthe same payment and this can be leveraged to re-construct the identity of sender and receiver.4 Sec-ond, if the HTLC statements are uploaded to theblockchain (e.g., due to uncollaborative intermedi-ate users in the payment path), an observer can eas-ily track the complete path used to route the pay-ment, even if she is not part of the payment. In thiswork, we propose a novel Multi-Hop HTLC smartcontract that avoids this privacy problem while en-suring that no intermediate user loses her bitcoins.

An important issue largely understudied in cur-rent PCNs is the handling of concurrent paymentsthat require a shared payment channel in theirpaths. Current proposals simply abort a paymentif the balance at the shared payment channel in thepath is not enough. However, as we show in Sec-tion 3.3, this approach can lead to a deadlock sit-

4 As noted in [40], in a path A → I1 → I2 → I3 → B,only I1 and I3 must collude to recover the identities of A andB as all the contracts in the path share the same H(R).

uation where none of simultaneous payments ter-minates. We propose a payment protocol that en-sure non-blocking progress, that is, at least one ofthe concurrent payments terminates. Moreover, weshow an inherent tradeoff between concurrency andprivacy for any fully distributed payment network.

3 Problem Definition

In this section, we first formalize a PCN and un-derlying operations, and discuss the attacker modeland our security and privacy goals. We then de-scribe an ideal world functionality for our proposal,and present a system overview. Throughout the fol-lowing description we implicitly assume that everyalgorithm takes as input the blockchain, which ispublicly known to all users.

Definition 1 (Payment Channel Network (PCN)).A PCN is defined as graph G := (V,E), where V isthe set of Bitcoin accounts and E is the set of cur-rently open payment channels. A PCN is definedwith respect to a blockchain B and is equipped withthe three operations (openChannel, closeChannel,pay) described below:

• openChannel(u1, u2, β, t, f) → {1, 0}. On inputtwo Bitcoin addresses u1, u2 ∈ V, an initial channelcapacity β, a timeout t, and a fee value f , if the op-eration is authorized by u1, and u1 owns at least βbitcoins, openChannel creates a new payment chan-nel (c〈u1,u2〉, β, f, t) ∈ E, where c〈u1,u2〉 is a freshchannel identifier. Then it uploads it to B and re-turns 1. Otherwise, it returns 0.

• closeChannel(c〈u1,u2〉, v) → {1, 0}. On input achannel identifier c〈u1,u2〉 and a balance v (i.e., thedistribution of bitcoins locked in the channel betweenu1 and u2), if the operation is authorized by bothu1 and u2, closeChannel removes the correspondingchannel from G, includes the balance v in B andreturns 1. Otherwise, it returns 0.

• pay((c〈s,u1〉, . . . , c〈un,r〉), v) → {1, 0}. On inputa list of channel identifiers (c〈s,u1〉, . . . , c〈un,r〉) anda payment value v, if the payment channels forma path from the sender (s) to the receiver (r) andeach payment channel c〈ui,ui+1〉 in the path has atleast a current balance γi ≥ v′i, where v′i = v −∑i−1

j=1 fee(uj), the pay operation decreases the cur-rent balance for each payment channel c〈ui,ui+1〉 byv′i and returns 1. Otherwise, none of the balances

6

at the payment channels is modified and the pay op-eration returns 0.

3.1 Attacker Model, and Security andPrivacy Goals

We consider a computationally efficient attackerthat can shape the network at her will by spawningusers and corrupting an arbitrary subset of themin an adaptive fashion. Once a user is corrupted,its internal state is given to the attacker and allof the following messages for that user are handedover to the attacker. On the other hand, we as-sume that the communication between two non-compromised users sharing a payment channel isconfidential (e.g., through TLS). Finally, the at-tacker can send arbitrary messages on behalf of cor-rupted users.

Against the above adversary, we identify the fol-lowing security and privacy notions of interest:

• Balance security. Intuitively, balance secu-rity guarantees that any honest intermediate usertaking part in a pay operation (as specified in Def-inition 1) does not lose coins even when all otherusers involved in the pay operation are corrupted.

• Serializability. We require that the execu-tions of PCN are serializable [58], i.e., for every con-current execution of pay operations, there exists anequivalent sequential execution.

• (Off-path) Value Privacy. Intuitively, valueprivacy guarantees that for a pay operation involv-ing only honest users, corrupted users outside thepayment path learn no information about the pay-ment value.

• (On-path) Relationship Anonymity [59,24]. Relationship anonymity requires that, giventwo simultaneous successful pay operations of theform

{payi((c〈si,u1〉, . . . , c〈un,ri〉), v)

}i∈[0,1] with at

least one honest intermediate user uj∈[1,n], cor-rupted intermediate users cannot determine the pair(si, ri) for a given payi with probability better than1/2.

3.2 Ideal World Functionality

Our Model. The users of the network are mod-eled as interactive Turing machines that communi-cate with a trusted functionality F via secure andauthenticated channels. We model the attacker Aas a probabilistic polynomial-time machine that is

given additional interfaces to add users to the sys-tem and corrupt them. A can query those interfacesadaptively and at any time. Upon corruption of auser u, the attacker is provided with the internalstate of u and the incoming and outgoing commu-nication of u is routed thorough A.

Assumptions. We model anonymous communi-cation between any two users of the network as anideal functionality Fanon, as proposed in [26]. Fur-thermore, we assume the existence of a blockchainB that we model as a trusted append-only bulletinboard (such as [72]): The corresponding ideal func-tionality FB maintains B locally and updates it ac-cording to the transactions between users. At anypoint in the execution, any user u of the PCN cansend a distinguished message read to FB, who sendsthe whole transcript of B to u. We denote the num-ber of entries of B by |B|. In our model, time cor-responds to the number of entries of the blockchainB, i.e., time t is whenever |B| = t. Our idealizedprocess F uses Fanon and FB as subroutines, i.e.,our protocol is specified in the (Fanon,FB)-hybridmodel. Note that our model for a blockchain is acoarse grained abstraction of the reality and thatmore accurate formalizations are known in the lit-erature, see [44]. For ease of exposition we stick tothis simplistic view, but one can easily extend ourmodel to incorporate more sophisticated abstrac-tions.

Notation. Payment channels in the BlockchainB are of the form (c〈u,u′〉, v, t, f), where c〈u,u′〉 is aunique channel identifier, v is the capacity of thechannel, t is the expiration time of the channel,and f is the associated fee. For ease of notationwe assume that the identifiers of the users (u, u′)are also encoded in c〈u,u′〉. We stress that any twousers may have multiple channels open simultane-ously. The functionality maintains two additionalinternal lists C and L. The former is used to keeptrack of the closed channels, while the latter recordsthe off-chain payments. Entries in L are of theform (c〈u,u′〉, v, t, h), where c〈u,u′〉 is the correspond-ing channel, v is the amount of credit used, t is theexpiration time of the payment, and h is the iden-tifier for this entry.

Operations. In Figure 4 we describe the inter-actions between F and the users of the PCN. Forsimplicity, we only model unidirectional channels,although our functionality can be easily extended to

7

Open channel: On input (open, c〈u,u′〉, v, u′, t, f) from a user u, the F checks whether c〈u,u′〉 is

well-formed (contains valid identifiers and it is not a duplicate) and eventually sends (c〈u,u′〉, v, t, f)to u′, who can either abort or authorize the operation. In the latter case, F appends the tuple(c〈u,u′〉, v, t, f) to B and the tuple (c〈u,u′〉, v, t, h) to L, for some random h. F returns h to u and u′.

Close channel: On input (close, c〈u,u′〉, h) from a user ∈ {u′, u} the ideal functionality F parses Bfor an entry (c〈u,u′〉, v, t, f) and L for an entry (c〈u,u′〉, v

′, t′, h), for h 6= ⊥. If c〈u,u′〉 ∈ C or t > |B| ort′ > |B| the functionality aborts. Otherwise, F adds the entry (c〈u,u′〉, u

′, v′, t′) to B and adds c〈u,u′〉to C. F then notifies both users involved with a message (c〈u,u′〉,⊥, h).

Payment: On input (pay, v, (c〈u0,u1〉, . . . , c〈un,un+1〉), (t0, . . . , tn)) from a user u0, F executes thefollowing interactive protocol:

1. For all i ∈ {1, . . . , (n + 1)} F samples a random hi and parses B for an entry of the form(c〈ui−1,u′i〉, vi, t

′i, fi). If such an entry does exist F sends the tuple (hi, hi+1, c〈ui−1,ui〉, c〈ui,ui+1〉, v−∑n

j=i fj , ti−1, ti) to the user ui via an anonymous channel (for the specific case of the receiverthe tuple is only (hn+1, c〈un,un+1〉, v, tn)). Then F checks whether for all entries of the form

(c〈ui−1,ui〉, v′i, ·, ·) ∈ L it holds that v′i ≥

(v−

∑nj=i fj

)and that ti−1 ≥ ti. If this is the case F

adds di = (c〈ui−1,ui〉, (v′i − (v −

∑nj=i fj)), ti,⊥) to L, where (c〈ui−1,ui〉, v

′i, ·, ·) ∈ L is the entry

with the lowest v′i. If any of the conditions above is not met, F removes from L all the entriesdi added in this phase and aborts.

2. For all i ∈ {(n+1), . . . , 1} F queries all ui with (hi, hi+1), through an anonymous channel. Eachuser can reply with either > or ⊥. Let j be the index of the user that returns ⊥ such that forall i > j : ui returned >. If no user returned ⊥ we set j = 0.

3. For all i ∈ {j + 1, . . . , n} the ideal functionality F updates di ∈ L (defined as above) to(−,−,−, hi) and notifies the user of the success of the operation with with some distinguishedmessage (success, hi, hi+1). For all i ∈ {0, . . . , j} (if j 6= 0) F removes di from L and notifies theuser with the message (⊥, hi, hi+1).

Figure 4: Ideal world functionality for PCNs.

support also bidirectional channels. The executionof our simulation starts with F initializing a pair oflocal empty lists (L, C). Users of a PCN can query Fto open channels and close them to any valid state inL. On input a value v and a set of payment channels(c〈u0,u1〉, . . . , c〈un,un+1〉) from some user u0, F checkswhether the path has enough capacity (step 1) andinitiates the payment. Each intermediate user caneither allow the payment or deny it. Once the pay-ment has reached the receiver, each user can againdecide to interrupt the flow of the payment (step 2),i.e., pay instead of the sender. Finally F informsthe involved nodes of the success of the operation(step 3) and adds the updated state to L for thecorresponding channels.

Discussion. Here, we show that our ideal func-tionality captures the security and privacy proper-

ties of interest for a PCN.

• Balance security. Let ui be any intermediatehop in a payment pay((c〈s,u1〉, . . . , c〈un,r〉), v). F lo-cally updates in L the channels corresponding to theincoming and outgoing edges of ui such that the to-tal balance of ui is increased by the coins she setsas a fee, unless the user actively prevents it (step2). Since F is trusted, balance security follows.

• Serializability. Consider for the moment onlysingle-hop payments. It is easy to see that the idealfunctionality executes them serially, i.e., any twoconcurrent payments can only happen on differentlinks. Therefore one can trivially find a schedulerthat performs the same operation in a serial order(i.e., in any order). By balance security, any pay-ment can be represented as a set of atomic single-hop payments and thus serializability holds.

8

• Value Privacy. In the ideal world, users thatdo not lie in the payment path are not contactedby F and therefore they learn nothing about thetransacted value (for the off-chain payments).

• Relationship Anonymity. Let ui be an interme-diate hop in a payment. In the interaction with theideal functionality, ui is only provided with a uniqueidentifier for each payment. In particular, such anidentifier is completely independent from the iden-tifiers of other users involved in the same payment.It follows that, as long as at least one honest user uilies in a payment path, any two simultaneous pay-ments over the same path for the same value v areindistinguishable to the eyes of the user ui+1. Thisimplies that any proper subset of corrupted interme-diate hops, for any two successful concurrent pay-ments traversing all of the corrupted nodes, cannotdistinguish in which order an honest ui forwardedthe payments. Therefore such a set of corruptednodes cannot determine the correct sender-receiverpair with probability better than 1/2.

UC-Security. Let EXECτ,A,E be the ensemble ofthe outputs of the environment E when interactingwith the adversary A and parties running the pro-tocol τ (over the random coins of all the involvedmachines).

Definition 2 (UC-Security). A protocol τ UC-realizes an ideal functionality F if for any adversaryA there exists a simulator S such that for any envi-ronment E the ensembles EXECτ,A,E and EXECF ,S,Eare computationally indistinguishable.

Lower bound on byzantine users in PCN. Weobserve that in PCNs that contain channels in whichboth the users are byzantine (a la malicious) [46],there is an inherent cost to concurrency. Specif-ically, in such a PCN, if we are providing non-blocking progress, i.e., at least one of the concur-rent payments terminates, then it is impossible toprovide serializability in PCNs (cf. Figure 11 in Ap-pendix D). Thus, henceforth, all results and claimsin this paper assume that in any PCN execution,there does not exist a channel in which both itsusers are byzantine.

Lemma 1. There does not exist any serializableprotocol for the PCN problem that provides non-blocking progress if there exists a payment channelin which both users are byzantine.

3.3 Key Ideas and System Overview

In the following, we give a high-level overview onhow we achieve private and concurrent payments inPCNs.

3.3.1 Payment Privacy

The payment operation must ensure the securityand privacy properties of interest in a PCN, namelybalance security, value privacy and relationshipanonymity. A naıve approach towards achievingbalance security would be to use HTLC-based pay-ments (see Section 2.3.2). This solution is howeverin inherent conflict with anonymity: It is easy tosee that contracts belonging to the same transac-tions are linkable among each other, since they en-code the same condition (h) to release the payment.Our proposal, called Multi-Hop HTLC, aims to re-move this link among hops while maintaining thefull compatibility with the Bitcoin network.

The idea underlying Multi-Hop HTLC is the fol-lowing: At the beginning of an n-hop transac-tion the sender samples n-many independent strings(x1, . . . , xn). Then, for all i ∈ 1, . . . , n, she sets

yi = H(⊕n

j=i xj

), where H is an arbitrary hash

function. That is, each yi is the result of apply-ing the function H to all of the input values xj forj ≥ i in an XOR combiner. The sender then pro-vides the receiver with (yn, xn) and the i-th nodewith the tuple (yi+1, yi, xi). In order to preserveanonymity, the sender communicates those valuesto the intermediate nodes over an anonymous chan-nel. Starting from the sender, each pair of neighbor-ing nodes (ui+1, ui) defines a standard HTLC on in-puts (ui, ui+1, yi, b, t), where b and t are the amountof bitcoin and the timeout parameter, respectively.Note that the release conditions of the contractsare uniformly distributed in the range of the func-tion H and therefore the HTLCs of a single trans-action are independent from each other. Clearly,the mechanism described above works fine as longas the sender chooses each value yi according to thespecification of the protocol. We can enforce anhonest behavior by including non-interactive zero-knowledge proofs [38].

3.3.2 Concurrent Payments

It is possible that two (or more) simultaneous pay-ments share a payment channel in their payment

9

Figure 5: Illustrative example of two blocking pay-ments: Alice to Gabriel (red) and Bob to Edward(blue). For simplicity, assume each payment pays 1 bit-coin and each payment channel has capacity 1 bitcoin.Each payment channel is colored with the payment thathas reached it first. In this deadlock situation, none ofthe payments can continue further in the path and can-not be trivially completed.

paths in such a manner that none of the paymentsgoes through. In the example depicted in Figure 5,the payment from Alice to Gabriel cannot be carriedout as the capacity in the payment channel betweenFabi and Gabriel is already locked for the paymentfrom Bob to Edward. Moreover, this second pay-ment cannot be carried out either as the capacity onthe payment channel between Carol and Edward isalready locked. This deadlock situation is a genericproblem of PCNs, where a payment is aborted assoon as there exists a payment channel in the pathwithout enough capacity.

Blocking Payments (Fulgor). A best-effort so-lution for avoiding this deadlock consists on lettingboth payments fail. Aborted payments do not af-fect the balance of the involved users as the re-ceiver would not disclose the release condition forthe locked payment channels. Therefore, involvedpayment channels would get unlocked only after thecorresponding timeout and bitcoins are sent back tothe original owner.

The sender of an aborted payment can then ran-domly choose a waiting period to reissue the pay-ment. Although the blocking mechanism closely re-sembles the practice of users in others payment net-works such as Ripple [14] or SilentWhispers [49], itmight degrade transaction throughput in a fully de-centralized PCN.

Non-blocking Payments (Rayo). An alter-native solution consists on a non-blocking solutionwhere at least one out of a set of concurrent pay-ments completes. Our approach to achieve it as-sumes that there exists a global ordering of pay-

ments (e.g., by a global payment identifier). Ina nutshell, users can queue payments with higheridentifier than the current one “in-flight”, and abortpayments with lower identifiers. This ensures thateither the current in-flight payment completes orone of the queued payments would do, as their iden-tifiers are higher.

4 Fulgor: Our Construction

In this section, we introduce the cryptographicbuilding blocks required for our construction (Sec-tion 4.1), we describe the details for the Multi-HopHTLC contract (Section 4.2), we detail the con-structions for PCN operations (Section 4.3), analyzeits security and privacy (Section 4.4) and concludewith a few remarks (Section 4.5).

Notation. We denote by λ the security param-eter of our system and we use the standard defini-tion for a negligible function. We denote by decisionthe possible events in a payment channel due to apayment. The decision forward signals to lock thebalance in the payment channel corresponding tothe payment value. The decision abort signals therelease of locked funds in the payment channel dueto the abortion of a payment. Correspondingly, thedecision accept signals the confirmation of a pay-ment accepted by the receiver.

For ease of notation, we assume that users iden-tifiers (ui, ui+1) can be extracted from the channelidentifier c〈ui,ui+1〉.

System Assumptions. We assume that everyuser in the PCN is aware of the complete networktopology, that is, the set of all users and the exis-tence of a payment channel between every pair ofusers. We further assume that the sender of a pay-ment chooses a payment path to the receiver ac-cording to her own criteria. The current value oneach payment channel is not published but insteadkept locally by the users sharing a payment channelas otherwise privacy is trivially broken. We furtherassume that every user is aware of the payment feescharged by each other user in the PCN.

This can be accomplished in practice. The open-ing of a payment channel between two users requiresto add a transaction in the blockchain that includesboth user identifiers. Therefore, the topology of thePCN is trivially leaked. Moreover, the transactionused to open a payment channel can contain user-

10

defined data [5] so that each user can embed herown payment fee. In this manner, each user canproactively gather updated information about thenetwork topology and fees from the blockchain it-self or be disseminated by a gossip protocol [62, 48].

We further assume that pairs of users sharinga payment channel communicate through secureand authenticated channels (such as TLS), which iseasy to implement given that every user is uniquelyidentified by a public key. Also we assume thatthe sender and the receiver of a (possibly indirect)transaction can communicate through a secure anddirect channel. Finally, we assume that the senderof a payment can create an anonymous paymentchannel with each intermediate user. The IP ad-dress where to reach each user could be encodedin the channel creation transaction and thereforelogged in the blockchain. We note that our pro-tocol is completely parametric with respect to therouting, therefore any onion routing-like techniqueswould work in this context.

We consider the bounded synchronous communi-cation setting [23]. In such communication model,time is divided into fixed communication roundsand it is assumed that all messages sent by a userin a round are available to the intended recipi-ent within a bounded number of steps in an exe-cution. Consequently, absence of a message indi-cates absence of communication from a user duringthe round. In practice, this can be achieved withloosely synchronized clocks among the users in thePCN [28].

Finally, we assume that there is a total orderamong the users (e.g., lexicographically sorted bytheir public verification keys).

4.1 Building Blocks

Non-Interactive Zero-Knowledge. Let R :{0, 1}∗ × {0, 1}∗ → {0, 1} be an NP relation, andlet L be the set of positive instances for R, i.e.,L = {x | ∃w s.t. R(x,w) = 1}. A non-interactivezero-knowledge proof for R consists of a single mes-sage from a prover P to a verifier V. The proverP wants to compute a proof π that convinces theverifier V that a certain statement x ∈ L. We allowthe prover to run on an extra private input w suchthat R(x,w) = 1. The verifier can either accept orreject, depending on π. A NIZK is complete if theV always accepts honestly computed π for a state-

ment x ∈ L and it is sound if V always rejects anyπ for all x 6∈ L, except with negligible probability.Loosely speaking, a NIZK proof is zero knowledge ifthe verifier learns nothing from π beyond the factthat x ∈ L. Efficient NIZK protocols are known toexist in the random oracle model [38].

Two Users Agreement. Two users ui and ujsharing a payment channel, locally maintain thestate of the payment channel defined as a scalarchannel-state := cap(c〈ui,uj〉) that denotes the cur-rent capacity of their payment channel. We requirea two party agreement protocol that ensures thatboth users agree on the current value of cap(c〈ui,uj〉)at each point in time. We describe the details ofsuch protocol in Appendix B. For readability, in therest we implicitly assume that two users sharing apayment channel satisfactorily agree on its currentstate.

4.2 Multi-Hop HTLC

We consider the standard scenario of an indirectpayment from a sender Sdr to a receiver Rvr for acertain value v through a path of users (u1, . . . , un),where un = Rvr. All users belonging to the samenetwork share the description of a hash functionH : {0, 1}∗ → {0, 1}λ that we model as a randomoracle.

Let L be the following language: L ={(H, y′, y, x) | ∃(w) s.t. y′ = H(w)∧y = H(w⊕x)}where w⊕x denotes the bitwise XOR of the two bit-strings. Before the payment starts, the sender Sdrlocally executes the following SetupHTLC algorithmdescribed in Figure 6.

SetupHTLC(n) :

∀i ∈ [n] :

xi ∈ {0, 1}λ; yi ← H

n⊕j=i

xj

∀i ∈ [n− 1] :

πi ← P

(H, yi+1, yi, xi),

n⊕j=i+1

xj

return ((x1, y1, π1), . . . , (xn, yn))

Figure 6: Setup operation for the Multi-Hop HTLC con-tract.

11

Intuitively, the sender samples n-many random

strings xi and defines yi as H(⊕n

j=i xj

)which is

the XOR combination of all xj such that j ≥ i.Then, Sdr computes the proofs π to guarantee thateach yi is well-formed, without revealing all of thexi. The receiver is provided with (xn, yn) and shesimply checks that yn = H(xn). Sdr then sends(xi, yi, πi) to each intermediate user ui, througha direct communication channel. Each ui runsV((H, yi+1, yi, xi), πi) and aborts the payment if theverification algorithm rejects the proof.

Starting from the user u0 = Sdr, each pair ofusers (ui, ui+1) check whether both users receivedthe same values of (yi+1, v). This can be done bysimply exchanging and comparing the two values.If this is the case, they establish HTLC (ui, ui+1,yi+1, v, ti) as described in Section 2.3, where tidefines some timespan such that for all i ∈ [n] :ti−1 = ti + ∆, for some positive value ∆. Oncethe contract between (un−1, un) is settled, the userun (the receiver) can then pull v bitcoins by releas-ing the xn, which by definition satisfies the con-straint H(xn) = yn. Once the value of xn is pub-lished, un−1 can also release a valid condition for thecontract between (un−2, un−1) by simply outputtingxn−1 ⊕ xn. In fact, this mechanism propagates forevery intermediate user of the payment path, un-til Sdr: For each node ui it holds that, wheneverthe condition for the contract between (ui, ui+1) isreleased, i.e., somebody publishes a string r suchthat H(r) = yi+1, then ui immediately learns xi⊕rsuch that H(xi⊕ r) = yi, which is a valid conditionfor the contract between (ui−1, ui). It follows thateach intermediate user whose outgoing contract hasbeen pulled is able to release a valid condition forthe incoming contract.

4.3 Construction Details

In the following, we describe the details of the threeoperations (openChannel, closeChannel, pay) thatcompose Fulgor.

• openChannel(u1, u2, β, t, f): The purpose ofthis operation is to open a payment channel be-tween users u1 and u2. For that, they create aninitial Bitcoin deposit that includes the followinginformation: their Bitcoin addresses, the initial ca-pacity of the channel (β), the channel timeout (t),the fee charged to use the channel (f) and a channelidentifier (c〈u1,u2〉) agreed beforehand between both

payu0(m) :

(Txid,{c〈u0,u1〉

}∪{c〈ui,ui+1〉

}i∈[n] , v)← m

v1 := v +

n∑i

fee(ui)

if v1 ≤ cap(c〈u0,u1〉) then

cap(c〈u0,u1〉) := cap(c〈u0,u1〉)− v1

t0 := tnow + ∆ · n∀i ∈ [n] :

vi := v1 −i−1∑j=1

fee(uj)

ti := ti−1 −∆

{(xi, yi, πi)}i∈[n+1] ← SetupHTLC(n+ 1)

Send(ui, ((Txid, xi, yi, yi+1,

πi, c〈ui−1,ui〉, c〈ui,ui+1〉, vi+1, ti, ti+1), forward))

HTLC(u0, u1, y1, v1, t1)

Send(un+1, (Txid, xn+1, yn+1, c〈un,un+1〉,

vn+1, tn+1))

else

abort

Figure 7: The pay routine in Fulgor for the sender. Thelight blue pseudocode shows additional steps required inRayo.

users. After the Bitcoin deposit has been success-fully added to the blockchain, the operation returns1. If any of the previous steps is not carried out asdefined, the operation returns 0.

• closeChannel(c〈u1,u2〉, v): This operation is usedby two users (u1, u2) sharing an open payment chan-nel (c〈u1,u2〉) to close it at the state defined by vand accordingly update their bitcoin balances inthe Bitcoin blockchain. This operation in Fulgoris performed as defined in the original proposal ofpayment channels (see Section 2.1), additionally re-turning 1 if and only if the corresponding Bitcointransaction is added to the Bitcoin blockchain.

• pay((c〈u0,u1〉, . . . , c〈un,un+1〉), v): A payment op-eration transfers a value v from a sender (u0) to a re-ceiver (un+1) through a path of open payment chan-nels between them (c〈u0,u1〉, . . . , c〈un,un+1〉). Here,we describe a blocking version of the payment oper-ation (see Section 3.3). We discuss the non-blockingversion of the payment operation in Section 5.

As shown in Figure 7 (black pseudocode), the

12

payun+1(m) :

(Txid, xn+1, yn+1, c〈n,n+1〉, vn+1, tn+1)← m

if H(xn+1) = yn+1 and tn+1 > tnow + ∆ then

store (xn+1, yn+1, c〈n,n+1〉, tn+1)

Send(un, ((Txid, xn+1, yn+1, c〈n,n+1〉), accept))

else

Send(un, ((Txid, yn+1, c〈n,n+1〉, vn+1), abort))

payui(m) :

(m∗, decision)← m

if decision = forward then

(Txid, xi, yi, yi+1, πi, c〈i−1,i〉, c〈i,i+1〉,

vi+1, ti, ti+1)← m∗

if vi+1 ≤ cap(c〈ui,ui+1〉) and V((H, yi+1, yi, xi), πi)

and ti+1 = ti −∆ then

cap(c〈ui,ui+1〉) := cap(c〈ui,ui+1〉)− vi+1

HTLC(ui, ui+1, yi+1, vi+1, ti+1)

cur(c〈ui,ui+1〉).append(m∗)

else if ∃k | Txid > cur(c〈ui,ui+1〉)[k].Txid then

Q(c〈ui,ui+1〉).append(m∗)

else

Send(ui−1, ((Txid, yi, c〈i−1,i〉, vi), abort))

else if decision = abort then

(Txid, yi+1, c〈i,i+1〉, vi+1)← m∗

cap(c〈ui,ui+1〉) := cap(c〈ui,ui+1〉) + vi+1

Send(ui−1, ((Txid, yi, c〈i−1,i〉, vi), abort))

cur(c〈ui,ui+1〉).delete(m∗.Txid)

m′ := max(Q(c〈ui,ui+1〉))

payui((m′, forward))

else if decision = accept then

(Txid, xi+1, yi+1, c〈i,i+1〉, vi+1)← m∗

store (xi+1 ⊕ xi, yi, c〈i−1,i〉, ti)Send(ui−1, ((Txid, xi+1 ⊕ xi, yi, c〈i−1,i〉, vi), accept))cur(c〈ui,ui+1〉).delete(m∗.Txid)

Figure 8: The pay routine in Fulgor for the receiver andeach intermediate user. The light blue pseudocode showsadditional steps in Rayo. max(Q) returns the informa-tion for the payment with highest identifier among thosein Q.

sender first calculates the cost of sending v bit-coins to Rvr as v1 := v +

∑i fee(ui), and the cor-

responding cost at each of the intermediate hopsin the payment path. If the sender does not haveenough bitcoins, she aborts the payment. Other-wise, the sender sets up the contract for each inter-mediate payment channel following the mechanismdescribed in Section 4.2 and sends the informationto the corresponding users.

Every intermediate user verifies that the incomingHTLC has an associated value smaller or equal thanthe capacity of the payment channel with her suces-sor in the path. Additionally, every intermediateuser verifies that the zero-knowledge proof associ-ated to the HTLC for incoming and outgoing pay-ment channels correctly verifies and that the time-out for the incoming HTLC is bigger than the time-out for the outgoing HTLC by a difference of ∆.If so, she generates the corresponding HTLC forthe same associate value (possibly minus the fees)with the successor user in the path; otherwise, sheaborts by triggering the abort event to the prede-cessor user in the path. These operations have beenshown in Figure 8 (black pseudocode).

If every user in the path accepts the payment, iteventually reaches the receiver who in turn releasesthe information required to fulfill the HTLC con-tracts in the path (see Figure 8 (black pseudocode)).Interestingly, if any intermediate user aborts thepayment, the receiver does not release the condi-tion as she does not receive any payment. More-over, payment channels already set in the previoushops of the path are voided after the timeout set inthe corresponding HTLC.

4.4 Security and Privacy Analysis

In the following, we state the security and privacyresults for Fulgor. We prove our results in the(Fanon,FB)-hybrid model. In other words, Theo-rem 1 holds for any UC-secure realization of Fanon

and FB. We show the proof of Theorem 1 in Ap-pendix A.

Theorem 1 (UC-Security). Let H : {0, 1}∗ →{0, 1}λ be a hash function modelled as a randomoracle, and let (P,V) a zero-knowledge proof sys-tem, then Fulgor UC-realizes the ideal functional-ity F defined in Figure 5 in the (Fanon,FB)-hybridmodel.

13

4.5 System Discussion

Compatibility with Bitcoin. We note that allof the non-standard cryptographic operations (suchas NIZK proofs) happen off-chain, while the only al-gorithm required to be executed in the verificationof the blockchain is the hash function H, which canbe instantiated with SHA-256. Therefore our Multi-Hop HTLC scheme and Fulgor as a whole is fullycompatible with the current Bitcoin script. More-over, as mentioned in Section 2.1, the addition ofSegWit or similar solution for the malleability is-sue in Bitcoin fully enables payment channels in theBitcoin system [70].

Generality. Fulgor is general to PCNs (and notonly tied to Bitcoin). Fulgor requires that: (i)openChannel allows to embed custom data (e.g.,fee); (ii) conditional updates of the balance in thepayment channel. As arbitrary data can be includedin cryptocurrency transactions [5] and most PCNssupport, among others, the HTLC contract, Fulgorcan be used in many other PCNs such as Raiden, aPCN for Ethereum [13].

Support for Bidirectional Channels. Fulgorcan be easily extended to support bidirectional pay-ment channels and only two minor changes are re-quired. First, the payment information must in-clude the direction requested at each payment chan-nel. Second, the capacity of a channel c〈uL,uR〉 is atuple of values (L,R, T ) where L denotes the cur-rent balance for uL, R is the current balance of uRand T is the total capacity of the channel. A pay-ment from left to right for value v is possible if L ≥ vand R + v ≤ T . In such case, the tuple is updatedto (L− v, R+ v, T ). A payment from right to left ishandled correspondingly.

5 Non-blocking Payments inPCNs

In this section, we discuss how to handle concur-rent payments in a non-blocking manner. In otherwords, how to guarantee that at least one paymentout of a set of concurrent payments terminates.

In the following, we start with an impossibility re-sult that dictates the design of Rayo, our protocolfor non-blocking payments. Then, we describe themodifications required in the ideal world functional-ity and Fulgor to achieve them. Finally, we discuss

the implications of these modifications in terms ofprivacy properties.

5.1 Concurrency vs Privacy

We show that achieving non-blocking progress re-quires a global state associated to each of thepayments. Specifically, we show that we can-not provide disjoint-access parallelism and non-blocking progress for PCNs. Formally, a PCN im-plementation is disjoint-access parallel if for anytwo payments channels ei, ej , channel-state (ei) ∩channel-state (ej) =∅.

Lemma 2. There does not exist any strictly seri-alizable disjoint-access parallel implementation forthe payment channels problem that provides non-blocking progress.

We defer to Appendix D for a proof sketch. Hav-ing established this inherent cost to concurrencyand privacy, we model global state by a Txid fieldattached to each of the payments. We remark thatthis Txid, however, allows an adversary to reducethe set of possible senders and receivers for thepayment, therefore inevitably reducing the privacyguarantees, as we discuss in Section 5.2.

5.2 Ideal World Functionality

Here, we show how to modify the ideal functional-ity F , as described in Section 3.2, to account forthe changes to achieve non-blocking progress in anyPCN. First, a single identifier Txid (as opposed toindependently sampled hi) is used for all the pay-ment channels in the path (c〈u0,u1〉, . . . , c〈un,un+1〉).Second, F no longer aborts a payment simply whenno capacity is left in a payment channel. Instead,F queues the payment if its Txid is higher than thecurrent in-flight payment, or aborts it the Txid islower. We detail the modified ideal functionalityin Appendix C.

Discussion. Here, we discuss how the modifiedideal world definition captures the security and pri-vacy notions of interest as described in Section 3.1.In particular, it is easy to see that the notions of bal-ance security and value privacy are enforced alongthe same lines. However, the leakage of the samepayment identifier among all intermediate users inthe payment path, reduces the possible set of senderand receivers to the actual sender and receiver

14

Figure 9: Illustrative example of tradeoff between con-currency and privacy. Each node represents a user: blacknodes are honest and red are byzantine. In both cases,we assume two concurrent payments: S1 pays R1 and S2

pays R2 through the path U1, U2, U3. The color of thearrow denotes the payment identifier. Dashed ellipsesdenote the anonymity set for each case.

for such payment, thereby breaking relationshipanonymity. Therefore, there is an inherent tradeoffbetween how to handle concurrent payments (block-ing or non-blocking) and the anonymity guarantees.

An illustrative example of this tradeoff is shownin Figure 9. It shows how two simultaneous pay-ments pay1((c〈S1,U1〉, c〈U1,U2〉, c〈U2,U3〉, c〈U3,R1〉), v)and pay2((c〈S2,U1〉, c〈U1,U2〉, c〈U2,,U3〉, c〈U3,R2〉), v) arehandled depending on whether concurrent pay-ments are handled in a blocking or non-blockingfashion. We assume that both payments can suc-cessfully finish in the current PCN and that bothpayments transfer the same payment amount v, asotherwise relationship anonymity is trivially broken.

For the case of blocking payments, each inter-mediate user uj observes an independently chosenidentifier Txidij for each payment payi. There-fore, the attacker is not able to correlate the pair(Txid11,Txid21) (i.e., view of U1) with the pair(Txid13,Txid23) (i.e., view of U3). It follows thatfor a pay operation issued by any node, say S1, theset of possible receivers that the adversary observesis {R1, R2}.

However, when the concurrent payments are han-dled in a non-blocking manner, the adversary ob-serves for pay1 that Txid11 = Txid13. Therefore, theadversary can trivially derive that the only possiblereceiver for a pay initiated by S1 is R1.

5.3 Rayo: Our Construction

Building Blocks. We require the same buildingblocks as described in Section 4.1 and Section 4.2.The only difference is that the channel’s state be-tween two users is now defined as channel-state :=(cur(ui,uj)[ ], Q(ui,uj)[ ], cap(ui,uj)), where cur denotesan array of payments currently using (part of) thecapacity available at the payment channel; Q de-notes the array of payments waiting for enough ca-pacity at the payment channel, and cap denotes thecurrent capacity value of the payment channel.

Operations. The openChannel and closeChanneloperations remain as described in Section 4.3. How-ever, the pay operation has to be augmented to en-sure non-blocking payments. We have described theadditional actions in light blue pseudocode in Fig-ures 7 and 8.

In the following, we informally describe these ad-ditional actions required for the pay operation. In anutshell, when a payment reaches an intermediateuser in the path, several events can be triggered.The simplest case is when the corresponding pay-ment channel is not saturated yet (i.e., enough ca-pacity is left for the payment to succeed). The useraccepts the payment and simply stores its informa-tion in cur as an in-flight payment.

The somewhat more interesting case occurs whenthe payment channel is saturated. This means that(possibly several) payments have been already gonethrough the payment channel. In this case, the sim-plest solution is to abort the new payment, but thisleads to deadlock situations. Instead, we ensurethat deadlocks do not occur by leveraging the totalorder of payment identifiers: If the new paymentidentifier (Txid) is higher than any of the paymentidentifiers currently active in the payment channel(i.e., included in cur [ ]), the payment identified byTxid is stored in Q. In this manner, if any of the cur-rently active payments are aborted, a queued pay-ment (Txid∗) can be recovered from Q and reissuedtowards the receiver. On the other hand, if Txid islower than every identifier for currently active pay-ments, the payment identified by Txid is directlyaborted as it would not get to complete in the pres-ence of a concurrent payment with higher identifierin the PCN.

15

5.4 Analysis and System Discussion

Security and Privacy Analysis. In the follow-ing, we state the security and privacy results forRayo when handling payments in a non-blockingmanner. We prove our results in the (Fanon,FB)-hybrid model. In other words, Theorem 2 holds forany UC-secure realization of Fanon and FB (analysisin Appendix A).

Theorem 2 (UC-Security). Let H : {0, 1}∗ →{0, 1}λ be a hash function modelled as a randomoracle, and let (P,V) a zero-knowledge proof sys-tem, then Rayo UC-realizes the ideal functionalityF described in Figure 10 in the (Fanon,FB)-hybridmodel.

System Discussion. Rayo is compatible withBitcoin, can be generally applicable to PCN andsupports bidirectional payment channels similar toFulgor. Moreover, the Rayo protocol provides non-blocking progress. Specifically, Rayo ensures thatsome payment successfully terminates in every exe-cution. Intuitively, this is because any two conflict-ing payments can necessarily be ordered by theirrespective unique identifier: the highest paymentidentifier is deterministically identified and termi-nates successfully while the lower priority paymentaborts.

5.5 Fulgor vs Rayo

In this work, we characterize the tradeoff betweenthe two protocols presented in this work. As shownin Table 1, both protocols guarantee crucial secu-rity and correctness properties such as balance secu-rity and serializability. By design, Rayo is the onlyprotocol that ensures non-blocking progress. Fi-nally, regarding privacy, we aimed at achieving thestrongest privacy possible. However, although bothprotocols guarantee value privacy, we have shown

Table 1: Comparison between Fulgor and Rayo.

Fulgor Rayo

Balance security Serializability

Non-blocking progress # Value Privacy

Anonymity G#

that it is impossible to simultaneously achieve non-blocking progress and strong anonymity. There-fore, Fulgor achieves strong anonymity while Rayoachieves non-blocking progress at the cost of weak-ening the anonymity guarantees. We note never-theless that Rayo provides relationship anonymityonly if none of the intermediate nodes is compro-mised. Intuitively, Rayo provides this (weaker)privacy guarantee because it still uses Multi-HopHTLC as Fulgor.

6 Performance Analysis

In this section, we first evaluate the performance ofFulgor. Finally, we describe the overhead requiredfor Rayo.

We have developed a proof-of-concept implemen-tation in Python to evaluate the performance ofFulgor. We interact with the API of lnd [1], the re-cently released Lightning Network implementation,We use listchannels to extract the current capacityof an open payment channel, listpeers to extract thelist of public keys from other users in the network,and getinfo to extract the user’s own public key. Wehave instantiated the hash function with SHA-256.We have implemented the Multi-Hop HTLC usinga python-based implementation of ZK-Boo [63] tocreate the zero-knowledge proofs. We set ZK-Booto use SHA-256, 136 rounds to achieve a soundnesserror of the proofs of 2−80, and a witness of 32 bytesas in [69].

Implementation-level Optimizations. Dur-ing the protocol description, we have assumed thatthe sender creates a different anonymous commu-nication channel with each intermediate user. Inour implementation, however, we use Sphinx [31]to create a single anonymous communication chan-nel between sender and receiver, where intermedi-ate nodes are the intermediate users in the path.Sphinx allows to send the required payment infor-mation to each intermediate user while obfuscatingthe information intended for other users in the pathand the actual length of the path by padding the for-warded data. This optimization has been discussedin the bitcoin community and implemented in thecurrent release of lnd [9].

Testbed. We have simulated five users and createda linear structure of payment channels: user i haspayment channels open only with user i−1 and user

16

i+ 1, user 0 is the sender, and user 4 is the receiverof the pay operation. We run each of the users in aseparated virtual machine with an Intel Core i7 3.1GHz processor and 2 GB RAM. The machines areconnected in a local network with a mean latency of111.5 milliseconds. For our experiments, we assumethat each user has already opened the correspondingpayment channels and got the public verificationkey of each other user in the PCN. As this is a onetime setup operation, we do not account for it inour experiments.

Performance. We have first executed the pay-ment operation available in the lnd software, whichuses the HTLC-based payment as the contract forconditional updates in a payment channel. We ob-serve that a (non-private) pay operation over a pathwith 5 users takes 609 ms and so needs Fulgor. Ad-ditionally, the Sdr must run the SetupHTLC(n + 1)protocol, increasing thereby her computation time.Moreover, the Sdr must send the additional in-formation corresponding to the Multi-Hop HTLCcontract (i.e., (xi, yi, yi+1, πi)) to each intermediateuser, which adds communication complexity.

The sender requires 309 ms to compute the proofπi for each of the intermediate users. Each proofis of size 1.65 MB. Finally, each intermediate userrequires 130 ms to verify πi. We focus on the zero-knowledge proofs as they are the most expensiveoperation.

Therefore, the total computation overhead is 1.32seconds (lnd pay and Multi-Hop HTLC) and the to-tal communication overhead is less than 5 MB (3zero-knowledge proofs plus the tuple of small-sizevalues (xi, yi, yi+1) per intermediate user). We ob-serve that previous proposal [69] required around10 seconds to compute only a single zero-knowledgeproof. In contrast, the pay operation in Fulgor re-quires less than 2 seconds of computation and tocommunicate less than 5 MB among the users inthe path for the complete payment operation, whichdemonstrates the practicality of Fulgor.

Scalability. In order to test the scalability of thepay operation in Fulgor, we have studied the run-ning time and communication overhead required byeach of the roles in a payment (i.e., sender, receiver,and intermediate user). Here, we take into accountthat Sphinx requires to pad the forwarded messagesto the maximum path length. In the absence ofwidespread PCN in practice, we set the maximum

path length to 10 in our test, as suggested for simi-lar payment networks such as the Ripple credit net-work [49].

Regarding the computation time, the sender re-quires 3.09 seconds to create πi for each interme-diate user. However, this computation time canbe improved if different πi are calculated in paral-lel taking advantage of current multi-core systems.Each intermediate user requires 130 ms as only hasto check the contract for payment channels withsuccessor and predecessor user in the path. Finally,the receiver incurs in few ms as she only has to checkwhether a given value is the correct pre-image of agiven hash value.

Regarding communication overhead, the sendermust create a message with 10 proofs of knowledgeand other few bytes associated to the contract foreach intermediate payment channel. So in total,the sender must forward 17MB approximately. AsSphinx requires padded messages at each node toensure anonymity, every intermediate user must for-ward a message of the same size.

In summary, these results show that even withan unoptimized implementation, a payment with 10intermediate users takes less than 5 seconds and re-quire a communication overhead of approximately17MB at each intermediate user. Therefore, Fulgorinduces a relatively small overhead while enablingpayments between any two users in the PCN andhas the potential to be deployed as a PCN witha growing base of users performing payments witheven 10 intermediate users in a matter of few sec-onds, a result in line with other privacy preservingpayment systems [54, 49].

Non-blocking payments (Rayo). Given theirsimilar definitions, the performance evaluation forFulgor carries over to Rayo. Additionally, the man-agement of non-blocking payments requires that in-termediate users maintain a list (cur) of currentin-flight payments and a queue (Q) of paymentswaiting to be forwarded when capacity is available.The management of these data structures requiresa fairly small computation overhead. Moreover,the number of messages to be stored in these datastructures according to the specification of Rayo isclearly linear in the length of the path. Specifically,a payment involving a path of length k ∈ N incursO(c·k) message complexity, where c is bounded bythe total of concurrent conflicting payments.

17

7 Related Work

Payment channels were first introduced by the Bit-coin community [2] and since then, several ex-tensions have been proposed. Decker and Wat-tenhofer [32] describe bidirectional payment chan-nels [32]. Lind et al. [47] leverage trusted platformmodules to use a payment channel without hin-dering compatibility with Bitcoin. However, theseworks focus on a single payment channel and theirextension to support PCNs remain an open chal-lenge.

TumbleBit [41] and Bolt [40] propose off-chainpath-based payments while achieving sender/re-ceiver anonymity in Tumblebit and paymentanonymity in Bolt. However, these approaches arerestricted to single hop payments, and it is not clearhow to extend them to account for generic multi-hopPCNs and provide the privacy notions of interest,as achieved by Fulgor and Rayo.

The Lightning Network [60] has emerged as themost prominent proposal for a PCN in Bitcoin.Other PCNs such as Thunder [19] and Eclair [10] forBitcoin and Raiden [13] for Ethereum are being pro-posed as slight modifications of the Lightning Net-work. Nevertheless, their use of HTLC leaks a com-mon identifier per payment, thereby reducing theanonymity guarantees as we described in this work.Moreover, current proposals lack a non-blocking so-lution for concurrent payments. Fulgor and Rayo,instead, rely on Multi-Hop HTLC to overcome thelinkability issue with HTLC. They provide a trade-off between non-blocking progress and anonymity.

Recent works [54, 49] propose privacy definitionsfor credit networks, a payment system that sup-ports multi-hop payments similar to PCNs. More-over, privacy preserving protocols are described forboth centralized [54] and decentralized credit net-works [49]. However, credit networks differ fromPCNs in that they do not require to ensure ac-countability against an underlying blockchain. Thisrequirement reduces the set of cryptographic oper-ations available to design a PCN. Nevertheless, Ful-gor and Rayo provide similar privacy guarantees ascredit networks even under those restrictions.

Miller et al [53] propose a construction for pay-ment channels to reduce the time that funds arelocked at intermediate payment channels (i.e., col-lateral cost), an interesting problem but orthogonalto our work. Moreover, they formalize their con-

struction for multi-hop payments as an ideal func-tionality. However, they focus on collateral cost anddo not discuss privacy guarantees, concurrent pay-ments are handled in a blocking manner only, andtheir construction relies on smart contracts avail-able on Ethereum that are incompatible with thecurrent Bitcoin scripting system.

Towns proposed [69] a variation of the HTLCcontract, based on zk-SNARKs, to avoid its link-ability problem among payment channels in a path.However, the Bitcoin community has not adoptedthis approach due to its inefficiency. In this work,we revisit this solution with a formal protocol withprovable security and give an efficient instantiationbased on ZK-Boo [38].

8 Conclusion

Permisionless blockchains governed on global con-sensus protocols face, among others, scalabilityissues in catering a growing base of users andpayments. A burgeoning approach to overcomethis challenge consists of PCNs and recent effortshave derived in the first yet alpha implementa-tions such as the Lightning Network [60] in Bit-coin or Raiden [13] in Ethereum. We are, however,only scratching the surface as many challenges suchas liquidity, network formation, routing scalability,concurrency or privacy are yet to be thoroughlystudied.

In this work, we lay the foundations for privacyand concurrency in PCNs. In particular, we for-mally define in the Universal Composability frame-work two modes of operation for PCNs attendingto how concurrent payments are handled (blockingversus non-blocking). We provide formally proveninstantiations (Fulgor and Rayo) for each, offer-ing a tradeoff between non-blocking progress andanonymity. Our evaluation results demonstratethat is feasible to deploy Fulgor and Rayo in prac-tice and can scale to cater a growing number ofusers.

Acknowledgments. We thank the anonymous re-viewers for their helpful reviews, and Ivan Pryvalovfor providing his python-based implementation ofZK-Boo.

This work is partially supported by a Intel/CE-RIAS research assistantship, and by the NationalScience Foundation under grant CNS-1719196.

18

This research is based upon work supported by theGerman research foundation (DFG) through thecollaborative research center 1223 and by the stateof Bavaria at the Nuremberg Campus of Technology(NCT). NCT is a research cooperation between theFriedrich-Alexander-University Erlangen-Nurnberg(FAU) and the Technische Hochschule NurnbergGeorg Simon Ohm (THN).

References

[1] Alpha release of the lightning network daemon.Blog entry. http://lightning.community/

release/software/lnd/lightning/2017/

01/10/lightning-network-daemon-alpha-

release/.

[2] Bitcoin wiki: Bitcoin contract. https://en.

bitcoin.it/wiki/Contract.

[3] Bitcoin wiki: Bitcoin scalability faq. https:

//en.bitcoin.it/wiki/Scalability_FAQ.

[4] Bitcoin wiki: Block size limit contro-versy. https://en.bitcoin.it/wiki/Block_

size_limit_controversy.

[5] Bitcoin wiki: Op return. https://en.

bitcoin.it/wiki/OP_RETURN.

[6] Bitcoin wiki: Payment channels. https://en.bitcoin.it/wiki/Payment_channels.

[7] Bitcoin wiki: Timelock. https://en.

bitcoin.it/wiki/Timelock.

[8] Bitcoin wiki: Transaction malleabil-ity. https://en.bitcoin.it/wiki/

Transaction_Malleability.

[9] Bolt #4: Onion routing protocols. https://

github.com/lightningnetwork/lightning-

rfc/blob/master/04-onion-routing.md.

[10] Eclair implementation of the lightning net-work. https://github.com/ACINQ/eclair.

[11] Lightning network daemon. Github im-plementation. https://github.com/

LightningNetwork/lnd.

[12] Lightning protocol reference implementation.Github implementation. https://github.

com/ElementsProject/lightning.

[13] Raiden network. Project’s website. http://

raiden.network/.

[14] Reliable transaction submission. Rip-ple protocol’s documentation. https://

ripple.com/build/reliable-transaction-

submission/.

[15] Ripple protocol. Project’s website. https://

ripple.com/.

[16] Segregated witness adoption. Blog en-try. https://bitcoincore.org/en/segwit_

adoption/.

[17] Stellar protocol. Project’s website. https://

www.stellar.org/.

[18] Stress test prepares visanet for the mostwonderful time of the year. Blog entry.http://www.visa.com/blogarchives/

us/2013/10/10/stress-test-prepares-

visanet-for-the-most-wonderful-time-

of-the-year/index.html.

[19] Thunder network. Project’s website. https:

//github.com/blockchain/thunder.

[20] Alpern, B., and Schneider, F. B. Definingliveness. Inf. Process. Lett. 21, 4 (Oct. 1985),181–185.

[21] Androulaki, E., Karame, G. O.,Roeschlin, M., Scherer, T., and Cap-kun, S. Evaluating user privacy in bitcoin.Financial Cryptography and Data Security2013.

[22] Atlas, K. The inevitability of pri-vacy in lightning networks. Blog entry.https://www.kristovatlas.com/the-

inevitability-of-privacy-in-lightning-

networks/.

[23] Attiya, H., and Welch, J. DistributedComputing. Fundamentals, Simulations, andAdvanced Topics. John Wiley & Sons, 2004.

[24] Backes, M., Kate, A., Manoharan, P.,Meiser, S., and Mohammadi, E. Anoa: Aframework for analyzing anonymous communi-cation protocols. In IEEE 26th Computer Se-curity Foundations Symposium (2013).

19

[25] Barber, S., Boyen, X., Shi, E., and Uzun,E. Bitter to better. how to make Bitcoin abetter currency. Financial Cryptography andData Security 2012.

[26] Camenisch, J., and Lysyanskaya, A. Aformal treatment of onion routing. In Advancesin Cryptology—CRYPTO (2005).

[27] Canetti, R. Universally composable security:A new paradigm for cryptographic protocols.In ”FOCS’01”.

[28] Cristian, F., Aghili, H., and Strong,H. R. Approximate clock synchronization de-spite omission and performance faults and pro-cessor joins. In Proceedings of the 16th Interna-tional Symposium on Fault-Tolerant Comput-ing (July 1986).

[29] Dandekar, P., Goel, A., Govindan, R.,and Post, I. Liquidity in credit networks: alittle trust goes a long way. In ACM Conferenceon Electronic Commerce (2011).

[30] Dandekar, P., Goel, A., Wellman,M. P., and Wiedenbeck, B. Strategic for-mation of credit networks. In WWW (2012).

[31] Danezis, G., and Goldberg, I. Sphinx: Acompact and provably secure mix format. In30th IEEE Symposium on Security and Privacy(S&P 2009).

[32] Decker, C., and Wattenhofer, R. Afast and scalable payment network with bit-coin duplex micropayment channels. In Sta-bilization, Safety, and Security of DistributedSystems (2015).

[33] Dryja, T. Unlinkable outsourcedchannel monitoring. (Talk transcript)https://diyhpl.us/wiki/transcripts/

scalingbitcoin/milan/unlinkable-

outsourced-channel-monitoring/.

[34] Fischer, M. J., Lynch, N. A., and Pater-son, M. S. Impossibility of distributed con-sensus with one faulty process. J. ACM 32, 2(Apr. 1985), 374–382.

[35] Friedenbach, M., BtcDrak, Dorier, N.,and kinoshitajona. Bip 68: Relative lock-

time using consensus-enforced sequence num-bers. https://github.com/bitcoin/bips/

blob/master/bip-0068.mediawiki.

[36] Fugger, R. Money as ious in socialtrust networks & a proposal for a decen-tralized currency network protocol. Techni-cal Report, 2004. http://archive.ripple-

project.org/decentralizedcurrency.pdf.

[37] Ghosh, A., Mahdian, M., Reeves, D. M.,Pennock, D. M., and Fugger, R. Mecha-nism design on trust networks. In WINE’07.

[38] Giacomelli, I., Madsen, J., and Orlandi,C. Zkboo: Faster zero-knowledge for booleancircuits. In USENIX Security (2016).

[39] go1111111 (pseudonym). Idea to im-prove lightning network. Forum post.https://bitcointalk.org/index.php?

topic=1134319.0.

[40] Green, M., and Miers, I. Bolt: Anonymouspayment channels for decentralized currencies.In CCS (2017).

[41] Heilman, E., Alshenibr, L., Baldimtsi,F., Scafuro, A., and Goldberg, S.TumbleBit: An untrusted bitcoin-compatibleanonymous payment hub. In NDSS (2017).

[42] Herlihy, M., and Shavit, N. On the natureof progress. In OPODIS (2011), pp. 313–328.

[43] Herrera-Joancomartı, J., and Perez-Sola, C. Privacy in bitcoin transactions:New challenges from blockchain scalability so-lutions. In Modeling Decisions for ArtificialIntelligence (2016).

[44] Kosba, A., Miller, A., Shi, E., Wen,Z., and Papamanthou, C. Hawk: Theblockchain model of cryptography and privacy-preserving smart contracts. In IEEE S&P(2016).

[45] Koshy, P., Koshy, D., and McDaniel, P.An analysis of anonymity in bitcoin using p2pnetwork traffic. In Financial Cryptography andData Security (2014).

20

[46] Lamport, L., and Fischer, M. Byzan-tine generals and transaction commit proto-cols. Tech. Rep. 62, SRI International, Apr.1982.

[47] Lind, J., Eyal, I., Pietzuch, P. R., andSirer, E. G. Teechan: Payment channelsusing trusted execution environments. http:

//arxiv.org/abs/1612.07766.

[48] Lopp, J. Lightning’s balancing act: Chal-lenges face bitcoin’s scalability savior. Blog en-try. http://www.coindesk.com/lightning-

technical-challenges-bitcoin-

scalability/.

[49] Malavolta, G., Moreno-Sanchez, P.,Kate, A., and Maffei, M. SilentWhispers:Enforcing security and privacy in credit net-works. In NDSS (2017).

[50] McCorry, P., Moser, M., Shahandashti,S. F., and Hao, F. Towards bitcoin paymentnetworks. In Australasian Conference Informa-tion Security and Privacy (2016).

[51] Meiklejohn, S., and Orlandi, C. Privacy-enhancing overlays in bitcoin. In BITCOIN(2015).

[52] Meiklejohn, S., Pomarole, M., Jordan,G., Levchenko, K., McCoy, D., Voelker,G. M., and Savage, S. A fistful of bitcoins:Characterizing payments among men with nonames. In IMC (2013).

[53] Miller, A., Bentov, I., Kumaresan, R.,and McCorry, P. Sprites: Payment chan-nels that go faster than lightning. CoRRabs/1702.05812 (2017).

[54] Moreno-Sanchez, P., Kate, A., Maffei,M., and Pecina, K. Privacy preserving pay-ments in credit networks. In NDSS (2015).

[55] Moreno-Sanchez, P., Modi, N.,Songhela, R., Kate, A., and Fahmy, S.Mind your credit: Assessing the health of theripple credit network. CoRR abs/1706.02358(2017).

[56] Moreno-Sanchez, P., Zafar, M. B., andKate, A. Listening to whispers of ripple:

Linking wallets and deanonymizing transac-tions in the ripple network. In PETS (2016).

[57] Nakamoto, S. Bitcoin: A peer-to-peer elec-tronic cash system. https://bitcoin.org/

bitcoin.pdf, 2008.

[58] Papadimitriou, C. H. The serializabilityof concurrent database updates. J. ACM 26(1979), 631–653.

[59] Pfitzmann, A., and Hansen, M.Anonymity, unlinkability, undetectability,unobservability, pseudonymity, and identitymanagement – a consolidated proposal forterminology, 2008.

[60] Poon, J., and Dryja, T. The bit-coin lightning network: Scalable off-chaininstant payments. Technical Report.https://lightning.network/lightning-

network-paper.pdf.

[61] Post, A., Shah, V., and Mislove, A.Bazaar: Strengthening user reputations in on-line marketplaces. In NSDI (2011).

[62] Prihodko, P., Zhigulin, S., Sahno,M., and Ostrovskiy, A. Flare: Anapproach to routing in lightning network.http://bitfury.com/content/5-white-

papers-research/whitepaper_flare_

an_approach_to_routing_in_lightning_

network_7_7_2016.pdf.

[63] Pryvalov, I. pyZKBoo++ implementation.Project’s website. https://sites.google.

com/view/pyzkboopp/home.

[64] Reid, F., and Harrigan, M. An analysis ofanonymity in the bitcoin system. In Securityand Privacy in Social Networks (2013).

[65] Russell, R. Reaching the ground with light-ning. Technical Report. http://ozlabs.org/

~rusty/ln-deploy-draft-01.pdf.

[66] Spagnuolo, M., Maggi, F., and Zanero,S. BitIodine: Extracting intelligence from thebitcoin network. In Financial Cryptographyand Data Security (2014).

[67] Torpey, K. Brock pierce: Bitcoin’s scalabil-ity issues are a sign of its success. Blog entry.

21

https://bitcoinmagazine.com/articles/

brock-pierce-bitcoin-s-scalability-

issues-are-a-sign-of-its-success-

1459867433/.

[68] Torpey, K. Does the lightning networkthreaten bitcoin?s censorship resistance?Blog entry. https://bitcoinmagazine.

com/articles/does-the-lightning-

network-threaten-bitcoin-s-censorship-

resistance-1461953131/.

[69] Towns, A. Better privacy withSNARKs. Mailing List. https:

//lists.linuxfoundation.org/pipermail/

lightning-dev/2015-November/000309.

html.

[70] van Wirdum, A. Segwit or not, bitfuryis getting ready for lightning with suc-cessful bitcoin main net test. Blog entry.https://bitcoinmagazine.com/articles/

segwit-or-not-bitfury-ready-lightning-

successful-bitcoin-main-net-test/.

[71] Viswanath, B., Mondal, M., Gummadi,K. P., Mislove, A., and Post, A. Canal:Scaling social network-based sybil toleranceschemes. In EuroSys (2012).

[72] Wikstrom, D. A universally composable mix-net. In Theory of Cryptography Conference(2004), M. Naor, Ed.

A Security Analysis

Our proof strategy consists of the description of asimulator S that handles users corrupted by the at-tacker and simulates the real world execution pro-tocol while interacting with the ideal functionalityF . The simulator S spawns honest users at adver-sarial will and impersonates them until the envi-ronment E makes a corruption query on one of theusers: At this point S hands over to A the inter-nal state of the target user and routes all of thesubsequent communications to A, who can replyarbitrarily. For operations exclusively among cor-rupted users, the environment does not expect anyinteraction with the simulator. Similarly, commu-nications exclusively among honest nodes happenthrough secure channels and therefore the attacker

does not gather any additional information otherthan the fact that the communication took place.For simplicity, we omit these operations in the de-scription of our simulator. The random oracle H issimulated by S via lazy-sampling. The operationsto be simulated for a PCN are described in the fol-lowing.

openChannel(c〈u1,u2〉, β, t, f): Let u1 be the user thatinitiates the request. We analyze two possible cases:

1. Corrupted u1: S receives a (c〈u1,u2〉, β, t, f) re-quest from the adversary on behalf of u1 andinitiates a two-user agreement protocol with Ato convey upon a local fresh channel identifierc〈u1,u2〉. If the protocol successfully terminates,S sends (open, c〈u1,u2〉, β, t, f) to F , which even-tually returns (c〈u1,u2〉, h).

2. Corrupted u2: S receives a message(c〈u1,u2〉, v, t, f) from F engages A in atwo-user agreement protocol on behalf of u1for the opening of the channel. If the executionis successful, S sends an accepting messageto F which returns (c〈u1,u2〉, h), otherwise itoutputs ⊥.

If the opening was successful the simulator initial-izes an empty list Lc〈u1,u2〉 and appends the value(h, v,⊥,⊥).

closeChannel(c〈u1,u2〉, v): Let u1 be the user that ini-tiates the request. We distinguish two possible sce-narios:

1. Corrupted u1: S receives a closing request fromthe adversary on behalf of u1, then it fetchesLc〈u1,u2〉 for some value (h, v, x, y). If such avalue does not exist then it aborts. Otherwiseit sends (close, c〈u1,u2〉, h) to F .

2. Corrupted u2: S receives (c〈u1,u2〉, h,⊥) fromF and simply notifies A of the closing of thechannel c〈u1,u2〉.

pay((c〈u0,u1〉, . . . , c〈un,un+1〉), v): Since the specifica-tions of the protocol differ depending on whether auser is a sender, a receiver or an intermediate nodeof a payment, we consider the cases separately.

1. Sender: In order to initiate a payment, theadversary must provide each honest user uiinvolved with a message mi that the simu-lator parses as (c〈ui−1,ui〉, c〈ui,ui−1〉, xi, yi, yi+1,

22

πi, vi, ti, ti+1), also the receiver of the pay-ment un+1 (in case it is not corrupted)is notified with some message (c〈un,un+1〉, xn,yn, v, tn). For each intermediate honest userui, the simulator checks whether ti ≥ ti+1 andV((H, yi, yi+1, xi), πi) = 1. If the conditionshold, S sends to F the tuple (pay, vi, (c〈ui−1,ui〉,c〈ui,ui+1〉), ti−1, ti), whereas for the receiver (incase it is honest) sends (pay, v, c〈un,un+1〉, tn) ifyn = H(xn), otherwise it aborts. For each in-termediate user ui the simulator confirms thepayment only when receives from the user ui+1

an x such that H(xi ⊕ x) = yi. If A out-puts a value x∗ such that H(x∗) = yi+1 butH(xi ⊕ x∗) 6= yi then S aborts the simula-tion. If the receiver is honest then the sim-ulator confirms the payment if the amount vcorresponds to what agreed with the senderand if H(xn) = yn. If the payment is con-firmed the entry (hi, v

∗− vi, xi⊕x, yi) is addedto Lc〈ui−1,ui〉

, where (h∗i , v∗, ·, ·) is the entry of

Lc〈ui−1,ui〉with the lowest v∗, and the same hap-

pens for the receiver.

2. Receiver: S receives some (h, c〈un,un+1〉, v, tn)

from F , then it samples a random x ∈ {0, 1}λand returns to A the tuple (x,H(x), v). If Areturns a string x′ = x, then S returns > to F ,otherwise it sends ⊥.

3. Intermediate user: S is notified that acorrupted user is involved in a paymentwith a message of the form (hi, hi+1,c〈ui−1,ui〉, c〈ui,ui+1〉, v, ti−1, ti) by F . S samples

an x ∈ {0, 1}λ and an x′ ∈ {0, 1}λ and runs thesimulator of the zero-knowledge scheme to ob-tain the proof π over the statement (H,H(x⊕x′), H(x′), x). The adversary is providedwith the tuple (c〈ui−1,ui〉, c〈ui,ui−1〉, x,H(x ⊕x′), H(x′), π, v, ti−1, ti) via an anonymous chan-nel. If A outputs a string x′′ = x ⊕ x′, thenS aborts the simulation. At some point ofthe execution the simulator is queried again on(hi, hi+1), then it sends x′ to A on behalf ofui+1. If A outputs a string z = x ⊕ x′ thesimulator sends > to F and appends (hi, v

∗ −v, z,H(z)) to Lc〈ui−1,ui〉

, where (h∗i , v∗, ·, ·) is the

entry of Lc〈ui−1,ui〉with the lowest v∗. The sim-

ulator sends ⊥ otherwise. Note that we con-sider the simpler case where a single node in

the payment is corrupted. However this canbe easily extended to the more generic case bybook-keeping the values of hi and choosing thecorresponding the pre-images x and x′ consis-tently. The rest of the simulation is unchanged.

Analysis. Since the simulation runs onlypolynomially-bounded algorithms it is easy to seethat the simulation is efficient. We now argue thatthe view of the environment in the simulation is in-distinguishable from the execution of the real-worldprotocol. For the moment, we assume that the sim-ulation never aborts, then we separately argue thatthe probability of the simulator to abort is negli-gible. For the openChannel and closeChannel algo-rithms the indistinguishability argument is trivial.On the other hand for the payment we need a moresophisticated reasoning. Consider first the scenariowhere the sender is corrupted: In this case the sim-ulation diverges form the the original protocol sinceeach multi-hop payment is broke down into sepa-rate single-hop payments. Note that the off-chaincommunication mimics exactly the real-world pro-tocol (as long as S does not abort): Each node uithat is not the receiver confirms the transaction toF only if it learns a valid pre-image of its yi. Sincewe assume that the simulation does not abort, it fol-lows that the simulation is consistent with the factthat each honest node always returns > at this stageof the execution (i.e., the payment chain does notstop at a honest node, other than the sender). How-ever, the values published in the blockchain couldin principle diverge from what the adversary is ex-pecting in the real execution. In fact, an entry ofthe real blockchain contains the values of (x,H(x))corresponding to a particular payment, in additionto the information that is leaked by the ideal func-tionality. Therefore we have to show that the valuesof (x, y) that the simulator appends to A’s view ofB (in the closeChannel simulation) have the samedistribution as in the real world. Note that thosevalues are either selected by the adversary if thesender is corrupted (there the argument is trivial)or chosen to be (x,H(x)) by the simulator, for somerandomly chosen x ∈ {0, 1}λ. For the latter case itis enough to observe that the following distributionsare statistically close((

n⊕i=1

xi, y1

), . . . , (xn, yn)

)≈ ((r1, s1), . . . , (rn, sn)),

23

where for all i : (xi, ri) ← {0, 1}2·λ, yi ← H(xi),and si ← H(ri). Note that on the left hand side ofthe equation the values are distributed accordinglyto the real-world protocol, while on the right handside the distribution corresponds to the simulatedvalues. The indistinguishability follows. For thesimulation of the receiver and of the intermediateusers one can use a similar argument. We only needto make sure that A cannot interrupt a paymentchain before it reaches the receiver, which is notallowed in the ideal world. It is easy to see that inthat case (A outputs x′′ such that H(x′′) = H(x⊕x′) before receiving x′) the simulation aborts.

What is left to be shown is that the simula-tion aborts with at most negligible probability. Letaborts the event that S aborts in the simulationof the sender and let aborti be the event that Saborts in the simulation of the intermediate user.By the union bound we have that Pr [abort] ≤Pr [aborts] + Pr [aborti].

We note that in case aborts happens than the ad-versary was able to output a valid proof πi over(H, yi, yi+1, xi) and an x∗ such that H(x∗) = yi+1

and H(x∗ ⊕ xi) 6= yi. Let w be a bitstring suchthat H(w) = yi+1 and H(w ⊕ xi) = yi, by thesoundness of the proof πi such a string is guar-anteed to exists. It follows that H(x∗ ⊕ xi) 6=H(w ⊕ xi) which implies that w 6= x∗, since His a deterministic function. However we have thatH(x∗) = H(w), which implies that w = x∗, since Acan query the random oracle at most polynomially-many times. This is a contradiction and thereforeit must be the case that for all PPT adversariesthe probability of aborts to happen is 0. We cannow rewrite Pr [abort] ≤ Pr [aborti]. Consider theevent aborti: In this case we have that A, on in-put (H(x ⊕ x′), H(x′), x), is able to output somex′′ = x⊕x′. Note that x′ is a freshly sampled valueand therefore the values H(x ⊕ x′) and H(x′) areuniformly distributed over the range of H. Thus theprobability that A is able to output the pre-imageof H(x ⊕ x′) without knowing x′ is bounded by anegligible function in the security parameter. It fol-lows that Pr [abort] ≤ negl(λ). And this concludesour proof.

Non-Blocking Solution. The security proof forour non-blocking solution is identical to what de-scribed above, with the only exception that the idealfunctionality leaks the identifier of a payment to the

intermediate users. Therefore the simulator mustmake sure to choose the transaction identifier con-sistently for all of the corrupted users involved inthe same payment. In addition to that, the sim-ulator must also implement the non-blocking logicfor the queueing of the payments. The rest of theargument is unchanged.

B Agreement between Two Users

In this section, we describe the protocol run bytwo users, u0 and u1, sharing a payment channelto reach agreement [34] on the channel’s state ateach point in time.

Notation and Assumptions. In this section,we follow the notation we introduced in Section 4.We assume that there is a total order between theevents received by the users at a payment chan-nel (e.g., lexicographically sorted by the hash of thecorresponding payment data) and the users (e.g.,lexicographically sorted by their public verificationkeys). Moreover, we assume that users perform theoperations associated to each event as defined inour construction (see Section 4.3). Therefore, inthis section we only describe the additional stepsrequired by users to handle concurrent payments.Finally, we assume that two users sharing a pay-ment channel, locally maintain the state of the pay-ment channel (channel-state). The actual defini-tion of channel-state depends on whether concur-rent payments are handled in a blocking or non-blocking manner. For blocking, channel-state is de-fined as cap(c〈u0,u1〉), where cap denotes the currentcapacity in the payment channel. For non-blocking,channel-state is defined as a tuple {cur[ ],Q[ ], cap},where cur denotes an array of payments currentlyusing (part of) the capacity available at the pay-ment channel; Q denotes the array of paymentswaiting for enough capacity at the payment chan-nel.

The agreement on channel-state between the cor-responding two users u0 and u1 is performed in twocommunication rounds. In the first round, bothusers exchange the set of events {decisionb} to beapplied into the channel-state. At the end of thisfirst round, each user comes up with the aggregatedset of events {decision} := {decision}0∪{decision}1deterministically sorted according to the followingcriteria. First, the events proposed by the user

24

with the highest identifier are included first. Sec-ond, if several events are included in {decision}b,they are sorted according to the following sequence:accept, abort, forward.5 Finally, events of the sametype are sorted in decreasing order by the corre-sponding payment identifier. These set of rules en-sure that the both users can deterministically com-pute the same sorted version of the set {decisioni}.

Before starting the second communication round,each user applies the changes related to each eventin {decisioni} to the current channel-state. Themapping between each event and the correspond-ing actions is defined as a function {(decisionj ,mj)}← f({decisioni}). This function returns a set of tu-ples that indicate what events must be forwarded towhich user in the payment path. Then, in the sec-ond communication round, each event decisionj issent to the corresponding user uj (encoded in mj).The actual implementation of the function f deter-mines how the concurrent payments are handled. InFulgor, we implement the function f as describedin Figures 7 and 8 (black pseudocode) for blockingapproach and as described in Figures 7 and 8 (lightblue pseudocode) for non-blocking approach.

In the following, we denote the completeagreement protocol between two users by2ProcCons(u0, u1, {decisioni}).

Lemma 3. 2ProcCons(u0, u1,{decisioni}) ensuresagreement on the channel-state given the set ofevents {decision}.

Proof. Assume that channel-state is consis-tent between two users ui and uj before2ProcCons(u0, u1,{decisioni}) is invoked. It iseasy to see that both users come with the samesorted version of {decisioni} since the sorting rulesare deterministic. Moreover, for each event, thefunction f deterministically updates channel-stateand returns a tuple (m, decision). As the events areapplied in the same order by both users, they reachagreement on the same updated channel-state andthe same set of tuples {(uk, decisionk)}.

5Although other sequences are possible, we fix this one toensure that the sorting is deterministic.

C Ideal World Functionality forNon-Blocking Payments

In this section, we detail the ideal world functional-ity for a PCN that handles concurrent payments ina non-blocking manner. We highlight in light bluethe changes with respect to the ideal world function-ality presented in Section 3.2 that correspond to aPCN that handles concurrent payments in a block-ing manner. Moreover, we assume the same model,perform the same assumptions and use the samenotation as described in Section 3.2. Additionally,we use the variable queued to track at which inter-mediate user the payment is queued if there is notenough capacity in her channel and the paymentidentifier is higher than those in-flight. Moreover,we use a list W to keep track of remaining hopsfor queued payments. Entries in W are of the form((c〈u1,u2〉, . . . , c〈uk,uk+1〉), v, (t1, . . . , tk)) and containthe remaining list of payment channels (c〈u1,u2〉, . . . ,c〈uk,uk+1〉), their associated timeouts (t1, . . . , tk) andthe remaining payment value v.

For simplicity we only model unidirectional chan-nels, although our functionality can be easily ex-tended to support also bidirectional channels. Theexecution of our simulation starts with F queryingFB to initialize it and F initializing itself the locallystored empty lists L, C,W.

D Proof for Concurrency Lem-mas

Figure 11: Execution depicting two payments:paymentTxidi from Alice to Edward and payment Txidj fromAlice to Fabi. If Alice and Bob are byzantine, they canallow both payments to be successful (while losing fundsthemselves).

Proof for Lemma 1. Consider an execution of twopayments depicted in Figure 11: payment Txidifrom Alice to Edward and payment Txidj from Al-ice to Fabi. The payment channel between Aliceand Bob is a contending bottleneck for both Txidi

25

Open channel: On input (open, c〈u,u′〉, v, u′, t, f) from a user u, F checks whether c〈u,u′〉 is well-

formed (contains valid identifiers and it is not a duplicate) and eventually sends (c〈u,u′〉, v, t, f) to u′,who can either abort or authorize the operation. In the latter case, F appends the tuple (c〈u,u′〉, v, t, f)to B and the tuple (c〈u,u′〉, v, t, h) to L, for some random h. F returns h to u and u′.

Close channel: On input (close, c〈u,u′〉, h) from a user ∈ {u′, u} the ideal functionality F parses Bfor an entry (c〈u,u′〉, v, t, f) and L for an entry (c〈u,u′〉, v

′, t′, h), for h 6= ⊥. If c〈u,u′〉 ∈ C or or t > |B| ort′ > |B|, the functionality aborts. Otherwise, F adds the entry (c〈u,u′〉, v

′, t′, f) to B and adds c〈u,u′〉to C. F then notifies both users involved with a message (c〈u,u′〉,⊥, h).

Payment: On input (pay, v, (c〈u0,u1〉, . . . , c〈un,un+1〉), (t0, . . . , tn),Txid) from a user u0, F executes thefollowing interactive protocol:

1. For all i ∈ {1, . . . , (n + 1)}, F parses B for an entry of the form ((c〈ui−1,u′i〉, vi, t′i, fi)). If such

an entry does exist, F sends the tuple (Txid,Txid, c〈ui−1,ui〉, c〈ui,ui+1〉, v −∑n

j=i fj , ti−1, ti) tothe user ui via an anonymous channel (for the specific case of the receiver the tuple is only(Txid, c〈un,un+1〉, v, tn)). Then, F checks whether for all entries of the form (c〈ui−1,ui〉, v

′i, ·, ·) ∈ L

it holds that v′i ≥(

v−∑n

j=i fj

)and that ti−1 ≥ ti. If this is the case, F adds di = (c〈ui−1,ui〉, v

′i−

(v −∑n

j=i fj), ti,⊥) to L, where (c〈ui−1,ui〉, v′i, ·, ·) ∈ L is the entry with the lowest v′i and sets

queued = n+ 1. Otherwise, F performs the following steps:

• If there exists an entry of the form (c〈uk,uk+1〉,−,−,Txid∗) ∈ L such that Txid > Txid∗, then

F adds dl = (c〈ul−1,ul〉, v′l−(v+

∑nj=l fj), tl,⊥) to L, for l ∈ {1, . . . , k} . Additionally, F adds

(Txid, (c〈uk,uk+1〉, . . . , c〈un,un+1〉), v−∑n

j=k fj , (tk, . . . , tn)) ∈ W. Finally, F sets queued = k.

• Otherwise, F removes from L all the entries di added in this phase. Additionally, F looksfor entries of the form (Txid′, (c〈i,i+1〉, . . . , c〈n,n+1〉), v, (ti, . . . , tn)) ∈ W, deletes them andexecute (pay, v, (c〈i,i+1〉, . . . , c〈n,n+1〉), (ti, . . . , tn)).

2. For all i ∈ {queued, . . . , 1} F queries all ui with (hi, hi+1), through an anonymous channel. Eachuser can reply with either > or ⊥. Let j be the index of the user that returns ⊥ such that forall i > j : ui returned >. If no user returned ⊥ we set j = 0.

3. For all i ∈ {j + 1, . . . , queued} the ideal functionality F updates di ∈ L (defined as above) to(−,−,−,Txid) and notifies the user of the success of the operation with with some distinguishedmessage (success,Txid,Txid). For all i ∈ {0, . . . , j} (if j 6= 0) F performs the following steps:

• Removes di from L and notifies the user with the message (⊥,Txid,Txid).

• F looks for entries of the form (Txid′, (c〈i,i+1〉, . . . , c〈n,n+1〉), v, (ti, . . . , tn)) ∈ W, removesthem from W and execute (pay, v, (c〈i,i+1〉, . . . , c〈n,n+1〉), (ti, . . . , tn)).

Figure 10: Ideal world functionality for PCNs for non-blocking progress.

26

and Txidj , however, only one of the payments canbe successfully executed since the payment channelbetween Alice and Bob has the capacity for onlyone of the two to be successful. Suppose by contra-diction that both Txidi and Txidj are successfullycompleted. Indeed, this is possible since byzan-tine users Alice and Bob can respond with an in-correct payment channel capacity to users Edwardand Fabi. However, the payment channel betweenAlice and Bob does not have sufficient capacity forboth transactions to be successful—contradictionsince there does not exist any equivalence to thesequential specification of payments channels.

Proof for Lemma 2. Suppose by contradiction thatthere exists a strictly serializable disjoint-accessimplementation providing non-blocking progress.Consider the following payment network: u1 → u2→ u3 → u4 → u5 → u1. Consider two concur-rent pay operations of the form pay1(c〈u1,u2〉, c〈u2,u3〉,c〈u3,u4〉, c〈u4,u5〉, v) and pay2(c〈u4,u5〉, c〈u5,u1〉, c〈u1,u2〉,c〈u2,u3〉, v). Consider the execution E in which pay1and pay2 run concurrently up to the following step:pay1 executes from u1 → . . . u4 and pay2 executesfrom u4 → u5 → u1. Let E1 (and resp. E2) bethe extensions of E in which pay1 (and resp. pay2)terminates successfully and pay2 (and resp. pay1)terminates unsuccessfully. By assumption of non-blocking progress, there exists such a finite exten-sion of this execution in which both pay1 and pay2must terminate (though they may not be successfulsince this depends on the available channel capac-ity).

Since the implementation is disjoint-access paral-lel, execution E1 is indistinguishable to (u1, . . . , u5)(and resp. (u4, . . . , u3)) from the execution E, anextension of E, in which only pay1 (and resp. pay2)is successful and matches the sequential specifica-tion of PCN. Note that analogous arguments appliesfor the case of E2.

However, E1 (and resp. E2) is not a correct ex-ecution since it lacks the all-or-nothing semantics:only a proper subset of the channels from the ex-ecution E involved in pay1 (and resp. pay2) havetheir capacities decreased by v (and resp. v′). Thisis a contradiction to the assumption of strict serial-izability, thus completing the proof.

27