Anonymous Multi-Hop Locks for BlockchainScalability and Interoperability

Giulio Malavolta∗§, Pedro Moreno-Sanchez∗¶†, Clara Schneidewind†, Aniket Kate‡, Matteo Maffei†§Friedrich-Alexander-University Erlangen-Nurnberg, †TU Wien, ‡ Purdue University

Abstract—Tremendous growth in cryptocurrency usageis exposing the inherent scalability issues with permis-sionless blockchain technology. Payment-channel networks(PCNs) have emerged as the most widely deployed solutionto mitigate the scalability issues, allowing the bulk ofpayments between two users to be carried out off-chain.Unfortunately, as reported in the literature and furtherdemonstrated in this paper, current PCNs do not providemeaningful security and privacy guarantees [32], [42].

In this work, we study and design secure and privacy-preserving PCNs. We start with a security analysis of exist-ing PCNs, reporting a new attack that applies to all majorPCNs, including the Lightning Network, and allows anattacker to steal the fees from honest intermediaries in thesame payment path. We then formally define anonymousmulti-hop locks (AMHLs), a novel cryptographic primitivethat serves as a cornerstone for the design of secure andprivacy-preserving PCNs. We present several provablysecure cryptographic instantiations that make AMHLscompatible with the vast majority of cryptocurrencies. Inparticular, we show that (linear) homomorphic one-wayfunctions suffice to construct AMHLs for PCNs supportinga script language (e.g., Ethereum). We also propose aconstruction based on ECDSA signatures that does notrequire scripts, thus solving a prominent open problem inthe field.

AMHLs constitute a generic primitive whose useful-ness goes beyond multi-hop payments in a single PCNand we show how to realize atomic swaps and interoper-able PCNs from this primitive. Finally, our performanceevaluation on a commodity machine finds that AMHLoperations can be performed in less than 100 millisec-onds and require less than 500 bytes of communicationoverhead, even in the worst case. In fact, after acknowl-edging our attack, the Lightning Network developers haveimplemented our ECDSA-based AMHLs into their PCN.This demonstrates the practicality of our approach andits impact on the security, privacy, interoperability, andscalability of today’s cryptocurrencies.

∗Both contributed equally and are considered to be co-first authors.¶ This work was done while this author was at Purdue University.

I. INTRODUCTION

Cryptocurrencies are growing in popularity and areplaying an increasing role in the worldwide financialecosystem. In fact, the number of Bitcoin transactionsgrew by approximately 30% in 2017, reaching a peakof more than 420, 000 transactions per day in December2017 [2]. This striking increase in demand has givenrise to scalability issues [20], which go well beyond therapidly increasing size of the blockchain. For instance,the permissionless nature of the consensus algorithmused in Bitcoin today limits the transaction rate totens of transactions per second, whereas other paymentnetworks such as Visa support peaks of up to 47,000transactions per second [9].

Among the various proposals to solve the scalabilityissue [22], [23], [40], [50], payment-channels haveemerged as the most widely deployed solution in prac-tice. In a nutshell, two users open a payment channelby committing a single transaction to the blockchain,which locks their bitcoins in a deposit secured by aBitcoin (smart) contract. These users can then performseveral payments between each other without the needfor additional blockchain transactions, by simply locallyagreeing on the new deposit balance. A transaction isrequired only at the end in order to close the paymentchannel and unlock the final balances of the two parties,thereby drastically reducing the transaction load on theblockchain. Further research has proposed the conceptof payment-channel network [50] (PCN), where twousers not sharing a payment channel can still pay eachother using a path of open channels between them.Unfortunately, current PCNs fall short of providing ad-equate security, privacy, and interoperability guarantees.

A. State-of-the-art in PCNs

Several practical deployments of PCNs exist to-day [5], [8], [10] based on a common reference descrip-tion for the Lightning Network (LN) [6]. Unfortunately,this proposal is neither privacy-preserving, as shownin recent works [32], [42], nor secure, which stays incontrast to what until now was commonly believed, aswe show in this work. In fact, we present a new attack,the wormhole attack, which applies not only to the LN,

Network and Distributed Systems Security (NDSS) Symposium 201924-27 February 2019, San Diego, CA, USAISBN 1-891562-55-Xhttps://dx.doi.org/10.14722/ndss.2019.23330www.ndss-symposium.org

the most widely deployed PCN, but also other PCNsbased on the same cryptographic lock mechanism, suchas the Raiden Network [7].

PCNs have attracted plenty of attention also fromacademia. Malavolta et al. [42] proposed a secure andprivacy-preserving protocol for multi-hop payments.However, this solution is expensive as it requires toexchange a non-trivial amount of data (i.e., around 5MB) between the users in the payment path and it alsohinders interoperability as it requires the Hash Time-Lock Contract (HTLC) supported in the cryptocurrency.

Green and Miers presented BOLT, a hub-basedprivacy-preserving payment for PCNs [32]. BOLT re-quires cryptographic primitives only available in Zcashand it cannot be seamlessly deployed in Bitcoin. More-over, this approach is limited to paths with a singleintermediary and the extension to support paths ofarbitrary length remains an open problem.

The rest of the existing PCN proposals suffer fromsimilar drawbacks. Apart from not formalizing provableprivacy guarantees, they are restricted to a setting witha trusted execution environment [38] or with a Turingcomplete scripting language [25], [26], [35], [44] so thatthey cannot seamlessly work with prominent cryptocur-rencies today (except for Ethereum).

Poelstra introduced the notion of scriptless scripts,a modified version of a digital signature scheme sothat a signature can only be created when faithfullyfulfilling a cryptographic condition [49]. The resultingsignature is verifiable following the unmodified digitalsignature scheme. When applied to script-based systemslike Bitcoin or Ethereum, they are accompanied by corescripts (e.g., script to verify the signature itself). Thisapproach reduces the space required for cryptographicoperations in the script, saving thus invaluable byteson the blockchain. Moreover, it improves upon thefungibility of the cryptocurrency as transactions frompayment channels no longer require a script differentfrom other payments.

Although interesting, current proposals [49] lackformal security and privacy treatment and are based onlyon the Schnorr signature scheme, thus being incompat-ible with major cryptocurrencies like Bitcoin. Althoughthere exist early proposals for Schnorr adoption inBitcoin [55], it is unclear whether they will be realized.

In summary, existing proposals are neither generi-cally applicable nor interoperable, since they rely onspecific features (e.g., contracts) of individual cryptocur-rencies or trusted hardware. Furthermore, there seemsto be a gap between secure realization of PCNs andwhat is developed in practice, as we demonstrate withour attack, which affects virtually all deployed PCNs.

B. Our Contributions

In this work, we contribute to the rigorous under-standing of PCNs and present the first interoperable,secure, and privacy-preserving cryptographic construc-tion for multi-hop locks (AMHLs). Specifically,

• We analyze the security of existing PCNs, reportinga new attack (the wormhole attack) which allowsdishonest users to steal the payment fees from honestusers along the path. This attack applies to the LN,as well as any decentralized PCN (following thedefinition in [42]) where the sender does not knowin advance the intermediate users along the path tothe receiver. We communicated the attack to the LNdevelopers, who acknowledged the issue.

• In order to construct secure and privacy-preservingPCNs, we introduce a novel cryptographic primi-tive called anonymous multi-hop lock (AMHL). Wemodel the security of such a primitive in the UCframework [18] to inherit the underlying compos-ability guarantees. Then we show that AMHLs canbe generically combined with any blockchain to con-struct a fully-fledged PCN.

• As a theoretical insight emerging from the wormholeattack, we establish a lower bound on the communi-cation complexity of secure PCNs (Section III) thatfollow the definition from [42]: Specifically, we showthat an extra round of communication to determinethe path is necessary to have a secure transaction.

• We show how to realize AMHLs in different set-tings. In particular, we demonstrate that (linearly)homomorphic operations suffice to build any script-based AMHL. Furthermore, we show how to realizeAMHLs in a scriptless setting. This approach is ofspecial interest because it reduces the transactionsize, and, consequently, the blockchain load. Wegive a concrete construction based on the ECDSAsignature scheme, solving a prominent problem inthe literature [49]. This makes AMHLs compatiblewith the vast majority of cryptocurrencies (includingBitcoin and Ethereum). In fact, AMHLs have beenimplemented and tested in the LN [28], [29].

• We implemented our cryptographic constructions andshow that they require at most 60 milliseconds to becomputed and a communication overhead of less than500 bytes in the worst case. These results demonstratethat AMHLs are practical and ready to be deployed.In fact, AMHLs can be leveraged to design atomicswaps and interoperable (cross-currency) PCNs.

Organization. Section II shows the background onPCNs. Section III describes the wormhole attack. Sec-tion IV formally defines AMHLs. Section V containsour protocols for AMHLs and Section VI analyzestheir performance. Section VII describes applicationsfor AMHLs. Section VIII discusses the related workand Section IX concludes this paper.

2

II. CONTEXT: PAYMENT CHANNEL NETWORKS

A. Payment Channels

A payment channel allows two users to exchangebitcoin without committing every single payment tothe Bitcoin blockchain. For that, users first publish anon-chain transaction to deposit bitcoin into a multi-signature address controlled by both users. Such depositalso guarantees that all bitcoin are refunded at a possiblydifferent but mutually agreed time if the channel expires.Users can then perform off-chain payments by adjustingthe distribution of the deposit (that we will refer to asbalance) in favor of the payee. When no more off-chainpayments are needed (or the capacity of the paymentchannel is exhausted), the payment channel is closedwith a closing transaction included in the blockchain.This transaction sends the deposited bitcoin to eachuser according the most recent balance in the paymentchannel. We refer the reader to [22], [23], [43], [50] forfurther details.

B. A Payment Channel Network (PCN)

A PCN can be represented as a directed graph G =(V,E), where the set V of vertices represents the Bitcoinaccounts and the set E of weighted edges represents thepayment channels. Every vertex U ∈ V has associateda non-negative number that denotes the fee it chargesfor forwarding payments. The weight on a directed edge(U1, U2) ∈ E denotes the amount of remaining bitcointhat U1 can pay to U2.

A PCN is used to perform off-chain paymentsbetween two users with no direct payment channelbetween them but rather connected by a path of openpayment channels. For that, assume that S wants to payα bitcoin to R, which is reachable through a path of theform S → U1 → . . .→ Un → R. For their payment tobe successful, every link must have a capacity γi ≥ α′i,where α′i = α−

∑i−1j=1 fee(Uj) (i.e., the initial payment

value minus the fees charged by intermediate users inthe path). If the payment is successful, edges from Sto R are decreased by α′i. Importantly, to ensure thatR receives exactly α bitcoin, S must start the paymentwith a value α∗ = α +

∑nj=1 fee(Uj). We refer the

reader to [32], [42], [43], [50] for further details.

The concepts of payment channels and PCNshave already attracted considerable attention fromacademia [23], [32], [33], [37], [42]–[44]. In practice,the Lightning Network (LN) [6], [50] has emergedas the most prominent example. Currently, there existseveral independent implementations of the LN forBitcoin [5], [8], [10]. Moreover, the LN is also consid-ered as a scalability solution in other blockchain-basedpayment systems such as Ethereum [7].

C. Multi-Hop Payments Atomicity

A fundamental property for multi-hop payments isatomicity: Either the capacity of all channels in the pathis updated or none of the channels is changed. Partialupdates can lead to coin losses for the users on thepath. For instance, a user could pay a certain amountof bitcoin to the next user in the path but never receivethe corresponding bitcoin from the previous neighbour.The LN tackles this challenge by relying on a smartcontract called Hash Time-Lock Contract (HTLC) [50].This contract locks x bitcoin that can be released only ifthe contract’s condition is fulfilled. The contract relieson a collision-resistant hash function H and it is definedin terms of a hash value y := H(R), where R is chosenuniformly at random, the amount of bitcoin x, and atimeout t, as follows: (i) If Bob produces the conditionR∗ such that H(R∗) = y before t days, Alice pays Bobx bitcoin; (ii) If t days elapse, Alice gets back x bitcoin.

Fig. 1 shows an example of the use of HTLC ina payment. For simplicity, we assume that every usercharges a fee of one bitcoin and the payment amountis 10 bitcoin. In this payment, Edward first sets up thepayment by creating a random value R and sendingH(R) to Alice. Then, the commitment phase startsby Alice. She first sets on hold 13 bitcoin and thensuccessively every intermediate user sets on hold thereceived amount minus his/her own fee. After Dave sets10 coins on hold with Edward, the latter knows thatthe corresponding payment amount is on hold at eachchannel and he can start the releasing phase (depicted ingreen). For that, he reveals the value R to Dave allowinghim to fulfill the HTLC contract and settle the newcapacity at the payment channel. The value R is thenpassed backwards in the path allowing the settlement ofthe payment channels.

Privacy Issues in PCNs. Recent works [32], [42] showthat the current use of HTLC leaks a common identifieralong the payment path (i.e., the condition H(R)) thatcan be used by an adversary to tell who pays to whom.Current solutions to this privacy issue are expensivein terms of computation and communication [42] orincompatible with major cryptocurrencies [32]. Thiscalls for an in-depth study of this cryptographic tool.

Alice Bob  Carol Dave Edward

2. HTLC(A, B ,y ,13 ,4)

1. y := H(R)

6. R

3. HTLC(B, C, y, 12, 3) 4. HTLC(C, D, y, 11, 2) 5. HTLC(D, E, y, 10, 1)

7. R

9. R

20 / 7 50 / 50 12 / 12 15 / 5

8. R 7. R

38 50

1 12

8. R 6. R

7 7

5 5

Fig. 1: Payment (with and without wormhole attack) fromAlice to Edward for value 10 using HTLC contract. The honest(attacked) releasing phase is depicted in green (red). Non-bold(bold) numbers show the capacity of payment channels before(after) the payment. We assume a common fee of 1 coin.

3

III. WORMHOLE ATTACK IN EXISTING PCNS

In a nutshell, the wormhole attack allows two col-liding users on a payment path to exclude intermediateusers from participating in the successful completionof a payment, thereby stealing the payment fees whichwere intended for honest path nodes.

In more detail, assume a payment path (U0, . . . , Ui,. . . , Uj , . . . , Un) used by U0 to pay an amount α +∑k γk to Un, where γk = fee(Uk) denotes the fee

charged by the intermediate user Uk as a reward forenabling the payment. Further assume that Ui and Ujare two adversarial users that may deviate from theprotocol if some economic benefit is at stake. Theadversarial strategy is as follows.

In the commitment phase, every user behaves hon-estly. This, in particular, implies that every honest userhas locked a certain amount of coins in the hopeof getting rewarded for this. In the releasing phase,honest users Uj+1, . . . , Un correctly fulfill their HTLCcontracts and settle the balances and rewards in theircorresponding payment channels.

The user Uj behaves honestly with Uj+1 effectivelysettling the balance in their payment channel. On theother hand, Uj waits until the timeout set in the HTLCwith Uj−1 is about to expire and then agrees with Uj−1to cancel the HTLC and set the balance in their paymentchannel back to the last agreed one. Note that fromUj−1’s point of view, this is a legitimate situation (e.g.,there might not be enough coins in a payment channel atsome user after Uj and the payment had to be canceled).Moreover, the channel between Uj−1 and Uj does notneed to be closed, it is just rolled back to a previousbalance, a feature present in the Lightning Network.

As Uj−1 believes that the payment did not gothrough, she also cancels the HTLC with Uj−2, whoin turns cancels the HTLC with Uj−3 and so on. Thisprocess continues until Ui is approached by Ui+1. Here,Ui cancels the HTLC with Ui+1. However, Ui getsthe releasing condition R from Uj and can use it tofulfill the HTLC with Ui−1 and therefore settle the newbalance in that payment channel. Therefore, from thepoint of view of users U1, . . . , Ui−1, the payment hasbeen successfully carried out. An illustrative example ofthis attack is shown in Fig. 1 with the attacked releasingphase depicted in red.

Discussion. An adversary controlling users Ui and Ujin a payment path that carries out the attack describedin this section gets an overall benefit of

∑jk=i+1 γk

bitcoins instead of only γi + γj bitcoins in the case hebehaves honestly. We make several observations here.First, the impact of this attack grows with the numberof intermediate users between Ui and Uj as well asthe number of payments that take both Ui and Uj

in their path. While the Lightning Network is at itsinfancy, other well-established networks such as Rippleuse paths with multiple intermediaries. For instance, inthe Ripple network, more than 27% of the payments usemore than two intermediaries [45]. Actually, paths withthree intermediaries (e.g., sender → bank → currency-exchange→ bank→ receiver) are essential for currencyexchanges, a key use case in LN itself [1]. When the LNgrows to the scale of the Internet, routes may consistof several intermediaries as in the Internet today. Giventhese evidences, we expect long paths in the LN.

Second, honest intermediate users cannot triviallydistinguish the situation in which they are under attackfrom the situation where the payment is simply unsuc-cessful (e.g., there are not enough coins in one of thechannels or one of the users is offline). In both cases, theview for the honest users is that the timeout establishedin the HTLC is reached, the payment failed and theyget their initially committed coins reimbursed. In short,the wormhole attack allows an adversary to steal thefees from intermediate honest users without leaving ainculpatory trace to them.

Third, fees are the main incentive for intermediaryusers. The wormhole attack takes away this crucialbenefit. In fact, this attack not only makes honest userslose their fees, but also incur collateral costs: Coinslocked for the payment under attack cannot be used foranother (possibly successful) payment simultaneously.

Responsible Disclosure. We notified this attack to theLN developers and they have acknowledged this issue.Additionally, they have implemented our ECDSA-basedconstruction (see Section V-D) and tested it for itsintegration in the LN, having thereby a fix for thewormhole attack and leveraging its privacy and practicalbenefits [28], [29].

(In)evitability of the Wormhole Attack. The worm-hole attack is not restricted to the LN, but generallyapplies to PCNs with multi-hop payments that involveonly two rounds of communication. We assume a com-munication round to consist of traversing the paymentpath once, either forth (e.g., for setting up the payment)or back (e.g., for releasing the coins). Additionally, weassume that in PCNs the communication between nodesis restricted to their direct neighbors, so in particular,there is no broadcast.1 Consequently, using two roundsof communication for a payment implies that the pay-ment is not preceded by a routing phase in which path-specific information is sent to nodes in the path. Underthese assumptions, we state the lower bound informallyin Theorem 1 and defer the formal theorem and theproof to Appendix A.

1This is the case in the setting of off-chain protocols where usersnot sharing a payment channel do not communicate with each other.

4

Theorem 1 (Informal). For all two-round (withoutbroadcast channels) multi-hop payment protocols thereexists a path prone to the wormhole attack.

In this work we show that adding an additionalround of communication suffices to overcome this im-possibility result.2 In particular, with one additionalround of communication, the sender of a payment cancommunicate path-specific secret information to theintermediate nodes. This information can then be usedto make the release keys unforgeable for an attacker. Thecryptographic protocols we introduce in the remainderof this paper adopt this approach.

IV. DEFINITION

Here we introduce a new cryptographic primitivecalled anonymous multi-hop lock (AMHL). This prim-itive generalizes the locking mechanism used for pay-ments in state-of-the-art PCNs such as the LN. In Sec-tion VII we show that AMHL is the main cryptographiccomponent required to construct fully-fledged PCNs.As motivated in the previous section, we model theprimitive such that it allows for an initial setup phasewhere the first node of the path provides the othernodes with some secret (path-specific) state. Formally,an AMHL is defined with respect to a universe of usersU and it is a five-tuple of PPT algorithms and protocolsL = (KGen,Setup, Lock, Rel, Vf) defined as follows:

Definition 1. An AMHL L = (KGen,Setup, Lock,Rel,Vf) consists of the following efficient algorithms:

{(ski, pk), (skj , pk)} ← 〈KGenUi(1λ),KGenUj

(1λ)〉 :On input the security parameter 1λ the key generationprotocol returns a shared public key pk and a secret keyski (skj , respectively) to Ui and Uj .

{sI0, . . . , (sIn, kn)} ← 〈SetupU0(1λ, U1, . . . , Un),

SetupU1(1λ), . . . , SetupUn

(1λ)〉 : On input a vector ofidentities (U1, . . . , Un) and the security parameter 1λ,the setup protocol returns, for i ∈ [0, n], a state sIi touser Ui. The user Un additionally receives a key kn.

{(`, sRi ), (`, sLi+1)} ← 〈LockUi(sIi , ski, pk),

LockUi+1(sIi+1, ski+1, pk)〉 : On input two initial

states sIi and sIi+1, two secret keys ski and ski+1,and a public key pk, the locking protocol is executedbetween two users (Ui, Ui+1) and returns a lock ` anda right state sRi to Ui and the same lock ` and a leftstate sLi+1 to Ui+1.

k′ ← Rel(k, (sI , sL, sR)) : On input an opening key kand a triple of states (sI , sL, sR), the release algorithmreturns a new opening key k′.

2A malicious sender can still bypass intermediate nodes, but he hasno incentive as it implies stealing coins from himself.

{0, 1} ← Vf(`, k) : On input a lock ` and a key k theverification algorithm returns a bit b ∈ {0, 1}.

Correctness. An AMHL is correct if the verificationalgorithm Vf always accepts an honestly generated lock-key pair. For a more detailed and formal correctnessdefinition, we refer the reader to Appendix B.

Key Ideas. Fig. 2 illustrates the usage of the differentprotocols underlying the AMHL primitive. First, weassume an (interactive) KGen phase that emulates theopening of payment channels that compose the PCN.

In the setup phase (green arrows), the introductionof the initial state at each intermediate user is crucial forsecurity and privacy. Intuitively, we can use this initialstate as “rerandomization factor” to ensure that locks inthe same path are unlinkable for the adversary.

Next, in the locking phase, each pair of users jointlyexecutes the Lock protocol to generate a lock `i. Thecreation of this lock represents the commitment fromUi to perform an application-dependent action if acryptographic problem is solved by Ui+1. In the caseof LN, this operation represents the commitment ofUi to pay a certain amount of coins to Ui+1 if Ui+1

solves the cryptographic condition. Each user also learnssome extra state sRi (resp. sLi+1) that will be needed forreleasing the lock later on. While these extra states arenot present in the LN (i.e., every lock is based on thesame cryptographic puzzle H(R)), they are crucial forsecurity. They make the releasing of different locks inthe path independent and thus ensure that a lock `i canonly be released if `i+1 has been released before.

Finally, after the entire path is locked, the receiverUn can generate a key for releasing its left lock. Then,each intermediate node can derive a valid key for itsleft lock from a valid key for its right lock using theRel algorithm. This last phase resembles the openingphase of the LN where each pair of users settles thenew balances for their deposit at each payment channelin the payment path.

A. Security and Privacy Definition

To model security and privacy in the presenceof concurrent executions we resort to the universalcomposability framework from Canetti [18]. We al-low thereby the composition of AMHLs with otherapplication-dependent protocols while maintaining se-curity and privacy guarantees.

Attacker Model. We model the players in our protocolas interactive Turing machines that communicate witha trusted functionality F via secure and authenticatedchannels. We model the attacker A as a PPT machinethat has access to an interface corrupt(·) that takes as

5

⊥ sI0

sR0

sL1

sI1

sR1 sL

n−1sIn−1

sRn−1 sLn sIn ⊥

Lock ,U0 U1

ℓ0 ℓn−1

kn−1

ℓn−2

kn−2 Release Release

( ,… , )SetupU0U1 Un

U1U0 Un−1 Un

ℓ1

⋯

Lock ,Un−1 Un

Lock ,U1 U2 Lock ,Un−2 Un−1

k1k0 Release kn

Fig. 2: Usage of the AMHL primitive. It is assumed that links between the users on the path have been created upfront (usingKGen) and that the resulting public and secret keys are implicitly given as argument to the corresponding executions of Lock.Otherwise, the inputs (outputs) to (from) the Lock protocol and the Rel algorithm are indicated by blue (orange) arrows.

input a user identifier U and provides the attacker withthe internal state of U . All the subsequent incoming andoutgoing communication of U are then routed throughA. We consider the static corruption model, that is, theattacker is required to commit to the identifiers of theusers he wishes to corrupt ahead of time.3

Communication Model. Communication happensthrough the secure message transmission functionalityFsmt that informs the attacker whenever some commu-nication happens between two users and the attackercan delay the delivery of the message arbitrarily (fora concrete functionality see [18]). We also assumethe existence of a functionality Fanon (see [17] foran example), which provides user with an anonymouscommunication channel. In its simplest form, Fanon isidentical to Fsmt, except that it omits the identifier ofthe sender from the message sent to the receiver. Weassume a synchronous communication network, wherethe execution of the protocol happens in discrete rounds.The parties are always aware of the current round andif a message is created at round i, then it is deliveredat the beginning of the (i + 1)-th round. Our modelassumes that computation is instantaneous. In the realworld, this is justified by setting a maximum time boundfor message transmission, which is known by all users.If no message is delivered by the expiration time, thenthe message is set to be ⊥. We remark that such anassumption is standard in the literature [25] and for anexample of the corresponding ideal functionality Fsyn

we refer the reader to [18], [34].

Universal Composability. Let EXECτ,A,E be the en-semble of the outputs of the environment E when inter-acting with the attacker A and users running protocol τ(over the random coins of all the involved machines).

Definition 2 (Universal Composability). A protocol τUC-realizes an ideal functionality F if for any PPT

3Extending our protocol to support adaptive corruption queries isan interesting open problem.

adversary A there exists a simulator S such thatfor any environment E the ensembles EXECτ,A,E andEXECF,S,E are computationally indistinguishable.

Ideal Functionality. We formally define the idealworld functionality F for AMHLs in the following. Fora more modular treatment, our UC definition modelsonly the cryptographic lock functionality, rather thanaiming at a comprehensive characterization of PCNs.In Section VII we show how one can construct afull PCN (e.g., as defined in [42]) by composing thisfunctionality with time locks, balance updates, andon-chain channel management. For ease of expositionwe assume that each pair of users establishes onlya single link per direction. The model can be easilyextended to handle the more generic case. F worksin interaction with a universe of users U and initial-izes two empty lists (U ,L) := ∅, which are used totrack the users and the locks, respectively. The listL represents a set of lock chains. The entries are ofthe form (lidi, Ui, Ui+1, f, lidi+1) where lidi is a lockidentifier that is unique even among other lock chainsin L, Ui and Ui+1 are the users connected by thelock, f ∈ {Init, Lock,Rel} is a flag that represents thestatus of the lock, and lidi+1 is the identifier of thenext lock in the path. For sake of better readability,we define functions operating on L extracting lock-specific information given the lock’s identifier, such asthe lock’s status (getStatus(·)), the nodes it is connecting(getLeft(·), getRight(·)), and the next lock’s identifier(getNextLock(·)). In addition we define an update func-tion updateStatus(·, ·) that changes the status of a lockto a new flag.

The interfaces of the functionality F are specifiedin Fig. 3. The KeyGen interface allows a user toestablish a link with another user (specifying whetherit wants to be the left or the right part of the link).The Setup interface allows a user U0 to setup a path(starting from U0) along previously established links.The Lock interface allows a user to create a lock with

6

KeyGen(sid, Uj , {L,R})Upon invocation by Ui:sends (sid, Ui, {L,R}) to Ujreceives (sid, b) from Uj

if b = ⊥ send ⊥ to Ui and abortif L insert (Ui, Uj) into U and sends (sid, Ui, Uj) to Uiif R insert (Uj , Ui) into U and sends (sid, Uj , Ui) to Ui

Lock(sid, lid)Upon invocation by Ui:if getStatus(lid) 6= Init or getLeft(lid) 6= Ui then abortsends (sid, lid, Lock) to getRight(lid)receives (sid, b) from getRight(lid)if b = ⊥ send ⊥ to Ui and abortupdateStatus(lid, Lock)sends (sid, lid, Lock) to Ui

GetStatus(sid, lid)Upon invocation by Ui:return (sid, lid, getStatus(lid)) to Ui

Setup(sid, U0, . . . , Un)Upon invocation by U0:if ∀i ∈ [0, n− 1] : (Ui, Ui+1) /∈ U then abort∀i ∈ [0, n− 1]: lidi ←$ {0, 1}λ

insert (lid0, U0, U1, Init, lid1), (lidn−1, Un−1, Un, Init,⊥)into Lsendan (sid,⊥, lid0,⊥, U1, Init) to U0

sendan (sid, lidn−1,⊥, Un−1,⊥, Init) to Un∀i ∈ [1, n− 1]: insert (lidi, Ui, Ui+1, Init, lidi+1) into L

sendan (sid, lidi−1, lidi, Ui−1, Ui+1, Init) to Ui

Release(sid, lid)Upon invocation by Ui:if getRight(lid) 6= Ui or getStatus(lid) 6= Lock or

getStatus(getNextLock(lid)) 6= Rel

and getNextLock(lid) 6= ⊥ then abortupdateStatus(lid, Rel)sends (sid, lid,Rel) to getLeft(lid)

Fig. 3: Ideal functionality for cryptographic locks (AMHLs)

its right neighbor on a previously created path and theRelease algorithm allows a user to release the lockwith its left neighbor, in case that the user is eitherthe receiver or its right lock has been released before.Finally, the GetStatus interface allows one to check thecurrent status of a lock, i.e., whether it is initialized,locked or released. Internally, the locks are assignedidentifiers that are unique across all paths. We definethe interfaces sends and receives to exchange messagesthrough the Fsmt functionality and the interface sendan

to send messages via Fanon.

B. Discussion

We discuss how the security and privacy notions ofinterest for AMHLs are captured by functionality F .

Atomicity. Loosely speaking, atomicity means thatevery user in a path is able to release its left lock incase that his right lock was already released. This isenforced by F as i) it is keeping track of the chainof locks and their current status in the list L and ii)the Release interface of F allows one to release a locklid (changing the flag to Rel) if lid is locked and thefollow-up lock (getNextLock(lid)) was already released.

Consistency. An AMHL is consistent if no attackercan release his left lock without its right lock beingreleased before. This prevents scenarios where someAMHL is released before the receiver is reached and,

more generically, the wormhole attack described in Sec-tion III. To see why our ideal functionality models thisproperty, observe that the Release interface allows a userto release the left lock only if the right lock has alreadybeen released or the user itself is the receiver. In thiscontext, no wormhole attack is possible as intermediatenodes cannot be bypassed.

Relationship Anonymity. Relationship anonymity [12]requires that each intermediate node does not learn anyinformation about the set of users in an AMHL beyondits direct neighbors. This property is satisfied by F asthe lock identifiers are sampled at random and duringthe locking phase a user only learns the identifiers of itsleft and right lock as well as its left and right neighbor.We discuss this further in Appendix D.

V. CONSTRUCTIONS

A. Cryptographic Building Blocks

Throughout this work we denote by 1λ ∈ N+ thesecurity parameter. Given a set S, we denote by x←$Sthe sampling of an element uniformly at random from S,and we denote by x← A(in) the output of the algorithmA on input in. We denote by min(a, b) the function thattakes as input two integers and returns the smaller ofthe two. To favor readability, we omit session identifiersfrom the description of the protocols. In the followingwe briefly recall the cryptographic building blocks ofour schemes.

7

Homomorphic One-Way Functions. A function g :D → R is one-way if, given a random element x ∈ R,it is hard to compute a y ∈ D such that g(y) = x.We say that a function g is homomorphic if D and Rdefine two abelian groups and for each pair (a, b) ∈ D2

it holds that g(a◦ b) = g(a)◦ g(b), where ◦ denotes thegroup operation. Throughout this work we denote thecorresponding arithmetic group additively.

Commitment Scheme. A commitment scheme COMconsists of a commitment algorithm (decom, com) ←Commit(1λ,m) and a verification algorithm {0, 1} ←Vcom(com, decom,m). The commitment algorithm al-lows a prover to commit to a message m withoutrevealing it. In a second phase, the prover can convincea verifier that the message m was indeed committed byshowing the unveil information decom. The security ofa commitment scheme is captured by the standard idealfunctionality Fcom [18].

Non-Interactive Zero-Knowledge. Let R be an NPrelation and let L be the set of positive instances, i.e.,L := {x | ∃w s.t. R(x,w) = 1}. A non-interactivezero-knowledge proof [15] scheme NIZK consists ofan efficient prover algorithm π ← PNIZK(w, x) and anefficient verifier {0, 1} ← VNIZK(x, π). A NIZK schemeallows the prover to convince the verifier about theexistence of a witness w for a certain statement x with-out revealing any additional information. The securityof a NIZK scheme is modeled by the following idealfunctionality FNIZK: On input (prove, sid, x, w) by theprover, check if R(x,w) = 1 and send (proof, sid, x)to the verifier if this is the case.

Homomorphic Encryption. One of the building blocksof our work is the additive homomorphic encryptionscheme HE := (KGenHE,EncHE,DecHE) from Pail-lier [46]. The scheme supports homomorphic opera-tion over the ciphertexts of the form EncHE(pk,m) ·EncHE(pk,m′) = EncHE(pk,m + m′). We assumethat Paillier’s encryption scheme satisfies the notion ofecCPA security, as defined in the work of Lindell [39].

ECDSA Signatures. Let G be an elliptic curve groupof order q with base point G and let H : {0, 1}∗ →{0, 1}|q| be a collision resistant hash function. Thekey generation algorithm KGenECDSA(1λ) samples aprivate key as a random value x←$Zq and sets thecorresponding public key as Q := x · G. To signa message m, the signing algorithm SigECDSA(sk,m)samples some k←$Zq and computes e := H(m). Let(rx, ry) := R = k · G, then the signing algorithmcomputes r := rx mod q and s := e+rx

k mod q.The signature consists of (r, s). The verification algo-rithm VfECDSA(pk, σ,m) recomputes e = H(m) andreturns 1 if and only if (x, y) = e

s · G + rs · Q and

r = x mod q. It is a well known fact that for every

valid signature (r, s), also the pair (r,−s) is a validsignature. To make the signature strongly unforgeablewe augment the verification equation with a check thats ≤ q−1

2 . We assume the existence of an interactiveprotocol ΠECDSA

KGen executed between two users where theone receives (x0, Q, sk), where sk is a Paillier secretkey and Q = x0 · x1 · G, whereas the other obtains(x1, Q,EncHE(pk, x0)), where pk is the correspondingPaillier public-key. For correctness, we require that thePaillier modulus is N = O(q4). We assume that theparties have access to an ideal functionality FECDSA

kgen(refer to Appendix E for a precise definition) that se-curely computes the tuples for both parties. An efficientprotocol has been recently proposed by Lindell [39].

Anonymous Communication. We assume an anony-mous communication channel Πanon available amongusers in the network, which is modelled by the idealfunctionality Fanon. It anonymously delivers messagesto users in the network (e.g., see [17]).

B. Generic Construction

An interesting question related to AMHLs is underwhich class of hard problems such a primitive exists. Ageneric construction using trapdoor permutations wasgiven (implicitly) in [42]. Here we propose a schemefrom any homomorphic one-way function. Examplesof homomorphic one-way functions include discretelogarithm and the learning with errors problem [51].Let g : D → R be a homomorphic one-way func-tion, and let Fanon be the ideal functionality for ananonymous communication channel. The algorithms ofour construction are given in Fig. 4. Note that KeyGensimply returns the users identities and thus it is omitted.

In the setup algorithm, the user U0 initializesthe AMHL by sampling n values (y0, . . . , yn−1)from the domain of g. Then it sends (via Fanon) atriple (g(

∑i−1j=0 yj), g(

∑ij=0 yj), yi) to each interme-

diate user. The intermediate user Ui can then checkthat the triple is well formed using the homomorphicproperties of g. Two contiguous users Ui and Ui+1 canagree on the shared value of `i := Yi = g(

∑ij=0 yj)

by simply comparing the second and first element oftheir triple, respectively. Note that publishing a validopening key k such that g(k) = ` corresponds toinverting the one-way function g. The opening of thelocks can be triggered by the last node in the chainUn: The initial key kn :=

∑n−1i=0 yi consists of a valid

pre-image of `n−1 := Yn−1. As soon as the “right”lock is released, each intermediate user Ui has enoughinformation to release its “left” lock. To see this, observethat g(ki+1 − yi) = g(

∑ij=0 yi − yi) = g(

∑i−1j=0 yi) =

Yi−1. For the security of the construction, we state thefollowing theorem. Due to space constraints, the proofis deferred to Appendix E.

8

SetupUi(1λ) SetupU0

(1λ, U1, . . . , Un) SetupUn(1λ)

y0 ←$DY0 := g(y0)

∀i ∈ [1, n− 1] : yi ←$Dif Yi 6= Yi−1 + g(yi) then abort(Yi−1, Yi, yi)←−−−−−−−− Yi := Yi−1 + g(yi) (Yn−1,kn:=

∑n−1i=0 yi)−−−−−−−−−−−−−−→

return (Yi−1, Yi, yi) return y0 return ((Yn−1, 0, 0), kn)

LockUi(sIi , ski, pk) LockUi+1(s

Ii+1, ski+1, pk)

parse sIi as (Y ′i , Yi, yi) Yi−−−−−−−−→parse si+1 as (Y ′i+1, Yi+1, yi+1)

if Yi 6= Y ′i+1 then abortreturn (Yi,⊥) return (Yi,⊥)

Rel(k, (sI , sL, sR))

parse sI as (Y ′, Y, y)

return k − y

Vf(`, k)

return g(k) = `

Fig. 4: Algorithms and protocols for the generic construction

Theorem 2. Let g be a homomorphic one-way function,then the construction in Fig. 4 UC-realizes the idealfunctionality F in the (Fsyn,Fsmt,Fanon)-hybrid model.

The generic construction presented here requires acryptocurrency supporting scripts that define (linearly)homomorphic operations. This construction is thereforeof special interest in blockchain technologies such asEthereum [4] and Hyperledger Fabric [11], where anyuser can freely deploy a smart contract without re-strictions in the cryptographic operations available. Westress that any function with homomorphic propertiesis suitable to implement our construction. For instance,lattice-based functions (e.g., from the learning witherrors problem) can be used for applications where post-quantum cryptography is required. However, many cryp-tocurrencies, led by Bitcoin, do not support unrestrictedscripts and the deployment of generic AMHLs requiresnon-trivial changes (i.e., a hard fork). To overcome thischallenge, we turn our attention to scriptless AMHLs,where a signature scheme can simultaneously be usedfor authorization and locking.

C. Scriptless Schnorr-based Construction

The crux of a scriptless locking mechanism is thatthe lock can consist only of a message m and a publickey pk of a given signature scheme and can be releasedonly with a valid signature σ of m under pk. Scriptlesslocks stem from an idea of Poelstra [48], who proposeda way to embed contracts into Schnorr signatures. In thiswork we cast Poelstra’s informal idea in our frameworkand we formally characterize its security and privacyguarantees. We further optimize this scheme in order tosave one round of communication.

Recall that a public key in a Schnorr signatureconsists of an element Q := x · G and a signatureσ := (k·G, s) on a message m is generated by samplingk←$Zq , computing e := H(Q‖k · G‖m), and setting

s := k − xe. On a very high level, the locking mecha-nism consists of an “incomplete” distributed signing ofsome message m: Two users Ui and Ui+1 agree on arandomly chosen element R0 +R1 using a coin tossingprotocol, then they set the randomness of the signatureto be R := R0+R1+Yi. Next they jointly compute thevalue s := r0 + r1 + e · (x0 + x1) as if Yi was not partof the randomness, where e is the hash of the transcriptso far. The resulting (R, s) is not a valid signature onm, since the additive term y∗ (where y∗ · G = Yi) ismissing from the computation of s. However, once thediscrete logarithm of Yi is revealed, a valid signature mcan be computed by Ui+1. Leveraging this observation,we can enforce an atomic opening: The subsequentlocking (between Ui+1 and Ui+2) is conditioned onsome Yi+1 = Yi + yi+1 · G. This way, the openingof the right lock reveals the value y∗ + yi+1 and Ui+1

can immediately extract y∗ and open its left lock witha valid signature on m. We defer the formal descriptionand the analysis of the scheme to Appendix C.

D. Scriptless ECDSA-based Construction

The Schnorr-based scheme is limited to cryptocur-rencies that use Schnorr signatures to authorize transac-tions and thus is not compatible with those systems,prominently Bitcoin, that implement ECDSA signa-tures. Therefore, an ECDSA-based scriptless AMHLis interesting both from a practical and a theoreticalperspective as to whether it can be done at all. Priorto our work, the existence of such a construction wasregarded an open question [49]. The core difficulty isthat the Schnorr-based construction exploits the linearstructure of the signature, whereas the ECDSA signingalgorithm completely breaks this linearity feature (e.g.,it requires to compute multiplicative shares of a keyand the inverse of elements within a group). In thefollowing, we show how to overcome these problems,introducing an ECDSA-based construction for AMHLs:Locks are of the form (pk,m) and can only be openedwith an ECDSA signature σ on m under pk.

9

SetupUi(1λ) SetupU0

(1λ, U1, . . . , Un) SetupUn(1λ)

y0 ←$Zq; Y0 = y0 ·G∀i ∈ [1, n− 1] : yi ←$ZqYi := Yi−1 + yi ·G

stmti := {∃y s.t. Yi = y ·G} stmti := {∃y s.t. Yi = y ·G}b← VNIZK(stmti, πi) (Yi−1,Yi,πi)←−−−−−−−− πi ← PNIZK

(∑ij=0 yj , stmti

)(Yn−1,kn:=

∑n−1i=0 yi)−−−−−−−−−−−−−−→

if b = 0 then abortYi := Yi−1 + yi ·Greturn (Yi−1, Yi, yi) return y0 return ((Yn−1, 0, 0), kn)

LockUi(sIi , ski, pk) LockUi+1(s

Ii+1, ski+1, pk)

parse sIi as (Y ′0 , Y0, y0) parse sIi+1 as (Y ′1 , Y1, y1)

parse ski as (x0, skHE) parse ski+1 as (x1, c)

r0 ←$Zq; R0 := r0 ·G; R′0 := r0 · Y0 r1 ←$Zq; R1 := r1 ·G; R′1 := r1 · Y ′1stmt0 := {∃r0 s.t. R0 = r0 ·G and R′0 = r0 · Y0} stmt1 := {∃r1 s.t. R1 = r1 ·G and R′1 = r1 · Y ′1}π0 ← PNIZK(r0, stmt0) π1 ← PNIZK(r1, stmt1)

com←−−(decom, com)← Commit(1λ, (R1, R′1, π1))

(R0,R′0,π0)−−−−−−−→if VNIZK(stmt0, π0) 6= 1 then abort

(rx, ry) := R = r1 ·R′0; ρ←$Zq2if Vcom(com, decom, (R1, R

′1π1)) 6= 1 then abort (decom,R1,R

′1,π1,c

′)←−−−−−−−−−−−−−c

′ := crx(r1)−1x1 · EncHE(pk, H(m)(r1)

−1 + ρq)

if VNIZK(stmt1, π1) 6= 1 then aborts← DecHE(skHE, c

′)

(rx, ry) := R = r0 ·R′1if s ·R1 6= rx · pk+H(m) ·G then abort s′:=s·r−1

0 mod q−−−−−−−−−−→if s′ · r1 ·R0 6= rx · pk+H(m) ·G then abort

return ((m, pk), (s′,m, pk)) return ((m, pk), (rx, s′))

Rel(k, (sI , sL, sR))

parse sI as (Y ′, Y, y), k as (r, s), sL as (w0, w1), sR as (s′,m, pk)

t := w1 · ( s′

s− y)−1; t′ := w1 · (− s

′

s− y)−1

if VfECDSA(pk, (w0,min(t,−t)),m) = 1 return (r,min(t,−t))if VfECDSA(pk, (w0,min(t′,−t′)),m) = 1 return (r,min(t′,−t′))

Vf(`, k)

parse ` as (m, pk)

parse k as (r, s)

return 1 iff (r, ·) = H(m)s·G+ r

s·pk and s ≤ q−1

2

Fig. 5: Algorithms and protocols for the ECDSA-based construction.

Let G be an elliptic curve group of order q withbase point G and let H : {0, 1}∗ → {0, 1}|q| be ahash function. The ECDSA-based construction is shownin Fig. 5. Each pair of users (Ui, Uj) generates ashared ECDSA public key pk = (xi · xj) · G viathe FECDSA

kgen functionality. Additionally, Ui receives aPaillier secret key sk and his share xi, whereas and Ujreceives the share xj and the Paillier encryption c ofxi. The key generation functionality is fully describedin Appendix E.

The setup here is very similar to the setup of thegeneric construction in Fig. 4 except that the one-wayfunction g is now instantiated with discrete logarithmover elliptic curves. Each intermediate user Ui receivesa triple (Yi−1, Yi, yi) such that Yi := Yi−1+yi ·G, fromFanon. For technical reasons, the initiator of the AMHL

also includes a proof of wellformedness for each Yi.

The locking algorithm is initiated by two users Uiand Ui+1 who agree on a message m (which encodes aunique id) and on a value Yi := y∗ ·G of unknown dis-crete logarithm. The two parties then run a coin tossingprotocol to agree on a randomness R = (r0 · r1) · Yi.When compared to the Schnorr instance, the crucialtechnical challenge here is that the randomnesses arecomposed multiplicatively due to the structure of theECDSA signature and therefore, the trick applied inthe Schnorr construction no longer works here. R iscomputed through a Diffie-Hellman-like protocol, wherethe parties exchange r0 · Yi and r1 · Yi and locallyrecompute R. As before, the shared ECDSA signatureis computed by “ignoring” the term Yi, since the partiesare unaware of its discrete logarithm. The corresponding

10

tuple(rx, s

′ := rx·(x0·xi+1)+H(m)r0·r1

)is jointly computed

using the encryption of x0 and the homomorphic prop-erties of Paillier encryption. This effectively means that(rx, s

′) = (rx, s∗ ·y∗), where (rx, s

∗) is a valid ECDSAsignature on m. In order to check the validity of s′,the parties additionally need to exchange the valueR∗ := (r0 · r1) · G = (y∗)−1 · R. The computationof R∗ (together with the corresponding consistencyproof) is piggybacked in the coin tossing. Given R∗,the validity of s′ can be easily verified by both partiesby recomputing it “in the exponent”.

From the perspective of Ui+1, releasing his left lockwithout a key for his right lock implies solving thediscrete logarithm of Yi. On the converse, once theright lock is released, the value y∗ + yi+1 is revealed(where yi+1 is part of the state of Ui+1) and a validsignature can be computed as

(rx,

s′

y∗

). The security of

the construction is established by the following theorem(see Appendix E for a full proof).

Theorem 3. Let COM be a secure commitment schemeand let NIZK be a non-interactive zero knowledge proof.If ECDSA signatures are strongly existentially unforge-able and Paillier encryption is ecCPA secure, then theconstruction in Fig. 5 UC-realizes the ideal functionalityF in the (FECDSA

kgen ,Fsyn,Fsmt,Fanon)-hybrid model.

E. Hybrid AMHLs

We observe that, when instantiated over the sameelliptic curve G, the setup protocols of the Schnorr andECDSA constructions are identical. This means that theinitiator of the lock does not need to know whethereach intermediate lock is computed using the ECDSAor Schnorr method. This opens the doors to hybridAMHLs: Given a unified setup, the intermediate pair ofusers can generate locks using an arbitrary locking pro-tocol. The resulting AMHL is a chaining of (potentially)different locks and the release algorithm needs to beadjusted accordingly. For the case of ECDSA-Schnorrthe user needs to extract the value y∗ from the rightSchnorr signature (R∗, s∗) and his state sR := s′ =s∗−y∗+yi+1 and sI := (Yi, Yi+1, yi+1). Given y∗, hecan factor it out of its left state sL = ((r, s · y∗),m, pk)and recover a valid ECDSA signature.

The complementary case (Schnorr-ECDSA) is han-dled mirroring this algorithm. Similar techniques alsoapply to the generic construction, when the one-wayfunction is instantiated appropriately (i.e., with discretelogarithm over the same curve). This flexibility enablesatomic swaps and cross-currency payments (see Sec-tion VII). The security for the hybrid AMHLs followssimilar to the standard case.

VI. PERFORMANCE ANALYSIS

A. Implementation Details

We have developed a prototypical Python implemen-tation to demonstrate the feasibility of our constructionand evaluate its performance. We have implemented thecryptographic operations required by AMHLs as de-scribed in this work. We have used the Charm library [3]for the cryptographic operations. We have instantiatedECDSA over the elliptic curve secp256k1 (the one usedin Bitcoin) and we have implemented the homomorphicone-way function as g(x) := x ·G over the same curve.Zero-knowledge protocols for discrete logarithms havebeen implemented using Σ protocols [21] and madenon-interactive using the Fiat-Shamir heuristic [27]. Fora commitment scheme we have used SHA-256 modeledas a random oracle [13].

B. Evaluation

Testbed. We conducted our experiments on a machinewith an Intel Core i7, 3.1 GHz and 8 GB RAM. Weconsider the Setup, Lock,Rel and Vf algorithms. We donot consider KGen as we use off-the-shelf algorithmswithout modification. Moreover, the key generation isexecuted only once upon creating a link and thus doesnot affect the online performance of AMHLs. We referto [39] for a detailed performance evaluation of theECDSA key generation. The results of our performanceevaluation are shown in Table I.

Computation Time. We measure the computationtime required by the users to perform the differentalgorithms. For the case of two-party protocols (e.g.,Setup and Lock) we consider the time for the two userstogether. We make two main observations: First, thescript-based construction based on discrete logarithm isfaster than scriptless AMHLs. Second, all the algorithmsrequire computation time of at most 60 milliseconds ona commodity hardware.

Generic Schnorr ECDSASetup Time (ms) 0.3 · n 1 · n 1 · n

Comm (bytes) 96 · n 128 · n 128 · nLock Time (ms) – 2 60

Comm (bytes) 32 256 416Rel Time (ms) – 0.002 0.02

Comm (bytes) 0 0 0Vf Time (ms) – 0.6 0.06

Comm (bytes) 0 0 0Comp Cost (gas) 350849 · n 0 0Lock size (bytes) 32 32 + |m| 32 + |m|Open size (bytes) 32 64 64

TABLE I: Comparison of the resources required to executethe algorithms for the different AMHLs. We denote by n thelength of the path. We denote the negligible computation timesby – (e.g., single memory read). We denote the size of anapplication-dependent message by |m| (e.g., a transaction ina payment-channel network).

11

Communication Overhead. We measure the com-munication overhead as the amount of informationthat users need to exchange during the execution ofinteractive protocols, in particular, Setup and Lock.As expected, the generic construction based on dis-crete logarithm requires less communication overheadthan scriptless constructions. The scriptless constructionbased on ECDSA requires a higher communicationoverhead. This is mainly due to having the signingkey distributed multiplicatively and a more complexstructure of the final signature when compared to theSchnorr approach.

Computation Cost. We measure the computationcost in terms of the gas required by a smart contractimplementing the corresponding algorithm in Ethereum.Naturally, we consider this cost only for the genericapproach based on discrete logarithm. We observe thatsetting up the corresponding contract requires 350849unit of gas per hop. At the time of writing, each AMHLtherefore costs considerably less than 0.01 USD.

Application Overhead. We measure the overheadincurred by the application in terms of the memory re-quired to handle application-dependent data, i.e., infor-mation defining the lock and the opening. In tune withthe rest of measurements, the generic construction basedon discrete logarithms requires the smallest amount ofmemory, both for lock and opening information. Thedifferent scriptless approaches require the same amountof memory from the application.

Scalability. We study the running time and communi-cation overhead required by each of the roles in a multi-hop lock protocol (i.e., sender, receiver and intermediateuser). We consider only the generic approach and theECDSA construction as representative of the scriptlessapproach. In the absence of significant metrics fromcurrent PCNs, we consider a path length of ten hopsas suggested for similar payment networks such as theRipple credit network [41].

Regarding the computation time, the sender requires3ms with the generic approach and 10ms with theECDSA scriptless approach. The computation time atintermediate users remain below 1ms for ECDSA andnegligible with the generic approach as they only haveto check the consistency of the locks with the predeces-sor and the successor, independently of the length of thepath. Similarly, the computation overhead of the receiverremains below 1ms as she only checks if a given key isvalid to open the lock according to the Vf algorithm. Insummary, a non-private payment over a path of 5 userstakes over 600ms as reported in [42]. Extending it withthe constructions presented in this work provides formalprivacy guarantees at virtually no overhead.

Regarding the communication overhead, the sender

must send a message of about 960 bytes for the genericapproach while about 1280 bytes are required insteadif ECDSA scriptless locks are used. Since Sphinx,the anonymous communication network used in theLN, requires padded messages at each node to ensureanonymity, we foresee that every intermediate user mustforward a message of the same size.

Comparing these results with other multi-hop andprivacy-preserving PCNs available in the literature, wemake the following observations. First, the overhead forthe constructions presented in this work are in tune withTeeChain [38], where the overhead per hop is about 0.4ms in a setting where cryptographic operations requiredfor the multi-hop locks have been replaced by a trustedexecution environment. Second, our constructions sig-nificantly reduce the communication and computationoverhead required by multi-hop HTLC [42]: While apayment using multi-hop HTLC requires approximately5 seconds and 17MB of communication, our approachrequires only few milliseconds and less than 1MB.

In summary, the evaluation results show that evenwith an unoptimized implementation, our constructionsoffer significant improvements on computation andcommunication overhead and are ready to be deployedin practice.

VII. APPLICATIONS

A. Payment-Channel Networks

AMHLs can be generically combined with ablockchain B to construct a fully-fledged PCN. Looselyspeaking, the transformation works as follows: In thefirst round the sender sets up the locks running the Setupalgorithm, then each pair of intermediate users executesthe Lock protocol and establishes the following AMHLcontract.

AMHL (Alice, Bob, `, x, t):1) If Bob produces the condition k such that Vf(`, k) =1 before t days, Alice pays Bob x coins.2) If t days elapse, Alice gets back x coins.

Where ` is the output lock and x and t are chosen asspecified in Section II. Note that we have to assumethat B supports the Vf algorithm and time managementin its script language. The rest of the payment isunchanged except that the intermediate users executethe Rel algorithm to extract a valid key k to claim thecorresponding payment. In Appendix F, we provide theexact description of the algorithms and we prove thefollowing theorem.

Theorem 4 (Informal). Let B a secure blockchain andlet L be a secure AMHL, then we can construct a securePCN (as defined in [42]).

12

Note that even though we defined security ofAMHLs in the UC framework, the composition ofmultiple AMHL instances in one protocol as needed forrealizing PCNs does not come for free if those instanceshave shared state. Formally, such shared state can arisefrom the use of a shared KGen algorithm. Consequently,we need to show for the KGen algorithms of thepresented constructions that they behave independentlyover multiple invocations and finally make use of theJUC theorem [19] to obtain the composability result.

This shows that AMHLs are the only cryptographicprimitive (except for the blockchain) needed to constructPCNs. The only limitation is that the blockchain needsto support the verification of the corresponding contractin their scripting language (see the discussion above).For this reason, the scriptless-construction are preferredfor those blockchains where the scripting language doesnot support the evaluation of a homomorphic one-wayfunction (such as Bitcoin).

Application to the Lightning Network. When appliedto the LN, the ECDSA AMHL construction conveysseveral advantages: First, it eliminates the security is-sues existing in the current LN due to the use of theHTLC contract. Second, it reduces the transaction sizeas a single signature is required per transaction. Thishas the benefit of lowering the communication over-head, the transaction fees, and the blockchain memoryrequirements for closing a payment channel. In fact, wehave received feedback from the LN community indi-cating the suitability of our ECDSA-based construction.Moreover, results from the implementation and testingdone by LN developers are available [28], [29].

The applicability of our proposals are not restrictedto the LN or Bitcoin: There exist other PCNs that couldsimilarly take advantage of the scriptless AMHLs pre-sented in this work. For instance, the Raiden Networkhas been presented as a payment channel network forsolving the scalability issue in Ethereum. The adoptionof our ECDSA scriptless AMHLs would bring the samebenefits to the Raiden Network.

B. Atomic Swaps

Assume two users U0 and U1 holding coins in twodifferent cryptocurrencies and want to exchange them.An atomic swap protocol ensures that either the coinsare swapped or the balances are untouched, i.e., the ex-change must be performed atomically. The widely usedprotocol for atomic swaps described in [16] leveragesthe HTLC contract to perform the swap. In a nutshell, anatomic swap can be seen as a multi-hop payment over apath of the form (U0, U1, U0). This approach inherits thesecurity concerns of HTLC contract. Scriptless AMHLsalso enhance this application domain with formallyproven security guarantees.

Additionally, our constructions contribute to thefungibility of the coins, a crucial aspect for any available(crypto)currency. Current protocols rely on transactionsthat are clearly distinguishable from regular payments(i.e., one-to-one payments). In particular, atomic swaptransactions contain the HTLC contract, in contrast toregular transactions. Scriptless AMHLs eliminate thisissue since even atomic swap transactions only requirea single signature from a public key, making them indis-tinguishable from regular payments. Similar argumentsalso apply for multi-hop payments in PCNs.

C. Interoperable PCNs

Among the cryptocurrencies existing today, an in-teresting problem consists in performing a multi-hoppayment where each link represents a payment channeldefined in a different cryptocurrency. In this manner,a user with a payment channel funded in a givencryptocurrency can use it to pay to another user witha payment channel in a different cryptocurrency. Cur-rently, the InterLedger protocol [54] tackles this prob-lem with a mechanism to perform cross-currency multi-hop payments that relies on the HTLC contract, aimingto ensure the payment atomicity across different hops.

However, apart from the already discussed issuesassociated with HTLC, the InterLedger protocol man-dates that all cryptocurrencies implement HTLC con-tracts. This obviously hinders the deployment of thisapproach. Instead, it is possible to use the differentAMHL constructions presented in this work on a singlepath, as described in Section V-E, therefore expandingthe domain of cross-currency multi-hop payments.

VIII. RELATED WORK

A recent work [24] shows a protocol to computean ECDSA signature using multi-party computation.However, it is not as efficient as Lindell’s approach [39].

There exists extensive literature proposing construc-tions for payment channels [22], [23], [37], [50]. Theseworks focus on a single payment channel, and theirextension to PCNs remain an open challenge. Tum-bleBit [33] and Bolt [32] support off-chain paymentswhile achieving payment anonymity guarantees. How-ever, the anonymity guarantees of these approaches arerestricted to single-hop payments and their extension tosupport multi-hop payments remains an open challenge.

State channels [25], [35], [44] and state channelnetworks [26] cannot work with prominent cryptocur-rencies except from Ethereum. TeeChain [38] requiresthe availability of a trusted execution environment ateach user. Instead, our proposal can be seamlesslydeployed today in virtually all cryptocurrencies, includ-ing Ethereum. In addition, AMHL enables operations

13

between different blockchains, which is clearly notthe case for Ethereum-only solutions. If we focus onthe specific setting of payment channels in Ethereum,AMHL is more efficient (i.e., it requires less gasand bytes) as payment conditions are encoded in thesignature and not in additional scripts. Finally, [25],[26] provide a different privacy notion: two endpointscan communicate privately but the intermediate nodesknow that a virtual channel is opened between them.This information is instead concealed with AMHL.Formalizing this privacy leakage and comparing it withour privacy definition is an interesting future work.

The LN has emerged as the most promising ap-proach for PCN in practice. Its current description [6] isbeing followed by several implementations [5], [8], [10].However, these implementations suffer from the securityand privacy issues with PCNs as described in this work.Instead, we provide several constructions for AMHLsthat can be leveraged to have secure and anonymousmulti-hop payments.

Malavolta et al. [42] propose a protocol for secureand anonymous multi-hop payments compatible withthe current LN. Their approach, however, imposes anoverhead of around 5 MB for the nodes in the network,therefore hindering its deployability. Here, we proposeseveral efficient constructions that require only a fewbytes of communication.

In the recent literature, we can find proposals forsecure and privacy-preserving atomic swaps. Tesser-act [14] leverages trusted hardware to perform realtime cryptocurrency exchanges. The Merkleized Ab-stract Syntax Trees (MAST) protocol has been proposedas a privacy solution for atomic swaps [36]. However,MAST relies on scripts that are not available in the ma-jor cryptocurrencies today. Moreover, specific contractsfor atomic swaps hinder the fungibility of the currency:An observer can easily differentiate between a regularpayment and a payment resulting from an atomic swap.

IX. CONCLUSION

We rigorously study the cryptographic core func-tionality for security, privacy, and interoperability guar-antees in PCNs, presenting a new attack on today’sPCNs (the wormhole attack) and proposing a novelcryptographic construction (AMHLs). We instantiateAMHLs in two settings: script-based and scriptless. Inthe script-based setting, we demonstrate that AMHLscan be realized from any (linear) homomorphic opera-tion. In the scriptless setting, we propose a constructionbased on ECDSA, thereby catering the vast majority ofcryptocurrencies deployed today. Our performance eval-uation shows that AMHLs are practical: All operationstake less than 100 milliseconds to run and introduce acommunication overhead of less than 500 bytes.

We show that AMHLs can be combined in a singlepath and are of interest in several applications apartfrom PCNs, such as atomic swaps and interoperablePCNs. In fact, LN developers have implemented andtested AMHL for LN. In the future, we plan to devisecryptographic instantiations of PCNs for the few cryp-tocurrencies not yet covered, most notably Monero.

Acknowledgements. The authors would like to thankElizabeth Stark, Conner Fromknecht and Olaluwa Os-untokun (Lightning Network Labs) for insightful discus-sions on the writeup of this paper. They would also liketo thank Foteini Baldimitsi for her helpful comments onUniversal Composability.

This work has been partially supported by the Na-tional Science Foundation under grant CNS-1719196,the European Research Council (ERC) under the Eu-ropean Unions Horizon 2020 research (grant agreementNo 771527-BROWSEC); by Netidee through the projectEtherTrust (grant agreement 2158) and PROFET (grantagreement P31621); by the Austrian Research Promo-tion Agency through the Bridge-1 project PR4DLT(grant agreement 13808694); by COMET K1 SBA,ABC; by Chaincode Labs and the Austrian ScienceFund (FWF) through the Meitner program; by theGerman research foundation (DFG) through the collab-orative research center 1223; by the German FederalMinistry of Education and Research (BMBF) throughthe project PROMISE (16KIS0763); and by the stateof Bavaria at the Nuremberg Campus of Technol-ogy (NCT). NCT is a research cooperation betweenthe Friedrich-Alexander-Universitat Erlangen-Nurnberg(FAU) and the Technische Hochschule Nurnberg GeorgSimon Ohm (THN).

REFERENCES

[1] “5 potential use cases for bitcoin’s lightning network,” https://tinyurl.com/y6u4tnda.

[2] “Blockchain explorer information,” https://blockchain.info/.[3] “Charm: A framework for rapidly prototyping cryptosystems,”

https://github.com/JHUISI/charm.[4] “Ethereum website,” https://www.ethereum.org/.[5] “Lightning network daemon,” https://github.com/

lightningnetwork/lnd.[6] “Lightning network specifications,” https://github.com/

lightningnetwork/lightning-rfc.[7] “Raiden network,” http://raiden.network/.[8] “A scala implementation of the lightning network,” https://

github.com/ACINQ/eclair.[9] “Stress test prepares visanet for the most

wonderful 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.

[10] “c-lightning – a lightning network implementation in c,” Acce-ses in May 2018, https://github.com/ElementsProject/lightning.

14

[11] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Chris-tidis, A. D. Caro, D. Enyeart, C. Ferris, G. Laventman,Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen,M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou,M. Vukolic, S. W. Cocco, and J. Yellick, “Hyperledger fabric:A distributed operating system for permissioned blockchains,”in EuroSys, 2018, pp. 30:1–30:15.

[12] M. Backes, A. Kate, P. Manoharan, S. Meiser, and E. Moham-madi, “Anoa: A framework for analyzing anonymous commu-nication protocols,” in CSF, 2013, pp. 163–178.

[13] M. Bellare and P. Rogaway, “Random oracles are practical: Aparadigm for designing efficient protocols,” in CCS, 1993.

[14] I. Bentov, Y. Ji, F. Zhang, Y. Li, X. Zhao, L. Breidenbach,P. Daian, and A. Juels, “Tesseract: Real-time cryptocurrencyexchange using trusted hardware,” in ePrint Archive, 2017, p.1153. [Online]. Available: http://eprint.iacr.org/2017/1153

[15] M. Blum, P. Feldman, and S. Micali, “Non-interactive zero-knowledge and its applications,” in Symposium on Theory ofComputing, 1988, pp. 103–112.

[16] S. Bowe and D. Hopwood, “Hashed time-locked contract trans-actions,” Bitcoin Improvement Proposal, https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki.

[17] J. Camenisch and A. Lysyanskaya, “A formal treatment ofonion routing,” in CRYPTO, 2005.

[18] R. Canetti, “Universally composable security: A new paradigmfor cryptographic protocols,” in FOCS, 2001, pp. 136–.

[19] R. Canetti and T. Rabin, “Universal composition with jointstate,” in Annual International Cryptology Conference, 2003,pp. 265–281.

[20] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels,A. Kosba, A. Miller, P. Saxena, E. Shi, E. Gun Sirer, D. Song,and R. Wattenhofer, “On Scaling Decentralized Blockchains,”in FC, 2016, pp. 106–125.

[21] I. Damgard, “On σ-protocols,” Lecture Notes, University ofAarhus, Department for Computer Science, 2002.

[22] C. Decker, R. Russel, and O. Osuntokun, “eltoo: A simplelayer2 protocol for bitcoin,” https://blockstream.com/eltoo.pdf.

[23] C. Decker and R. Wattenhofer, “A fast and scalable paymentnetwork with bitcoin duplex micropayment channels,” in Sta-bilization, Safety, and Security of Distributed Systems, 2015.

[24] J. Doerner, Y. Kondi, E. Lee, and a. shelat, “Secure two-partythreshold ecdsa from ecdsa assumptions,” in S&P, 2018.

[25] S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski,“Perun: Virtual payment hubs over cryptocurrencies,” in ePrint,2017. [Online]. Available: https://eprint.iacr.org/2017/635

[26] S. Dziembowski, S. Faust, and K. Hostakova, “General statechannel networks,” in CCS, 2018.

[27] A. Fiat and A. Shamir, “How to prove yourself: Practical solu-tions to identification and signature problems,” in Conferenceon the Theory and Application of Cryptographic Techniques,1986.

[28] C. Fromknecht, “Instantiating scriptless 2p-ecdsa: fungi-ble 2-of-2 multisigs for bitcoin today,” Talk at Scaling-Bitcoin 2018, https://tokyo2018.scalingbitcoin.org/transcript/tokyo2018/scriptless-ecdsa.

[29] ——, “tpec: 2p-ecdsa signatures,” Github repository, https://github.com/cfromknecht/tpec.

[30] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Securedistributed key generation for discrete-log based cryptosys-tems,” Journal of Cryptology, vol. 20, no. 1, pp. 51–83, 2007.

[31] S. Goldwasser, S. Micali, and R. L. Rivest, “A digital signaturescheme secure against adaptive chosen-message attacks,” SIAMJournal on Computing, vol. 17, no. 2, pp. 281–308, 1988.

[32] M. Green and I. Miers, “Bolt: Anonymous payment channelsfor decentralized currencies,” in CCS, 2017.

[33] E. Heilman, L. Alshenibr, F. Baldimtsi, A. Scafuro, andS. Goldberg, “TumbleBit: An untrusted bitcoin-compatibleanonymous payment hub,” in NDSS, 2017.

[34] J. Katz, U. Maurer, B. Tackmann, and V. Zikas, “Universallycomposable synchronous computation,” in Theory of cryptog-raphy, 2013, pp. 477–498.

[35] R. Khalil and A. Gervais, “Revive: Rebalancing off-blockchainpayment networks,” in CCS, 2017, pp. 439–453.

[36] J. Lau, “Merkelized abstract syntax tree,” Bitcoin ImprovementProposal, https://tinyurl.com/yc9jh6lv.

[37] J. Lind, I. Eyal, P. R. Pietzuch, and E. G. Sirer, “Teechan:Payment channels using trusted execution environments,” 2016,http://arxiv.org/abs/1612.07766.

[38] J. Lind, O. Naor, I. Eyal, F. Kelbert, P. R. Pietzuch, and E. G.Sirer, “Teechain: Reducing storage costs on the blockchain withoffline payment channels,” in Systems and Storage Conference,2018, p. 125.

[39] Y. Lindell, “Fast Secure Two-Party ECDSA Signing,” inCRYPTO, 2017, pp. 613–644.

[40] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, andP. Saxena, “A secure sharding protocol for open blockchains,”in CCS, 2016, pp. 17–30.

[41] G. Malavolta, P. Moreno-Sanchez, A. Kate, and M. Maffei,“SilentWhispers: Enforcing security and privacy in credit net-works,” in NDSS, 2017.

[42] G. Malavolta, P. Moreno-Sanchez, A. Kate, M. Maffei, andS. Ravi, “Concurrency and privacy with payment-channel net-works,” in CCS, 2017.

[43] P. McCorry, M. Moser, S. F. Shahandashti, and F. Hao, “To-wards bitcoin payment networks,” in ACISP, 2016.

[44] A. Miller, I. Bentov, R. Kumaresan, and P. McCorry, “Sprites:Payment channels that go faster than lightning,” in FC, 2019.

[45] P. Moreno-Sanchez, N. Modi, R. Songhela, A. Kate, andS. Fahmy, “Mind your credit: Assessing the health of the ripplecredit network,” in WWW, 2018, pp. 329–338.

[46] P. Paillier, “Public-key cryptosystems based on composite de-gree residuosity classes,” in International Conference on theTheory and Applications of Cryptographic Techniques, 1999,pp. 223–238.

[47] A. Pfitzmann and M. Hansen, “A Terminologyfor Talking about Privacy by Data Minimization:Anonymity, Unlinkability, Undetectability, Unobservability,Pseudonymity, and Identity Management,” https://dud.inf.tu-dresden.de/literatur/Anon Terminology v0.34.pdf, Aug. 2010,v0.34.

[48] A. Poelstra, “Lightning in scriptless scripts,” Mailing list post,https://lists.launchpad.net/mimblewimble/msg00086.html.

[49] ——, “Scriptless scripts,” Presentation slides,https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-05-milan-meetup/slides.pdf.

[50] J. Poon and T. Dryja, “The bitcoin lightning network: Scalableoff-chain instant payments,” Technical Report, https://lightning.network/lightning-network-paper.pdf.

[51] O. Regev, “On lattices, learning with errors, random linearcodes, and cryptography,” Journal of the ACM, vol. 56, no. 6,p. 34, 2009.

[52] S. Roos, P. Moreno-Sanchez, A. Kate, and I. Goldberg, “Set-tling payments fast and private: Efficient decentralized routingfor path-based transactions,” in NDSS, 2018.

[53] C.-P. Schnorr, “Efficient signature generation by smart cards,”Journal of cryptology, vol. 4, no. 3, pp. 161–174, 1991.

15

[54] E. S. Stefan Thomas, “A Protocol for Interledger Payments,”Whitepaper, https://interledger.org/interledger.pdf.

[55] P. Wuille, “Schnorr Bitcoin Improvement Proposal,” https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki.

APPENDIX

A. Wormhole Attack

In this section, we first describe generically thewormhole attack. We then formally prove that no two-round multi-hop payment in a payment-channel network(without broadcasts) is robust against this attack.

First, we give a model for such two-round multi-hoppayments that is capturing existing two-round construc-tions such as the standard HTLC-based construction asit is presented in [42]. As we are only interested inthe underlying locking mechanism of PCNs, we omitinformation on channel capacities and fees and simplymodel PCNs as graphs of the form G = (V,E).

For arguing about the communication in protocols,we formally state the notions of a path in a PCN as wellas of a communication round along a path.

Definition 3 (Path in a PCN). Let G = (V,E) be aPCN. We call a vector (u1, . . . , un) of users a path inG if it holds for all i ∈ [1, n− 1] that (ui, ui+1) ∈ E

In the following, we represent a message from u1to u2 with content m as a tuple M = 〈u1,m, u2〉.Intuitively, one round of communication in a PCN al-lows for the consecutive execution of pairwise protocolsalong a path. This is formally captured by the followingdefinition:

Definition 4 (Communication round in PCNs). LetG = (V,E) be a PCN and let π = (u1, . . . , un) bea path in G with length longer than one. We we call avector of consecutive messages (M1, . . . ,Ml) a roundof communication along π if the following conditionshold:

1) M1 = 〈u1,m, u2〉 for some message m

2) for all i ∈ [1; l] it holds that either

a) Mi = 〈uj ,m, uj+1〉 or

b) Mi = 〈uj+1,m, uj〉 for some j ∈ [1;n− 1] andsome message m

3) for all i ∈ [1; l − 1] it holds that if Mi =〈uj ,mi, uk〉 then either

a) Mi+1 = 〈uk,m, uj〉 or

b) Mi+1 = 〈umax (j,k),m, umax (j,k)+1〉 for somemessage m

Here condition 1) ensures that a round always startswith a message of the first user in the path to itsright neighbor. Condition 2) makes sure that messagescan only be exchanged between neighbors in the path.Finally, condition 3) encodes that every message in apath can either be followed by a message in the reverseddirection (in case that a protocol between two neighborsis performed) or alternatively a protocol between thenext two neighboring nodes is initiated (by the ,right’party in the former protocol now sending a messageto its right neighbor). Together these definitions ensurethat only pairwise protocols can be performed and oncethat they need to be carried out consecutively along thepath.

For describing the essence of the wormhole attack,we use an abstract view on payments in PCNs where weassume payments along a path π to consist of a commit-ment phase and a releasing phase. In the commitmentphase (which constitutes a communication round alongπ), pairwise locks (e.g. HTLCs) between the partiesalong the payment path are created in pairwise lockingprotocols between the neighboring nodes.

Definition 5 (Commitment phase in a PCN). Let G =(V,E) be a PCN and let π = (u1, . . . , un) be a path inG. A protocol encompassing one communication roundalong π is called a commitment phase along π if as aresult each user ui (for i ∈ [1;n]) learns some (shared)pieces of commitment information `i,i+1, `i−1,i (with`n,n+1 and `0,1 being empty). We call {`i,i+1}i∈1,n−1the output of the commitment phase.

In the releasing phase, starting from the payment’sreceiver, keys for ’opening’ the locks are released (asthe condition R in the lightning network). The releasingphase thereby consists of a communication round alongrev(π) (the reversal of π). These keys should satisfy theproperty that each path node can – given a valid key foran outgoing lock – derive a key for it’s incoming lock.

Definition 6 (Releasing phase in a PCN). Let G =(V,E) be a PCN and let π = (u1, . . . , un) be a pathin G. Further let C be a commitment phase along πand Vf be a boolean function taking two arguments.Additionally, let π′ be a subpath of π. A protocolencompassing one communication round along rev(π′)is called a releasing phase for C along rev(π′) if as aresult, each user ui in π′ learns some information ki−1,isuch that Vf(`i−1,i, ki−1,i) = 1.

With the notion of a subpath being defined asfollows:

Definition 7 (Subpath). Let G = (V,E) be a PCN andlet π = (u1, . . . , un) be a path in G. A path π′ =(u1, . . . , um) is considered a subpath of π if for allui in π′ there are paths πi (for i ∈ [0;m]) such that

16

π = π0 · (u1) · π1 · (u2) · π2 ˙. . .πm−1 · (um) · πm (where· denotes path concatenation).

Note that we assume communication to be restrictedto nodes connected by a direct link in the PCN (asensured by 4). This prevents that besides the specifiedmessages in the releasing phase, keys can be sent toprevious nodes in the path (e.g., via broadcast).

Figure 6 shows the payment from Alice to Edward inthe abstract setting. Initially, Edwards gives a trapdoor tto Alice. Using this, Alice starts the commitment phaseby creating the lock `A,B with Bob. To this end, Aliceand Bob might use their secret local states sA and sB .In the same fashion all following pairwise locks arecreated in the commitment phase till reaching Edward.Edward then starts the releasing phase by using thetrapdoor he initially sent to Alice for creating the keykD,E for opening lock `D,E . From this key (and theinformation learned in the commitment phase), Davecan derive key kC,D. In this fashion the whole lockchain can be released.

Note that in the setting of only two rounds ofcommunication (one along the payment path π andone along the reversed payment path rev(π)), the initialsecret local states of the users involved in a payment arecompletely independent from π and consequently fromthe local states of the other nodes in the path. This is asnone of the users received any path-specific informationupfront.

As a consequence, two nodes ui and uj (with1 < i + 1 < j) on a payment path can excludeintermediate nodes uk (with i < k < j) from taking partin the releasing phase as follows: After completing thecommitment phase in an honest fashion, the releasingphase proceeds honestly till reaching uj . At this point ujcan derive a key kj−1,j for releasing the lock `j−1,j with(honest) user uj−1. Instead of releasing this lock, ujforwards kj−1,j to ui which again can use this key forproducing a valid key for lock `i−1,i with its predecessorui−1. This is possible as no secret information from thenodes {uk}i<k<j is required for generating a valid keyfor li−1,i. Otherwise also opening the final lock wouldalready require secret information from some intermedi-ate nodes. As these pieces of secret information from the

Alice ) (sA

Bob ( ) sB

Carol ( ) sC

Dave ( ) sD

Edward ( ) sE

2. ℓA,B

1. t

9. kA,B 8. kB,C 7. kC,D 6. kD,E

3. ℓB,C 4. ℓC,D 5. ℓD,E

Fig. 6: Illustration of the abstract locking mechanism under-lying payments in PCNs

intermediate nodes are however completely unrelatedto the path and consequently from the trapdoor t eventhe receiver could not earn the necessary knowledgefrom the trapdoor for opening the last lock. So finally,node ui can release lock `i−1,i and consecutively all re-maining locks can be released without contacting nodes{uk}i<k<j at all. Together with the assumption thatnodes {uk}i<k<j cannot receive information throughother channels than the direct communication with theirimmediate neighbors in the path and the fact that keysfor locks can only be derived from the initial key, thereis no way for nodes {uk}i<k<j to open the locks withtheir successors in the path.

1) Inevitability of wormhole attacks in two-roundpayment protocols: In PCNS, payments that only en-compass two rounds of communication are inevitablyvulnerable to wormhole attacks. 4 More specifically,this means that when no path-specific information wascommunicated to the intermediate nodes of the paymentpath before performing the payment, nodes locatedbetween two corrupted users in the path can always bebypassed in the releasing phase. This situation occurs incases where the path is not known upfront, but routingis performed dynamically (e.g., [52]).

We formally prove the following theorem:

Theorem 5. Let G = (V,E) be a PCN and let π =(u1, . . . , un) be a path in G with length longer thantwo. Further, let ui, uj be nodes in π for some 0 <i < j ≤ n and let π′ = (u1, . . . , ui, uj , . . . , un) be thepath omitting the nodes between ui and uj . Assume thatu1 and un share initial common knowledge t while allother nodes do not have any initial shared knowledge.Then each payment along π that is carried out by aprotocol P consisting of a commitment phase C alongπ and a releasing phase along rev(π) for C, can alsobe carried out by a protocol P ′ consisting of C and areleasing phase for C along rev(π′) given that ui anduj collude. Additionally, for all users uk with i < k < j,P ′ is indistinguishable from the protocol only consistingof C.

Proof: Let G = (V,E) be a PCN and let π =(u1, . . . , un) be a path in G with length longer thantwo. Further, let ui, uj be nodes in π for some 0 <i < j ≤ n and let π′ = (u1, . . . , ui, uj , . . . , un) be thepath omitting the nodes between Ui and Uj . Assumea payment along the path π with u1 being the senderand un being the receiver. Without loss of generality,assume ui and uj to be controlled by the attacker andall other nodes on the path to be honest. We show that

4Note that we assume here PCNs of the previously describedstructure hence requiring that payments encompass a commitmentand a revealing phase and communication to be restricted to directneighbors.

17

the view of honest nodes ul with l < i or l > j in thescenario of ui and uj performing a wormhole attack ona successful payment don’t differ from the view in thescenario of a successful payment. More precisely, weshow how to construct a one-round successful releasingphase along rev(π′), where successful means that eachuser in π′ can derive a valid key for its outgoing locks.

In addition, we show that the view of honest nodesum with i < m < j in the scenario of the wormholeattack do not differ from their view in the scenario ofan unsuccessful payment. More formally, we show thatit is indistinguishable for those nodes whether the one-round releasing phase was omitted or carried out alongrev(π′).

To this end, we first show how an attacker can sim-ulate the behavior of the nodes ui+1, . . . , uj−1 withoutchanging the view of the honest nodes ul with l < i orl > j.

In the commitment phase, the locks along the pathπ have been created correctly. In the locking protocolbetween ul and ui, ui behaves honestly and conse-quently ul’s view is the same as in the honest case.In parallel to starting the locking protocol between uiand ui+1, the attacker locally simulates the lockingprotocols for the user’s ui+1, . . . , uj and creates simu-lated locks `i+1, . . . , `j . This is possible as by samplingrandom local states for those nodes, the attacker can runthe locking protocol locally. Finally, uj can continuethe commitment phase in an honest manner using asown local state the one resulting from the simulatedcommitments. This cannot be distinguished by nodeuj+1 as it’s own local state is unrelated to the localstates of the other intermediate nodes.

As we consider the case of a successful payment,the releasing phase will be performed honestly by nodesun, . . . uj+1. When uj+1 releases the lock between ujand uj+1 with key kj , then the attacker can simulatereleasing the locks `j−1, . . . , `i locally without pub-lishing the corresponding keys. This is possible as theattacker can use the local states of the intermediatenodes ui+1, . . . , uj−1 from the simulated commitmentphase for deriving keys kj−1, . . . , ki−1. As ki−1 ishence also a valid key for the honestly created lock li−1,the releasing phase can from this point be concluded inan honest manner.

Finally, we can observe that nodes ui+1, . . . , uj−1are not contacted at all in the releasing phase of thepayment which is the same as in the case that thepayment was unsuccessful, i.e., the releasing phase wasnot initiated by the receiver at all.

B. AMHLs Correctness

In this section, we define the notion of correctnessfor AMHLs.

Definition 8 (Correctness of AMHLs). Let L be aAMHL, λ ∈ N+ and n ∈ poly(λ). Let (U0, . . . , Un) ∈Un be a vector of users, (sk0, . . . , skn−1) and(sk∗1, . . . , sk

∗n) two vectors of private keys and

(pk0, . . . , pkn−1) a vector of shared public keys suchthat for all 0 ≤ i < n, it holds that

{(ski, pki), (sk∗i+1, pki)} ← 〈KGenUi

(1λ),KGenUi+1(1λ)〉.

Let (sI0, . . . , sIn) be vector of initial states and kn be a

key such that for all 0 ≤ i < n

{sI0, . . . , (sIn, kn)} ←

⟨SetupU0

(1λ, U1, . . . , Un). . .

SetupUn(1λ)

⟩Furthermore, let (`0, . . . , `n−1) be a vector of locks,(sL1 , . . . , s

Ln) and (sR0 , . . . , s

Rn−1) vectors of states, and

(k0, . . . , kn−1) a vector of keys such that for all 0 ≤i < n, it holds that

{(`i, sRi ), (`i, sLi+1)} ←

⟨LockUi(s

Ii , ski, pki)

LockUi+1(sIi+1, sk

∗i+1, pki)

⟩and

ki ← Rel(ki+1, (sIi+1, s

Li+1, s

Ri+1))

where sRn is ⊥. We say that L is correct if there existsa negligible function negl such that for all 0 ≤ i < n itholds that

Pr [Vf(`i, ki) = 1] ≥ 1− negl(λ).

C. Schnorr-based Scriptless Construction

In the following we cast the idea of Poelstra [48] inour framework.

Schnorr Signatures. Let G be an elliptic curve groupof order q with base point G and let H : {0, 1}∗ →{0, 1}|q| be a collision resistant hash function (modeledas a random oracle). The key generation algorithmKGenschnorr(1

λ) of a Schnorr signature [53] samplessome x←$Zq and sets the corresponding public keyas Q := x · G. To sign a message m, the sign-ing algorithm Sigschnorr(sk,m) samples some k←$Zq ,computes e := H(Q‖k · G‖m), sets s := k − xe, andreturns σ := (R, s), where R := k ·G. The verificationVfschnorr(pk, σ,m) returns 1 if and only if s · G =R +H(Q‖R‖m) ·Q. Schnorr signatures are known tobe strongly unforgeable against the discrete logarithmassumption [31]. We assume the existence of a 2-partyprotocol Πschnorr

KGen where the two players, on input x0 andx1, set a shared public key Q := (x0 + x1) ·G. Such aprotocol can be implemented using standard techniques

18

LockUi(sIi , ski, pk) LockUi+1(s

Ii+1, ski+1, pk)

parse sIi as (Y ′0 , Y0, y0) parse sIi+1 as (Y ′1 , Y1, y1)

r0 ←$Zq r1 ←$ZqR0 := r0 ·G R1 := r1 ·Gπ0 ← PNIZK(r0, {∃r0 s.t. R0 = r0 ·G}) π1 ← PNIZK(r1, {∃r1 s.t. R1 = r1 ·G})

com←−−(decom, com)← Commit(1λ, (R1, π1))(R0,π0)−−−−−→b1 ← VNIZK({∃r0 s.t. R0 = r0 ·G}, π0)

if b1 = 0 then aborte := H(pk‖R0 +R1 + Y ′1‖m)

if Vcom(com, decom, (R1, π1)) 6= 1 then abort (decom,R1,π1,s)←−−−−−−−−−−s := r1 + e · ski+1 mod qb0 ← VNIZK({∃r1 s.t. R1 = r1 ·G}, π1)

if b0 = 0 then aborte := H(pk‖R0 +R1 + Y0‖m)

if s ·G 6= R1 + e · (pk− ski ·G) then aborts′ := s+ r0 + e · ski mod q s′−→if s′ ·G 6= R0 +R1 + e · pk then abortreturn ((m, pk), s′) return ((m, pk), (R0 +R1 + Y ′1 , s

′))

Rel(k, (sI , sL, sR))

parse sI as (Y ′, Y, y)

parse k as (R, s)

parse sL as (W0, w1)

w := w1 + s− (sR + y)mod q

return (W0, w)

Vf(`, k)

parse ` as (m, pk)

parse k as (R, s)

e := H(pk‖R‖m)

return s ·G = R+ e · pk

Fig. 7: Algorithms and protocols for the Schnorr-based construction. The Setup protocol is as defined in Fig. 5.

and we denote the corresponding ideal functionality byF schnorr

kgen .

Description. Let G be an elliptic curve group of orderq with base point G and let H : {0, 1}∗ → {0, 1}|q|be a hash function. The Schnorr-based constructionis formally described in Fig. 7. The key generationalgorithm consists of a call to the F schnorr

kgen functionality.At the end of a successful run, Ui receives (xi, pk)whereas Uj obtains (xj , pk), where pk := (xi+xj) ·G.The setup of a AMHL is identical to the ECDSA-basedconstruction and can be found in Fig. 5.

Prior to the locking phase, two users Ui and Ui+1

(implicitly) agree on the value Yi and on a message mto be signed. Each message is assumed to be uniquefor each session (e.g., contains a transaction identifier).The locking algorithm consists of an “incomplete” dis-tributed signing of m. First, the two parties agree ona randomly chosen element R0 + R1 using a standardcoin tossing protocol, then they set the randomness ofthe signature to be R := R0 +R1 +Yi. Note that at thispoint the parties cannot complete the signature sincethey do not know the discrete logarithm of Yi. Instead,

they jointly compute the value s := r0+r1+e·(x0+x1)as if Yi was not part of the randomness, where e is thehash of the transcript so far. The resulting (R, s) is not avalid signature on m, since the additive term y∗ (wherey∗ · G = Yi) is missing from the computation of s.However, rearranging the terms, we have that (R, s+y∗)is a valid signature on m. This implies that, once thediscrete logarithm of Yi is revealed, a valid signature mcan be computed by Ui+1. Leveraging this observation,Ui+1 can enforce an atomic opening: The subsequentlocking (between Ui+1 and Ui+2) is conditioned onsome Yi+1 = Yi + yi+1 · G. This way, the openingof the right lock reveals the value y∗ + yi+1 and Ui+1

can immediately extract y∗ and open its left lock witha valid signature on m. The security of the constructionis shown by the following theorem. We refer the readerto Appendix E for a full proof.

Theorem 6. Let COM be a secure commitment scheme,and let NIZK be a non-interactive zero knowledge proof.If Schnorr signatures are strongly existentially unforge-able, then the construction in Fig. 7 UC-realizes theideal functionality F in the (F schnorr

kgen ,Fsyn,Fsmt,Fanon)-hybrid model.

19

D. Comparison of Privacy Notions and Guarantees

In this section we discuss our notion of relationshipanonymity as the privacy notion of interest for PCNsand compare it with other possible privacy notionsdescribed in the literature related to PCN.

Our privacy model faithfully captures the realityof currently deployed PCN. In particular, Malavolta etal. [42] showed that it captures the well established no-tion of relationship anonymity. In a nutshell, relationshipanonymity [47] requires that, given two simultaneoussuccessful payment operations between sender{0,1} andreceiver{0,1} that share the same path with at least onehonest intermediate user, corrupted intermediate userscannot determine the correct pair (senderb, receiverb)for a given payment with probability better than 1/2(i.e., guessing). Note that this holds only for paymentsof the same value, since such an information is triviallyleaked to intermediate users, i.e., each user can monitorhow adjacent links evolve and infer the amount that wastransferred.

An alternative privacy notion is described inBOLT [32]. There, authors propose payment anonymity.Intuitively, payment anonymity requires that the mer-chant, even in collaboration with a set of maliciouscustomers, learns nothing about a customer’s spendingpattern beyond the information available outside thepayment protocol.

While this privacy notion additionally hides thevalue that is transacted, it is restricted to single-hoppayments and does not consider the crucial aspect ofconditional payment required when more than one in-termediate user takes part in the payment. As discussedin Section III, many well-established networks use pathswith multiple intermediaries and it is reasonable toexpect long paths also in the LN. To obtain the bestof both worlds, one could envision a protocol whereprivate one-hop payments are performed “at the edges”(i.e., between sender and first hop as well as betweenlast hop and the receiver) while the rest of intermediateusers carry out a multi-hop payment a la LN.

However, this approach raises several questions.First, it is unclear whether the hypothetical resultingprivacy guarantees are stronger or weaker than thosepresented in this work. It is possible that the naıvecombination of the two systems would completely breakdown the guarantees of both schemes. Techniques pre-sented in both works might be required to develop anew system. Second, BOLT requires a blockchain sup-porting a rich scripting language and it is therefore notcompatible with prominent cryptocurrencies (such asBitcoin). Thus, making this system Bitcoin-compatiblewould require fundamentally new techniques.

In summary, although it seems to be an interesting

research direction, further work is required to study thisapproach and its privacy properties.

E. Security Analysis

Throughout the analysis we denote by poly(λ) anyfunction that is bounded by a polynomial in λ. Wedenote any function that is negligible in the securityparameter by negl(λ). We say that an algorithm is PPTif it is modelled as a probabilistic Turing machine whoserunning time is bounded by some function poly(λ).

In the following we recall the (non standard) idealfunctionalities that our protocols build on and we elab-orate on the security analysis of our constructions. Westress that the copies of these functionality that areinvoked as subroutines are fresh independent instancesand therefore the composition theorem [18] directlyapplies to our settings.

Key Generation Functionalities. Our ideal function-ality for key generation of Schnorr signatures F schnorr

keygenprovides the users with the interface described below.This essentially models a distributed key generation fordiscrete logarithm-based schemes, which is a very well-studied problem (see, e.g., [30]).

KeyGen(G, G, q)Upon invocation by both U0 and U1 on input (G, G, q):sample x←$Zq and compute Q = x ·Gset skU0,U1 = x

sample x0 and x1 randomly

sample a hash function H : {0, 1}∗ → {0, 1}|q|

send (x0, Q,H) to U0 and (x1, Q,H) to U1

ignore future calls by (U0, U1)

Our ideal functionality for key generation of ECDSAFECDSA

keygen is taken almost in verbatim from [39] and it isgiven in the following.

KeyGen(G, G, q)Upon invocation by both U0 and U1 on input (G, G, q):sample x←$Zq and compute Q = x ·Gsample x0 and x1 randomly

sample a hash function H : {0, 1}∗ → {0, 1}|q|

sample a key pair (skU0,U1 , pkU0,U1)← KGenHE(1

λ)

compute c← EncHE(pk, r) for a random r

send (x0, Q,H, sk) to U0 and (x1, Q,H, c) to U1

ignore future calls by (U0, U1)

Generic Construction. Here we elaborate on the proofof Theorem 2.

Proof:

20

We define the following sequence of hybrids, wherewe gradually modify the initial experiment.

H0 : Is identical to the protocol as described in Sec-tion V-B.

H1 : Consider the following ensemble of variables inthe interaction with A: A honest user Ui, a key pair(ski, pk), a state sI , a tuple (`i, `i+1, s

L, sR) such that

{·, (`i, sL)} ← 〈·, LockUi(sI , ski, pk)〉

and

{(`i+1, sR), ·} ← 〈LockUi

(sI , ski, pk), ·〉.

If, for any set of these variables, the adversaryreturns some k such that Vf(`i+1, k) = 1 andVf(`i,Rel(k, (s

I , sL, sR))) 6= 1, then the experimentaborts.

H2 : Consider the following ensemble of variables inthe interaction with A: A pair of honest users (U0, Ui)a set of (possibly corrupted) users (U1, . . . , Un), a keypair (ski, pk), a set of initial states

(sI0 . . . , sIn)←

⟨SetupU0

(1λ, U1, . . . , Un),. . . ,

SetupUn(1λ)

⟩,

and a pair of locks (`i−1, `i) such that

{·, (`i−1, ·)} ← 〈·, LockUi(sIi , ski, pk)〉

and{(`i, ·), ·} ← 〈LockUi

(sIi , ski, pk), ·〉.

If, for any set of these variables, the adversary returnssome ki−1 such that Vf(`i−1, ki−1) = 1 before the userUi outputs a key ki such that Vf(`i, ki) = 1, then theexperiment aborts.

H3 : Let S = (U0, . . . , Um) be an ordered set of(possibly corrupted) users. We say that that an orderedsubset A = (U1, . . . , Uj) is adversarial if Ui is honestand (Ui+1, . . . , Uj) are corrupted. Note that every set ofusers can be expressed as a concatenation of adversarialsubsets, that is S = (A1|| . . . ||Am′), for some m′ ≤ m.Whenever a honest user is requested to set up a lockfor a certain set S = (A1|| . . . ||Am′), it initializesan independent lock for each subset (Ai, A

0i+1), where

A0i+1 is the first element of the (i+1)-th set, if present.

Whenever some A0i+1 is requested to release the key for

the corresponding lock (recall that all A0i+1 are honest

nodes) it releases the key for the fresh lock (Ai, A0i+1)

instead.

S : The interaction of the simulator is identical to H3

except that the actions of S are dictated by the interac-tion with F . The simulator reads the communication of

A with the honest users via Fanon and is queried by Fon the following set of inputs.

1) (·, ·, ·, ·, Init): The simulator reconstructs the adver-sarial set (defined above) from the ids and sets upa fresh lock chain.

2) (·, Lock): The simulator initiates the locking pro-cedure with the adversary and replies with ⊥ if theexecution is not successful.

3) (·,Rel) The simulator releases the key of the cor-responding lock and publishes it.

If A interacts with a honest user (e.g., by releasing alock) the simulator queries the corresponding interfaceof F .

Note that the simulator is efficient and interacts as theadversary with the ideal world. Furthermore, the simu-lation is always consistent with the ideal world, i.e., ifthe adversary’s action is not supported by the interfacesof F the simulation aborts. What is left to be shown isthat the neighboring hybrids are indistinguishable to theeyes of the environment E .

Lemma 1. For all PPT distinguishers E it holds that

EXECH0,A,E ≡ EXECH1,A,E .

Proof: Follows from the homomorphic property ofthe function g: Recall that a key-lock pair (k, `) is validif and only if g(k) = `. Let (ki, `i) be the output of A,by construction we have that `i = `i−1+g(yi), for some(`i−1, yi), which is part of the state of the honest node.Since the release algorithm computes ki − yi we havethat

g(ki − yi) = g(ki)− g(yi)

= `i − g(yi)

= `i−1 + g(yi)− g(yi)

= `i−1

with probability 1, by the homomorphic property of g.

Lemma 2. For all PPT distinguishers E it holds that

EXECH1,A,E ≈ EXECH2,A,E .

Proof: Let q ∈ poly(λ) be a bound on the numberof interactions. Recall that H1 and H2 differ onlyfor the case where the adversary outputs a key for ahonestly generated lock before the trapdoor is released.Assuming towards contradiction that the probability thatthis event happens is non-negligible, we can constructthe following reduction against the one-wayness of g:On input some Y ∗ ∈ R, the reduction guesses a sessionj ∈ [1, q] and some index i ∈ [1, n]. The setup algorithmof the j-th session is modified as follows: Yi is set to beY ∗. Then, for all ι ∈ [i− 1, 0], the setup samples some

21

yι ∈ D and returns (Yι = Yι+1 − g(yι), Yι+1, yι). Thesetup samples a random yi ∈ D and sets Yi+1 = g(yi).Then, for ι ∈ [i + 1, n − 1], the setup samples yι ∈ Dreturns (Yι, Yι + g(yι), yι). The nodes (U1, . . . , Un−1)are given the corresponding output (except for Ui)and Un is given (Yn−1,

∑n−1j=i yj). If the node Ui is

requested to release the lock, the reduction aborts. Atsome point of the execution the adversary A outputssome y∗, and the reduction returns y∗ + yi−1.

The reduction is clearly efficient and, whenever jand i are guessed correctly, the reduction does not abort.Since the group defined by g is abelian, the distributioninduced by the modified setup algorithm is identical tothe original (except for the initial state of U1). Also notethat, whenever j and i are guessed correctly, the userUi is honest and therefore the adversary does not notsee the corresponding internal state. It follows that thereduction is identical toH1, to the eyes of the adversary.Finally, whenever the adversary outputs some valid ki−1for `i−1, then it holds that g(ki−1) = `i−1. Substitutingwe have that

g(ki−1) = `i−1g(y∗) = Yi−1g(y∗) = Y ∗ − g(yi−1)

g(y∗) + g(yi−1) = Y ∗

g(y∗ + yi−1) = Y ∗.

It follows that the reduction is successful with proba-bility at least 1

q·n·poly(λ) . This proves our statement.

Lemma 3. For all PPT distinguishers E it holds that

EXECH2,A,E ≡ EXECH3,A,E .

Proof: Recall that adversarial sets are always in-terleaved by a honest node. Therefore in H2 for eachadversarial set starting at index i there exists a ysuch that Yi = Yi−1 + g(y) and A is not given y.Since y is randomly sampled from D we have thatYi−1 + g(y) ≡ Y ′, for some Y ′ sampled uniformlyfrom R, which corresponds to the view of A in H3.

Lemma 4. For all PPT distinguishers E it holds that

EXECH3,A,E ≡ EXECF,S,E .

Proof: The changes between the two experimentsare only conceptual and the equivalence of the viewsfollows.

This concludes our analysis.

Schnorr-based Construction. Here we prove Theo-rem 6.

Proof:

We define the following sequence of hybrids, wherewe gradually modify the initial experiment.

H0 : Is identical to the protocol as described in Ap-pendix C.

H1 : All the calls to the commitment scheme arereplaced with interactions with the ideal functionalityFcom, defined in the following.

Commit(sid,m)Upon invocation by Ui (for i ∈ {0, 1}):record (sid, i,m) and send (com, sid) to U1−i

if some (sid, ·, ·) is already stored ignore the message

Decommit(sid)Upon invocation by Ui (for i ∈ {0, 1}):if (sid, i,m) is recorded then send (decom, sid,m) to U1−i

Instead of calling the Commit algorithm on somemessage m, the parties sent a message of the formCommit(sid, m) to the ideal functionality, and thedecommitment algorithm is replaced with a call toDecommit(sid). The verifying party simply recordsmessages from Fcom.

H2 : All the calls to the NIZK scheme are replaced withinteractions with the ideal functionality FNIZK:

Prove(sid, x, w)Upon invocation by Ui (for i ∈ {0, 1}):if R(x,w) = 1 then send (proof, sid, x) to U1−i

Instead of running the proving algorithm in input (x,w),the proving party queries the functionality on Prove(sid,x, w). The verifier records the messages from FNIZK.

H3,H4,H5,S : The subsequent hybrids are defined asH1,H2,H3,S, respectively, in Theorem 2.

As argued before, the simulator is efficient and theinteraction is consistent with the inputs of the idealfunctionality. In the following we prove the indistin-guishability of the neighboring experiments.

Lemma 5. For all PPT distinguishers E it holds that

EXECH0,A,E ≈ EXECH1,A,E .

Proof: Follows directly from the security of thecommitments scheme COM.

Lemma 6. For all PPT distinguishers E it holds that

EXECH1,A,E ≈ EXECH2,A,E .

Proof: Follows directly from the security of thenon-interactive zero-knowledge scheme NIZK.

22

Lemma 7. For all PPT distinguishers E it holds that

EXECH2,A,E ≈ EXECH3,A,E .

Proof: In order to show this claim, we introducean intermediate experiment.

H∗2 : The locking algorithms are substituted with thefollowing ideal functionality. Such an interface is calledby both parties on input m and y =

∑ij=0 yj , where i

is the position of the lock in the chains and the yj aredefined as in the original protocol. Note that the keyskU0,U1 refers to the previously established key in thecall to the F schnorr

kgen .

Sign(m, y)Upon invocation by both U0 and U1 on input (m, y):compute (R, s) = Sigschnorr(skU0,U1 ,m)

return (R, s− y)

We defer the indistinguishability proof to lemma 8.Let cheat by the event that triggers an abort ofthe experiment in H3, that is, the adversary re-turns some k such that Vf(`i+1, k) = 1 and thatVf(`i,Rel(k, (s

I , sL, sR))) 6= 1. Assume towards con-tradiction that Pr [cheat | H∗2] ≥ 1

poly(λ) , then we canconstruct the following reduction against the strong-existential unforgeability of Schnorr signatures: Thereduction receives as input a public key pk and samplesan index j ∈ [1, q], where q ∈ poly(λ) is a bound on thetotal amount of interactions. Let Q be the key generatedin the j-th interaction, the reduction sets Q = pk. Allthe calls to the signing algorithm are redirected to thesigning oracle. If the event cheat happens, the reduc-tion returns corresponding (k∗, `∗) = (σ∗, (m∗, pk∗)),otherwise it aborts.

The reduction is clearly efficient. Assume for themoment that j is the index of the interaction wherecheat happens, and let i+ 1 be the index that identifiesthe lock `∗ in the corresponding chain. Note that incase the guess of the reduction is correct we havethat pk∗ = pk. Since cheat happens we have thatVfschnorr(pk

∗,m∗, σ∗) = 1 and the release fails, i.e.,Vf(`i,Rel(k, (s

Ii , s

Li , s

Ri )) 6= 1 (where `i is the lock in

the previous position as `∗ in the same chain). Recallthat the release algorithm parses sLi as (Wi,0, wi,1) andσ∗ as (R∗, s∗) and returns (Wi,0, wi,1+s∗−(sRi +yi)).Substituting with the corresponding values(

Wi,0, wi,1 + s∗ − (sRi + yi))

=

Ri, si − i−1∑j=0

yj + s∗ − sj −i∑

j=0

yj + yi

= (Ri, si + s∗ − sj) ,

where sj is the answer of the oracle on the j-th sessionon input mj . This implies that s∗ 6= sj , otherwise(Ri, si) would be a valid signature since it is an outputof the signing oracle. Since each message uniquelyidentifies a session (the same message is never queriedtwice to the interface Sign(m,y)) this implies that(σ∗, (m∗, pk∗)) is a valid forgery. By assumption thishappens with probability at least 1

q·poly(λ) , which is acontradiction and proves that Pr [cheat | H∗2] ≤ negl(λ).Since the experiments H2 and H3 differ only whencheat happens (and H3 aborts), we are only left withshowing the indistinguishability of H2 and H∗2.

Lemma 8. For all PPT distinguishers E it holds that

EXECH2,A,E ≈ EXECH∗2 ,A,E .

Proof: The proof consists of the description of thesimulator for the interactive lock algorithm. We describetwo simulators depending on whether the honest adver-sary is playing the role of the ”left” or ”right” party. Foreach proof, both the simulators implicitly check that thegiven witness is valid and abort if this is not the case.

1) Left corrupted: Prior to the interaction the simula-tor is sent (Y, y, (prove, {∃y∗ s.t y∗ ·G = Y }, y∗)),which is the state corresponding to the execu-tion of the lock. After agreeing on a messagem, the simulator sends (com, sid) to A, for arandom sid. The simulator also queries the inter-face Sign on input m, y∗ and receives a signatureσ = (R, s). At some point of the execution Asends (R0, (prove, {∃r0 s.t r0 ·G = R0}, r0)). Thesimulator replies with decom, sid,

(R∗ = R− (R0 + Y ),proof, sid,{∃r∗ s.t r∗ ·G = R∗}

),

R∗, (s− r0 − e · x0)

where e = H(pk‖R∗‖m) and x0 is the valuereturned by the key generation to A. The rest ofthe execution is unchanged.

2) Right corrupted: Prior to the interaction the simula-tor is sent (Y, y, (prove, {∃y∗ s.t y∗ ·G = Y }, y∗)),which is the state corresponding to the executionof the lock. After agreeing on a message m, thesimulator is given(com, sid,

(R1,

prove, sid,{∃r1 s.t r1 ·G = R1}, r1

))by A. The simulator then queries the interfaceSign on input m, y∗ and receives a signatureσ = (R, s). The simulator sends (R∗ = R −(R1 + Y ), (proof, sid, {∃r∗ s.t r∗ · G = R∗})) toA and receives ((decom, sid), s∗) in response. Thesimulator checks whether s∗ = r1 + e · x1, wheree = H(pk‖R∗‖m), and returns s if this is the case.

23

Both simulators are obviously efficient and the distri-butions induced by the simulated views are identical tothe ones of the original protocol.

This concludes the proof of lemma 7.

Lemma 9. For all PPT distinguishers E it holds that

EXECH3,A,E ≈ EXECH4,A,E .

Proof: Let q ∈ poly(λ) be a bound on the numberof interactions. Let cheat denote the events that triggersan abort in H4 but not in H3. In the following we aregoing to show that Pr [cheat | H3] ≤ negl(λ), thus prov-ing the indistinguishability of H3 and H4. Assume thatthe converse is true, then we can construct the followingreduction against the discrete logarithm problem (whichis implied by the sEUF of Schnorr): On input someY ∗ ∈ G, the reduction guesses a session j ∈ [1, q] andsome index i ∈ [1, n]. The setup algorithm of the j-thsession is modified as follows: Yi is set to be Y ∗. Then,for all ι ∈ [i − 1, 0], the setup samples some yι ∈ Zqand returns (Yι = Yι+1 − yι · G, Yι+1, yι). The setupsamples a random yi ∈ Zq and sets Yi+1 = yi ·G. Then,for ι ∈ [i+ 1, n− 1], the setup samples yι ∈ Zq returns(Yι, Yι+yι ·G, yι). The nodes (U1, . . . , Un−1) are giventhe corresponding output (except for Ui) and Un is given(Yn−1,

∑n−1j=i yj). If the node Ui is requested to release

the lock, the reduction aborts. At some point of theexecution the adversary A outputs some k∗ = (R∗, s∗).The reduction parses sR as the updated state of Ui andreturns s∗ + yi−1 − sR.

The reduction is clearly efficient and, whenever jand i are guessed correctly, the reduction does not abort.Since the group G is abelian and the Ui is honest, thedistribution induced by the modified setup algorithm isidentical to the original to the eyes of the adversary.Recall that cheat happens only in the case where k∗

is a valid opening for `i and the release algorithmis successful on input k∗ (if the last condition is notsatisfied both H3 and H4 abort). Substituting, we havethat sR is of the form r0+r1+e·(x0+x1)−y = s′−y,for some y ∈ Zq . Since the release is successful, then itmust be the case that (R′ = (r0 + r1) ·G+ Yi−1, s

′) isa valid Schnorr signature on the message mi−1 (agreedby the two parties in the locking algorithm for `i−1),which implies that y ·G = Yi−1. As argued in the proofof lemma 7, if s∗ 6= s′, then we have an attacker againstthe strong unforgeability of the signature scheme. Itfollows that s∗ = s′ with all but negligible probability.

Substituting we have

(s∗ + yi−1 − sR) ·G = (s∗ + yi−1 − s′ + y) ·G= (yi−1 + y) ·G= yi−1 ·G+ y ·G= yi−1 ·G+ Yi−1= yi−1 ·G+ (Y ∗ − yi−1 ·G)

= Y ∗

as expected. Since, by assumption, this happens withprobability at least 1

q·n·poly(λ) we have a successfulattacker against the discrete logarithm problem. Thisproves our statement.

Lemma 10. For all PPT distinguishers E it holds that

EXECH4,A,E ≡ EXECH5,A,E .

Proof: Recall that adversarial sets are always in-terleaved by a honest node. Therefore in H4 for eachadversarial set starting at index i there exists a ysuch that Yi = Yi−1 + y · G and A is not given y.Since y is randomly sampled from Zq we have thatY + i− 1+y ·G ≡ Y ′, for some Y ′ sampled uniformlyfrom G, which corresponds to the view of A in H5.

Lemma 11. For all PPT distinguishers E it holds that

EXECH5,A,E ≡ EXECF,S,E .

Proof: The change is only syntactical and theindistinguishability follows.

This concludes our analysis.

ECDSA-based Construction. In the following weprove Theorem 3.

Proof: The sequence of hybrids that we define isidentical to the one described in the proof of Theorem 6.In the following we prove the indistinguishability ofneighboring experiments only for the cases where theargument needs to be modified. If the argument isidentical, the proof is omitted.

Lemma 12. For all PPT distinguishers E it holds that

EXECH2,A,E ≈ EXECH3,A,E .

Proof: In order to show this claim, we introducean intermediate experiment.

H∗2 : The locking algorithms is substituted with theinteraction with the following ideal functionality. Recallthat the key skU0,U1 here refers to the key establishedduring the call of the same pair of users to the keygeneration functionality. Also note that the lockingalgorithm is called by both parties on input m and

24

y =∑ij=0 yj , where i is the position of the lock in the

chains and the yj are defined as in the original protocol.

Sign(m, y)Upon invocation by both U0 and U1 on input (m, y):compute (r, s) = SigECDSA(skU0,U1 ,m)

return (r,min(s · y,−s · y))

The indistinguishability proof of H2 and H∗2 is for-mally shown in lemma 13. Let cheat by the event thattriggers an abort of the experiment in H3, that is, theadversary returns some k such that Vf(`i+1, k) = 1and Vf(`i,Rel(k, (s

I , sL, sR))) 6= 1. Assume towardscontradiction that Pr [cheat | H∗2] ≥ 1

poly(λ) , then wecan construct the following reduction against the strong-existential unforgeability of ECDSA signatures: Thereduction receives as input a public key pk and samplesan index j ∈ [1, q], where q ∈ poly(λ) is a bound on thetotal amount of interactions. Let Q be the key generatedin the j-th interaction, the reduction sets Q = pk. Allthe calls to the signing algorithm are redirected to thesigning oracle. If the event cheat happens, the reduc-tion returns corresponding (k∗, `∗) = (σ∗, (m∗, pk∗)),otherwise it aborts.

The reduction runs in polynomial time. Assumefor the moment that j is the index of the interactionwhere cheat happens, and let i + 1 be the index thatidentifies the lock `∗ in the corresponding chain. Notethat in case the guess of the reduction is correct wehave that pk∗ = pk. Since cheat happens we havethat VfECDSA(pk∗,m∗, σ∗) = 1 and the release fails,i.e., Vf(`i,Rel(k

∗, k∗, (sIi , sLi , s

Ri ))) 6= 1 (where `i is

the lock in the previous position as `∗ in the samechain). Recall that the release algorithm parses sLias (wi,0, wi,1), σ∗ as (r∗, s∗), and sRi as (s′,m, pk)

and computes t = w1 · ( s′

s∗ − y)−1 and t′ = w1 ·(− s′

s∗ − y)−1. Then it returns either (wi,0,min(t,−t))or (wi,0,min(t′,−t′)) depending on which verifies asa valid signature on m under pk. Substituting with thecorresponding values (for the case t is the lower term)

(wi,0, t) =

(ri, wi,1 ·

(s′

s∗− y)−1)

=

ri, si · i−1∑j=0

yj ·

(sj ·

∑ij=0 yj

s∗− yi

)−1

where sj is the answer of the oracle on the j-th sessionon input the corresponding message mj . If we set s∗ =

sj then we have

(wi,0, t) =

ri, si · i−1∑j=0

yj ·

i∑j=0

yj − yi

−1

= (ri, si)

which is a valid signature on mi (since it is the output ofthe signing oracle) and the release would be successful.So this cannot happen and we can assume that s∗ 6=sj . A similar argument (substituting t with t′) can beused to show that it must be the case that s∗ 6= −sj .Since each message uniquely identifies a session (thesame message is never queried twice to the interfaceSign(m,y)) this implies that (σ∗, (m∗, pk∗)) is a validforgery. By assumption this happens with probability atleast 1

q·poly(λ) , which is a contradiction and proves thatPr [cheat | H∗2] ≤ negl(λ). Since the experiments H2

andH3 differ only when cheat happens (andH3 aborts),we are only left with showing the indistinguishability ofH2 and H∗2.

Lemma 13. For all PPT distinguishers E it holds that

EXECH2,A,E ≈ EXECH∗2 ,A,E .

Proof: The proof consists of the description ofthe simulator for the interactive lock algorithm. In thefollowing we describe the two simulators for the lockingprotocol depending on whether the honest adversary isplaying the role of the ”left” or ”right” party. For eachzero-knowledge proof, both the simulators implicitlycheck that the given witness is valid and abort if this isnot the case.

1) Left corrupted: Prior to the interaction the simula-tor is sent (Y, y, (prove, {∃y∗ s.t y∗ ·G = Y }, y∗)),which is the state corresponding to the execu-tion of the lock. After agreeing on a messagem, the simulator sends (com, sid) to A, for arandom sid. The simulator also queries the inter-face Sign on input m, y∗ and receives a signatureσ = (r, s). The simulator sets R = H(m)

s · G +rs · pk. At some point of the execution A sends(R0, R

′0, (prove, {∃r0 s.t r0 ·G = R0 and r0 ·Y =

R′0}, r0)). Then the simulator samples a ρ← Zq2and computes c′ ← EncHE(pk, s · r0 + ρq). Then itprovides the attacker with

decom, sid,

R∗ = (r0)−1 ·R,R1 = y−1 ·R∗,proof, sid,{∃r∗ s.t r∗ ·G = R1

and r∗ · Y = R∗

} ,

R1, R∗, c′.

The rest of the execution is unchanged.

25

The executions are identical except for the way c′ iscomputed. In order to show the statistical proximity weinvoke a the following helping lemma.

Lemma 14. [39] For all (r, s, p) ∈ Zq and fora random ρ ∈ Zq2 , the distributions EncHE(pk, r ·s mod q+pq+ρq) and EncHE(pk, r ·s mod q+ρq) arestatistically close.

In the real world c′ is computed as EncHE(pk, r ·s mod q + pq + ρq), for some p which is bounded byq since the only operation performed without modularreduction are one multiplication and one addition, whichcannot increase the result by more than q2. Since thedistribution EncHE(pk, r · s mod q + ρq) is identical tothe simulation, the indistinguishability follows.

2) Right corrupted: Prior to the interaction the simula-tor is sent (Y, y, (prove, {∃y∗ s.t y∗ ·G = Y }, y∗)),which is the state corresponding to the executionof the lock. After agreeing on a message m, thesimulator is given

com, sid,R1, R′1,

prove, sid,{∃r1 s.t r1 ·G = R1 andr1 · Y = R′1

},

r1

by A. The simulator then queries the interfaceSign on input m, y∗ and receives a signatureσ = (r, s). Then it sets R = H(m)

s · G +rs · pk and R∗ = R − (R1 + Y ) and sends(R0 = y−1 · R∗, R∗, (proof, sid, {∃r∗ s.t r∗ · G =R0 and r∗ · Y = R∗})) to A. The attackersends ((decom, sid), c′) in response. The simulatorchecks

DecHE(sk, c′) = r · r · (r1)−1 +H(m) · r−11 mod q,

where r was sampled in the key generation algo-rithm. If the check holds true, the simulator sendss to A.

The distribution induced by the simulator is identicalto the real experiment except for the way c is com-puted. Towards showing indistinguishability, considerthe following modified simulator, that is given theoracle O(c′, a, b) as defined in the following securityexperiment of the Paillier encryption scheme.

Exp− ecCPAAHE(λ) :

(sk, pk)← KGenHE(1λ)

(w0, w1)←$ZqQ = w0 ·Gb←$ {0, 1}c← EncHE(pk, wb)

b′ ← A(pk, c, Q)O(·,·,·)

where O(c′, a, b) returns 1 iff DecHE(sk, c′) = a+ b · wb

return 1 iff b = b′

Instead of performing the last check, the simulatorqueries the oracle on input (c′, a = H(m) · r−11 , b =r · (r1)−1). It is clear that the modified simulatoraccepts if and only if the simulator described aboveaccepts. Assume towards contradiction that the modifiedsimulator can be efficiently distinguished from the realworld experiment. Then we can reduce to the securityof Paillier as follows: On input (pk, c,Q), the reductionsimulates the inputs of A as described in the modifiedsimulator using the input pk, Q, and c as the corre-sponding variables. It is easy to see that the reductionis efficient. Note that if b = 0 then we have thatc = EncHE(pk, w0) and Q = w0 ·G, which is identicalto the real world execution. On the other hand if b = 1then it holds that c = EncHE(pk, w1) and Q = w0 · G,where w1 is uniformly distributed in Zq , which isidentical to the (modified) simulated experiment. Thisimplies that the modified simulation is computationallyindistinguishable from the real world experiment. Sincethe modified simulation and the simulation (as describedabove) are identical to the eyes of the adversary, thevalidity of the lemma follows.

This concludes the proof of lemma 12.

Lemma 15. For all PPT distinguishers E it holds that

EXECH3,A,E ≈ EXECH4,A,E .

Proof: Let q ∈ poly(λ) be a bound on the numberof interactions. Let cheat denote the event that triggersan abort in H4 but not in H3. In the following we aregoing to show that Pr [cheat | H3] ≤ negl(λ), thus prov-ing the indistinguishability of H3 and H4. Assume thatthe converse is true, then we can construct the followingreduction against the discrete logarithm problem (whichis implied by the sEUF of ECDSA): On input someY ∗ ∈ G, the reduction guesses a session j ∈ [1, q] andsome index i ∈ [1, n]. The setup algorithm of the j-thsession is modified as follows: Yi is set to be Y ∗. Then,for all ι ∈ [i−1, 0], the setup samples some yι ∈ Zq andreturns (Yι = Yι+1− (yι) ·G, Yι+1, yι). The setup sam-ples a random yi ∈ Zq and sets Yi+1 = yi ·G. Then, forι ∈ [i+1, n−1], the setup samples yι ∈ Zq and returns(Yι, Yι+yι ·G, yι). The nodes (U1, . . . , Un−1) are giventhe corresponding output (except for Ui) and Un is given

26

(Yn−1,∑n−1j=i yj). If the node Ui is requested to release

the lock, the reduction aborts. At some point of theexecution the adversary A outputs some k∗ = (r∗, s∗).The reduction parses sR = (s′,m, pk) as the updatedstate of Ui then checks the following:

1)(ss∗ + yi−1

)·G = Y ∗

2) −(s′

s∗ + yi−1

)·G = Y ∗

and returns the LHS term of the equation that satisfiesthe relation.

The reduction is clearly efficient and, whenever jand i are guessed correctly, the reduction does notabort. Since the G is abelian and the Ui is honest, thedistribution induced by the modified setup algorithm isidentical to the original to the eyes of the adversary.Recall that cheat happens only in the case where k∗

is a valid opening for `i and the release algorithmis successful on input k∗ (if the last condition is notsatisfied both H3 and H4 abort). Substituting, we havethat s′ is of the form x0·x1·rx+H(m)

r0·r1 = s · y, whereR′ = r0 · r1 · Yi−1 = (rx, ry), for some y ∈ Zq .Since the release is successful, then it must be the casethat (rx, s) is a valid ECDSA signature on the messagemi−1 (agreed by the two parties in the locking algorithmfor `i−1). This implies that y ·G = Yi−1. As argued inthe proof of lemma 12, if s∗ 6= s and s∗ 6= s, then wehave an attacker against the strong unforgeability of thesignature scheme. It follows that s∗ = s or s∗ = −swith all but negligible probability. Substituting we have(

s′

s∗+ yi−1

)·G =

(s · ys∗

+ yi−1

)·G

=s · ys∗·G+ yi−1 ·G

= y ·G+ yi−1 ·G= Yi−1 + yi−1 ·G= (Y ∗ − yi−1 ·G) + yi−1 ·G= Y ∗

which implies that condition (1) holds if s∗ = s. Forthe other case

−(s′

s∗+ yi−1

)·G = −

(s · ys∗

+ yi−1

)·G

= − s · ys∗·G+ yi−1 ·G

= y ·G+ yi−1 ·G= Yi−1 + yi−1 ·G= (Y ∗ − yi−1 ·G) + yi−1 ·G= Y ∗

which means that condition (2) is satisfied if s∗ = −s.Since, by assumption, this happens with probability atleast 1

q·n·poly(λ) we have a successful attacker against the

discrete logarithm problem. This proves our statement.

This concludes our proof.

F. PCNs from Multi-Hop Locks

In this section we show that AMHLs are sufficientto construct a full-fledged PCN that satisfy the standardsecurity definition from Malavolta et al. [42].

Ideal Functionalities. We assume an ideal realizationof AMHLs in the form of an ideal functionality FL asdescribed in Fig. 3. That is, all parties have oracle accessto FL through the specified interfaces.

Furthermore (same as it was done in [42]), weassume the existence of a blockchain B that we model asa trusted append-only bulletin board: The correspondingideal functionality FB maintains B locally and updatesit according to the transactions between users. At anypoint in the execution, anyone can send a distinguishedmessage read to FB, who sends the whole transcript ofB to U . We denote the number of entries of B by |B|.We assume that users can specify arbitrary contracts,i.e., transactions in B may be associated with arbitraryconditions which require to be me in order to make thetransaction effective. FB is entrusted to enforce that acontract is fulfilled before the corresponding transactionis executed.

We model time as the number of entries of theblockchain B, i.e., time t is whenever |B| = t. Notethat we can artificially elapse time by adding dummyentries to B and that the current time is available to allparties by simply reading B and counting the numberof entries. As discussed before, we assume synchronouscommunication between users, which is modelled bythe functionality Fsyn, and secure message transmissionchannels between users (modelled by Fsmt).

Multi-session Extension. A subtlety in the applica-tion of the composition theorem is that each call ofeach ideal functionality assumes to spawn an indepen-dent instance. However, the FL functionality (describedin Fig. 3) formally requires a joint state between ses-sions: The KGen protocols that are used for estab-lishing pairwise links (or channels, respectively) areshared between multiple locking instances which mightpotentially result in shared keys between the differentinstances of PrivMuLs that realize payment channels.Consequently, a study of the concrete realization ofthose KGen protocols is required when arguing aboutthe composition of several locking instances. Composi-tion with joint states is discussed in [19], where theauthors state a stronger version of the compositiontheorem (the so called JUC theorem) which accountsfor joint state and randomness across protocol sessions.

27

In order to satisfy the conditions for the JUCtheorem to apply, we must argue that our protocolrealizes a stronger ideal functionality FL that makesonly independent calls to the underlying interfaces (referto [19] for a detailed description). More precisely, thismeans that we need to argue for each of the previouslypresented concrete realizations of FL that a parallelcomposition of those protocols – with all instancesof the protocol sharing the same KGen protocols andrunning independently otherwise – realizes the function-ality FL. This is shown in the following lemmas.

Lemma 16. Let g be a homomorphic one-way function,

and let LgenericKGen

be the multi-session extension ofthe protocol described in Fig. 4 using a shared KGen

algorithm. Then LgenericKGen

UC-realizes the ideal func-tionality FL in the (Fsyn,Fsmt,Fanon)-hybrid model.

Proof: The proof trivially follows from Theorem 2and the Composition Theorem [18] since the KGenprotocol never needs to be invoked for realizing FL and

hence the different copies of Lgeneric in LgenericKGen

arefully independent. So the joint state is in fact empty.

Lemma 17. Let COM be a secure commitment scheme,let NIZK be a non-interactive zero knowledge proof,

and let LschnorrKGen

be the multi-session extensionof the protocol described in Fig. 7 using a sharedKGen algorithm realizing F schnorr

kgen . If Schnorr sig-natures are strongly existentially unforgeable, then

LschnorrKGen

UC-realizes the ideal functionality FL inthe (F schnorr

kgen ,Fsyn,Fsmt,Fanon)-hybrid model.

Proof: It is easy to see that the F schnorrkgen func-

tionality itself is stateless and therefore consecutiveinvocations of F schnorr

kgen are indistinguishable from theinvocation of fresh instances of the functionality. Hence,for multiple protocols, it is identical to query the sameF schnorr

kgen instance or to work on independent copies (andthe same property carries over to protocols realizing

this functionality). As a consequence LschnorrKGen

isindistinguishable from the multi-session extension ofLschnorr using independent KGen copies that realizeF schnorr

kgen . So the claim trivially follows from Theorem 6and the Composition Theorem [18].

Lemma 18. Let COM be a secure commitment schemeand let NIZK be a non-interactive zero knowledge proof,

and let LecdsaKGen

be the multi-session extension of theprotocol described in Fig. 5 using a shared KGen al-gorithm realizing idealECDSA

kgen . If ECDSA signatures arestrongly existentially unforgeable and Paillier encryp-tion is ecCPA secure, and KGen then the constructionin Fig. 5 UC-realizes the ideal functionality FL in the(FECDSA

kgen ,Fsyn,Fsmt,Fanon)-hybrid model.

Proof: As FECDSAkgen satisfies the same independence

property as F schnorrkgen , the same argument as for lemma 17

applies.

System Assumptions. We assume that every user in thePCN is aware of the complete network topology, thatis, the set of all users and the existence of a paymentchannel between every pair of users. We further assumethat the sender of a payment chooses a payment path tothe receiver according to her own criteria.

The current value on each payment channel is notpublished but instead kept locally by the users sharing apayment channel. The two users U0 and U1 are assumedto maintain locally the capacity of their channel, denotedby cap(U0, U1). We further assume that every user isaware of the payment fees charged by each other user inthe PCN. For ease of exposition we define the predicatefee(Ui) to return the fee charged by the user Ui. Weassume that pairs of users sharing a payment channelcommunicate through secure and authenticated channels(such as TLS), which is easy to implement given thatevery user is uniquely identified by a public key.

Our System. In the following we describe the threeoperations (open channel, close channel, and payment)that constitute the core of our system. For the sakeof simplicity we restrict each pair of user to at mostone channel, however our construction can be easilyextended to support multiple channels per pair.

OPEN CHANNEL. The open channel protocol generatesa new payment channel between users U1 and U2. Theuser U1 invokes FL on input (U2, L), depending on thedirection of the channel, which returns the users identi-fiers (U1, U2) if the operation was successful. Then theusers create an initial blockchain deposit that includesthe following information: Their addresses, the initialcapacity of the channel, the channel timeout, and the feecharged to use the channel agreed beforehand betweenboth users. After the deposit has been successfullyadded to the blockchain, the operation returns 1. If anyof the previous steps is not carried out as defined, theoperation returns 0.

CLOSE CHANNEL. The close channel protocol is run bytwo users U1 and U2 sharing an open payment channelto close it at the state defined by v and accordinglyupdate their bitcoin balances in the Bitcoin blockchain.From this point on, U1 and U2 ignore all the requestsfrom FL relative to their link.

PAYMENT. A payment operation transfers a value vfrom a sender (U0) to a receiver (Un+1) througha path of open payment channels between them(U0, . . . , Un+1). The sender (prot. 1) first computesthe cost of sending v coins to the receiver as v1 :=v +

∑ni=1 fee(Ui), and the corresponding cost at each

28

of the intermediate hops in the payment path. Then itsetups up a AMHL by calling the ideal functionalityFL on the set of identifiers of the intermediate users.Finally, it sends each user the corresponding value tobe transferred and a timeout information ti.

Each intermediate user (prot. 3) checks whether thecapacity of the channel is high enough to support thetransfer of the coins and whether the timeouts giveby the sender are consistent, i.e., ti+1 = ti − ∆ forsome fixed ∆. Starting from (U0, U1), each pair of usersquery the ideal functionality FL on the Lock interfaceusing the lid received in the previous phase. If theideal functionality signals to proceed, then the two usersestablish a contract specified in the following.

contract(Alice, Bob, lid, x, t)

1) If GetStatus(lid) = Rel before t days,then Alice pays Bob x coins.

2) If t elapse, then Alice gets back x coins.

The contract is authenticated by both users and canbe uploaded to B by either of them at any time. If everyuser in the path locks the corresponding lid, eventuallythe receiver (prot. 2) is reached. Un+1 checks whetherthe transacted value is what it expects, and whether thelatest timeout tn+1 is well-formed. If both conditionshold, the receiver releases the lock lidn by querying theideal functionality. This triggers a cascade of releasecalls in the path from the sender to the receiver, therebyenabling the left user in the link to pull the payment(using the previously established contract). If for somereason one of the intermediate links is not released,then all of the previous contracts are voided after thecorresponding timeout.

Analysis. In the following we argue that the system asdescribed above ideally realizes the functionality FPCNas defined in [42], assuming oracle access to FL, FB,and Fsyn.

Theorem 7. The system described above UC-realizesFPCN (as defined in [42]) in the (FL,FB,Fsyn,Fsmt)-hybrid model.

Proof: The proof consists of the observation thatthe ideal functionality FL enforces balance security andsatisfies relationship anonymity (as defined in [42]).A subtlety is that now all users have access to aGetStatus interface and they might be able to querythe functionality on a certain lid and learn its statuseven when they are not involved in the generation ofsuch a lock. However one can easily show that thishappen only with negligible probability since it requireguessing lid, which is a string sampled uniformly atrandom. It is also easy to see that FL does not allow

Algorithm 1: Payment routine for the senderInput : (U0, . . . , Un+1, v)

1 v1 := v +∑ni=1 fee(Ui)

2 if v1 ≤ cap(U0, U1) then3 query FL on Setup(U0, . . . , Un+1)4 FL returns (⊥, lid0,⊥, U1, Init)5 cap(U0, U1) := cap(U0, U1)− v16 t0 := tnow + ∆ · n7 forall i ∈ {1, . . . , n}8 vi := v1 −

∑i−1j=1 fee(Uj)

9 ti := ti−1 −∆10 send ((Ui−1, Ui+1, vi+1, ti, ti+1), fwd) to

Ui11 end for12 send (Un, vn+1, tn+1) to Un+1

13 query FL on Lock(lid0)14 if FL returns (lid0, Lock)15 contract(U0, U1, lid0, v1, t1)16 else17 abort18 end if else19 abort20 end if

Algorithm 2: Payment routine for the receiver

Input : (Un, vn+1, tn+1, v)1 FL returns (lidn,⊥, Un,⊥, Init)2 if (tn+1 > tnow + ∆) ∧ (vn+1 =

v) ∧ (GetStatus(lidn) = Lock) then3 query FL on Release(lidn)4 send ok to Un5 else6 send ⊥ to Un7 end if

one to perform wormhole attacks, by construction. Whatis left to be shown is that the rest of the informationexchanged by the machines does not break any of theseproperties. Note that the only information that is sentoutside FL consists of user identifiers, timeouts, andvalues to lock. The first are already known by theintermediate users, whereas the rest of the items arechosen exactly as described in FPCN . Note that it issufficient here to argue about the individual copies ofFL in isolation by the JUC theorem [19]. As we showed,the multi-session extended ideal functionality FL isrealized by our instantiations and therefore the JUCtheorem allows us to complete the analysis assumingindependent copies of FL running in parallel.

29

Algorithm 3: Payment routine for the i-thintermediate user

Input : (m, decision)1 if decision = fwd then2 parse m as (Ui−1, Ui+1, vi+1, ti, ti+1)3 FL returns (lidi−1, lidi, Ui−1, Ui+1, Init)4 if (vi+1 ≤ cap(Ui, Ui+1)) ∧ (ti+1 =

ti −∆) ∧ (GetStatus(lidi−1) = Lock) then5 cap(Ui, Ui+1) := cap(Ui, Ui+1)− vi+1

6 query FL on Lock(lidi)7 if FL returns (lidi, Lock)8 contract(Ui, Ui+1, lidi, vi+1, ti+1)9 else

10 send ⊥ to Ui−111 end if12 else13 send ⊥ to Ui−114 else if decision = ⊥ then15 cap(Ui, Ui+1) := cap(Ui, Ui+1) + vi+1

16 send ⊥ to Ui−117 else if (decision = ok) ∧GetStatus(lidi) = Rel

then18 query FL on Release(lidi−1)19 send ok to Ui−120 else21 send ⊥ to Ui−122 end if

30