A Composable Security Treatment of the Lightning Network

Aggelos Kiayias Orfeas Stefanos Thyfronitis Litos University of Edinburgh and IOHK University of Edinburgh Email: [email protected] Email: [email protected]

Abstract—The high latency and low throughput of synchrony [4] and variable difficulty [5]. Interestingly, blockchain protocols constitute one of the fundamen- this latency “deficiency” is intrinsic to the blockchain tal barriers for their wider adoption. Overlay proto- approach (see below), i.e., latency’s dependency on k is cols, notably the lightning network, have been touted not a side-effect of the security analysis but rather a as the most viable direction for rectifying this in prac- characteristic of the underlying protocol and the threat tice. In this work we present for the first time a full model it operates in. formalisation and security analysis of the lightning Given the above state of affairs, one has to either network in the (global) universal composition setting change the underlying settlement protocol or devise that leverages a global ledger functionality, for which some other mechanism that, in conjunction with the realisability by the Bitcoin blockchain protocol has blockchain protocol, achieves high throughput and low been demonstrated in previous work [Badertscher et latency. A number of works proceeded with the first al., Crypto’17]. As a result, our treatment delineates direction, e.g., hybrid consensus [6], Algorand [7]. A exactly how the security guarantees of the protocol downside of this approach is that the resulting pro- depend on the properties of the underlying ledger tocols fundamentally change the threat model within and the frequent availability of the protocol partici- which Bitcoin is supposed to operate, e.g., by reducing pants. Moreover, we provide a complete and modu- the threshold of corrupted players, strengthening the underlying cryptographic assumptions or complicating lar description of the core of the lightning protocol the setup assumption required (e.g., from a public to a that highlights precisely its dependency to under- private setup). lying basic cryptographic primitives such as igital The alternative approach is to build an overlay pro- signatures, pseudorandom functions, identity-based tocol that utilises the blockchain protocol as a “fall signatures and a less common two-party primitive, back” layer and does not relax the threat model in any which we term a combined digital signature, that way while it facilitates fast “off-chain” settlement under were originally hidden within the lightning protocol’s certain additional assumptions. We note that in light of implementation. the impossibility result regarding protocol “responsive- ness” from [6] that states that no protocol can provide 1. Introduction settlement in time proportional to actual network delay (i.e., fast settlement) and provide a security threshold Improving the latency of blockchain protocols, in over 1/3, we know that maintaining Bitcoin’s threat the sense of the time it takes for a transaction to be model will require some additional assumption for the “finalised”, as well as their throughput, in the sense of overlay protocol to offer fast settlement. the number of transactions they can handle per unit of The first instance of this approach and by far the time, are perhaps the two most crucial open questions most widely known and utilised to date, came with the in the area of permissionless distributed ledgers and lightning network [8]1 that functions over the Bitcoin remain fundamental barriers for their wider adoption blockchain and leverages the concept of a bilateral pay- in applications that require large scale and reasonably ment channel. The latency for a transaction becomes expedient transaction processing, cf. [1]. The Bitcoin linear to actual network delay and another factor that blockchain protocol, introduced by Nakamoto [2], pro- equals the number of bilateral payment channel hops vides settlement with probability of error that drops in the path that connects the two end-points of the exponentially in the number of blocks k that accumulate transaction. Implicated parties are guaranteed that, if over a transaction of interest. This has been informally they wish so, eventually the ledger will record a “gross” argued in the original white paper, and further for- mally demonstrated in [3], from where it can be inferred 1. The specification available online is a more descriptive that the total delay in actual time for a transaction reference for the inner workings of the protocol, see https://github.com/lightningnetwork/lightning-rfc/blob/master/ to settle is linear in k in the worst case. These results 02-peer-protocol.md. See also the raiden network that implements were subsequently generalised to the setting of partial Lightning over Ethereum, https://raiden.network. settlement transaction that reflects the balance resulting also general as it can be applied to any payment from all in-channel payments. Deviations from this guar- network by finely tuning the following parts of the antee are cryptographically feasible but deincentivised: functionality: the exact channel opening message a malicious party trying to commit to an outdated state sequence, the details of the on-chain checks per- will lose funds to a peer that provides evidence of a formed by FPayNet, the negligence time bounds and subsequent state. Moreover, note that no record of a the penalty in case of a malicious closure being specific payment transaction need ever appear on-chain caught. Using FPayNet, parties can open and close thus the number of lightning transactions that can be channels, forward payments along channel paths in exchanged can reach the maximum capacity the network the network as well as poll its status. Importantly, allows between the parties, without being impeded by the functionality keeps track of all the off-chain and any restrictions of the underlying blockchain protocol. on-chain balances and ensures that when a channel The lightning network has been very influential in closes, the on-chain balances are in line with the off- the space and spun a number of follow up research chain ones. In order to handle realistic adversarial and implementations (see below for references). We note deviations, FPayNet allows the adversary to choose that the lightning network is not the only option for one of the following outcomes for each multi-hop building an overlay over a blockchain. See e.g., [9] for payment: (i) let it go through as requested, (ii) an alternative approach focusing on reducing latency, charge it to an adversarial party along the path, (iii) where it is shown that if the assumption is raised to charge it to a negligent honest party along the path. a security threshold of 3/4 plus the honesty of an ad- This last outcome is a crucial security characteristic ditional special player, it is possible to obtain optimal of the lightning network: honest parties are required latency. Nevertheless, this approach does not offer the to poll the functionality with a frequency that corre- throughput benefits that are intrinsic to the lightning sponds to their level of involvement in the network network. and the properties of the underlying ledger. If a Despite the importance of the lightning network for party does not poll often enough, FPayNet identifies blockchain scalability there is still no work so far pro- it as negligent and it may lose funds. viding a thorough formal security analysis. This is a 2) We identify for the first time the exact polling re- dire state of affairs given the fact that the protocol is quirements so that honest parties do not lose funds, 2 actually currently operational and its complexity makes as a function of the parameters of GLedger. The it difficult to extract precise statements regarding the polling requirements for each party are two-fold: level of security it offers. (i) the first type refers to monitoring for closures Our Results. We present the first, to our knowledge, of channels of which the party is a member, and complete security analysis of the lightning network, is specified by the parameter “delay” (chosen by which we carry out in the universal composition (UC) the party), (ii) the second type refers to monitoring setting. We model the payment overlay that the light- for specific events related to receiving and relaying ning network provides as an ideal functionality and we payments. In detail, let Alice be an intermediary of demonstrate how it can be implemented in a hybrid a multi-hop payment. When the payment starts, she world which assumes a global ledger functionality. Our specifies two blockheights h, h0. Also, let a be the treatment is general and does not assume any specific upper bound to the number of blocks that may be implementation for the underlying ledger functionality. finalised in the ledger from the time a certain trans- The “paynet” functionality that we introduce abstracts action is emitted to the time it becomes finalised all the salient security features achieved by the lightning (i.e. it is included in a block in the “stable” part of network. We subsequently describe the whole lightning the ledger). Alice should then poll twice while her protocol in this setting and we prove that it realises local view of the chain advances from blockheight our paynet functionality under standard cryptographic h to blockheight h0 − a. Moreover, the two pollings assumptions; the security guarantees of the functionality should be separated by a time window so that the reflect specific environmental conditions regarding the chain can grow by at least a blocks. availability of the honest parties to poll the status of 3) We provide a complete pseudocode description of the network. In more details our results are as follows. the lightning network protocol ΠLN and prove that it realises FPayNet in the Random Oracle model. 1) We present the FPayNet functionality which ab- stracts the syntax and security properties provided We identify a number of underlying cryptographic primitives that have been used in the lightning by the lightning network. We describe our FPayNet network in a non-black-box fashion and without assuming a global ledger functionality GLedger as defined in [10], and further refined in [11], which reference. Interestingly, while most of these primi- we know that is realised by the Bitcoin blockchain. tives are quite standard (a PRF, a Digital Signature Our approach not only captures lightning, but it is scheme and an Identity Based Signature scheme), there is also one that is less standard and requires 2. For current deployment statistics see e.g., https://1ml.com/ a new definition. The combined digital signature – statistics. as we will call it – is a special case of an asymmetric

2 two-party digital signature primitive (e.g., see [12] for their analysis which offer instant finality; as we and references therein) with the following character- prove in Theorem3, a representative variant of these istic: One of the two parties, called the shareholder, functionalities (Fig.8) is unrealisable even under strong generates and stores a share of the signing key. network assumptions (cf. Section8). It is worth noting The public key of the combined signature can be here that, were such a ledger realizable, layer-2 payment determined non-interactively from public informa- networks would not be as useful in practice because one tion produced by both parties. Issuing signatures of their two main motivations is the high latency of real requires the availability of the share, which is ver- blockchains. On the other hand, in [15] the ledger is not ifiable given the public information provided by explicitly specified as a functionality, but only informally the shareholder. We formalise the combined digital described. Several smart contracts are formally defined signature primitive and show that the construction instead as UC ITMs, which are the entities with which lying within the lightning specification realises it protocols ultimately interact. The execution model of under standard cryptographic assumptions. In sum- these contracts and their interaction with the blockchain mary, the realisation of FPayNet is achieved assum- is explained in an intuitive way, but a complete formal- ing the security of the underlying primitives, which ization of the ledger is missing. Lastly, the ledger used in turn can be based on EC-DLOG and the Random in [13] cannot be used directly by protocol parties, only Oracle model. accessed via higher-level functionalities. This limitation 4) We prove that a more idealized ledger functionality, is imposed because otherwise any party could arbitrarily i.e. a ledger with instant finality, is unrealisable even change the balances of other parties, given the definition assuming a synchronous multicast network. This of the functionality. This ledger is therefore a useful result supports our decision to use the more realistic abstraction for higher-level protocols, but not amenable ledger functionality of [10], since it establishes that to direct usage, let alone concrete realisation. if our analysis was based on such a perfect ledger, it Organisation. In Section2 we present preliminaries for would not be relevant for any real world deployment the model we employ and the relevant cryptographic of a payment network since such software would primitives. In Section3 we present an overview of the – necessarily – depend on a non-perfect ledger. lightning network, accompanied by figures of the rele- This choice also distinguishes our work compared to vant transactions. Our payment network functionality is previous attempts [13], [14], [15], [16] to formalize given an overview description in Section4. Our abstrac- payment networks, as well as highlights the consid- tion of the core lightning protocol is provided in Sec- erable latency improvement that the protocol offers tion5. We give more details about the combined digital in comparison to directly using the ledger. signature primitive in Section6. In Section7 we provide an overview of the security proof of the main simulation Related Work. A first suggestion for building a uni- theorem. Finally, in Section8 we formalise our claim directional payment channel appeared in [17]. Bidirec- that a ledger functionality with instant finality is un- tional payment channels were developed in [18] and of realisable. We refer the reader to the appendix of the course as part of the lightning network [8]. Subsequent full version [25] for the formal definition of the paynet work on the topic dealt with either improving payment functionality FPayNet and the protocol ΠLN, along with networks by utilising more expressive blockchains such the proof that the latter UC-realises the former. Our as Ethereum [16], hardware assumptions, see e.g., [19], claim on the unrealisability of a perfect ledger is also or extending its functionality beyond payments, to smart proven there. contracts, [15] or finally enhancing their privacy, see e.g., [14], [20], [21]. Additional work looked into develop- 2. Preliminaries ing supporting protocols for the payment networks such as rebalancing [22] or finding routes in a decentralised In this section we give a brief overview of the tools fashion [23], [24]. With respect to idealising the pay- and frameworks used in this work. ment network functionality in the UC setting, a number Universal Composability framework. In of previous papers [13], [14], [15], [16] presented ideal simulation-based security, cryptographic tasks are functionalities abstracting the concept, but they did not defined via an ideal “functionality” F, which can be prove that the lightning network realises them. The main thought of as an uncorruptible entity that gets the advantage of our approach however here is that, for the inputs of all parties and returns the expected outputs first time, we present a payment network functionality while also interacting with the adversary in a prescribed that interoperates with a global ledger functionality for manner. In this way, the functionality expresses the which we know, in light of the results of [10], that essence of a cryptographic task and its security features. is realisable by the Bitcoin blockchain and hence also A protocol Π realises the functionality F if for any reflects the actual parameters that can be enforced by real world adversary we can define a “simulator” S, the implementation and the exact participation condi- acting as an ideal world adversary, such that any tions needed for security. In contrast, previous work [13], environment E cannot distinguish between the real [14], [16] utilized “too idealised” ledger functionalities world and the ideal world executions. Albeit a powerful

3 tool, simulation-based security only works when a single directly by the environment, whereas FPayNet is not. instance of the protocol is run in isolation. However, Transaction structure. GLedger does not define what is real-world systems almost always run several programs a valid transaction, but leaves it as a system parameter. concurrently, which furthermore may run different Importantly, no notion of coins is built in GLedger. We instances of the same protocol. To facilitate this, the therefore specify a valid transaction, closely following Universal Composability [26] framework allows us to concepts put forth in Bitcoin [2], but avoiding specifying analyse a single instance of the protocol and then the entire Bitcoin script. take advantage of a generic composition theorem to At a high level, every transaction consists of inputs infer the security of the protocol more broadly. This is and outputs. Each output has an associated value in achieved by allowing arbitrary interactions between the coins and a number of “spending methods”. A spending environment and the real-world adversary. method specifies the exact requirements for spending the As mentioned, lightning network members have to output. Each input must be connected to exactly one periodically check the blockchain to ensure the security output and satisfy one of its spending methods. of their funds. However, the execution model of the UC Transactions in GLedger form a DAG. A new trans- framework allows E to impose extended periods of inac- action is valid only if each of its inputs correctly spends tivity to any party. We opted to avoid the complication an output with no other connected input and the sum of using the clock functionality to force regular activa- of the values of its outputs does not exceed the sum of tion. Restricting the analysis only to environments that the values of the outputs connected to its inputs. We always cater for the needed activations would preclude refer the reader to the full version [25] for a complete the composability of our model. We instead allow E to overview. deny activation to players (therefore becoming negli- Cryptographic Primitives. In the Lightning Network gent) and provide security guarantees conditional on E specification, a custom scheme for deriving keys is used. permitting the necessary monitoring of the blockchain. Its syntax and security aims closely match those of pre- Hybrid functionalities used. Both our main protocol viously studied Identity Based Signature schemes [28], and the corresponding functionality use GLedger [10], [29], thus we use the latter to abstract away the com- [11] as a hybrid. GLedger formalizes an ideal distributed plexity of the construction and highlight the security append-only data structure akin to a blockchain. Any requirements it satisfies. We slightly modify previous participating party can read from GLedger, which returns IBS schemes by adding an algorithm that, on input of an ordered list of transactions. Furthermore parties can the public parameters mpk and a label l, returns the submit new transactions which, if valid, will be added verification key pkl. Such an IBS scheme provides 5 to the ledger and made visible to all parties at the algorithms: discretion of the adversary, but necessarily within a k • (mpk, msk) ← Setup(1 ): master keypair genera- predefined time window. This property is called liveness. tion Once a transaction is added to the ledger, it becomes • (pkl, skl) ← KeyDer(mpk, msk, l): keypair deriva- visible to all parties at the discretion of the adversary, tion with label l but within another predefined time window, and cannot • pkl ← PubKeyDer(mpk, l): verification key be removed or reordered. This is called persistence. The derivation with label l exact definition can be found in the full version [25]. • σ ← SignIBS(m, skl): signature generation with The current work makes heavy use of these two security signing key skl properties, as the security of the lightning network relies • {0, 1} ← VerifyIBS(σ, m, pkl): signature verifica- crucially on the security of the underlying ledger. tion Furthermore, G needs the G functionality, Ledger clock We refer the reader to [29] for more details. Other which models the notion of time. Every participating cryptographic primitives used are digital signatures and party can request to read the current time (which is pseudorandom functions. Finally, a less common two- initialized to 0) and inform G that her round is over. clock party cryptographic primitive is employed that we for- G increments the time by one once all parties have clock malise as combined digital signatures, see Section6. declared the end of their round. As already mentioned, the protocol and functionality defined in the current work do not make direct use 3. Lightning Network overview of Gclock. Indeed, the only notion of time both in the lightning protocol and in our work is provided by the Two-party channels. The aim of LN is to enable fast, height of the blockchain, as reported respectively by cheap, off-chain transactions, without compromising se- the underlying Bitcoin node and GLedger. We therefore curity. Specifically no trust between counterparties is omit it in the statement of Theorem2 for simplicity needed. This is achieved as follows: Two parties that of notation; it should normally appear as hybrid along plan to have recurring monetary exchanges lock up some with GLedger. Its exact definition can be found in the full funds with one special on-chain transaction. We say that version [25]. We also note that GLedger and Gclock are they opened a new channel. They can then transact with global functionalities [27] and therefore can be accessed the locked funds multiple times solely by interacting

4 privately, without informing the blockchain. If they want be able to spend the appropriate share from the coins to use their funds in the usual, on-chain way again, they contained in the funding output. Second, the two old have to close the channel and unlock the funds with one commitment transactions are revoked. This ensures that more on-chain transaction. Each party can unilaterally no party can close a channel using an old commitment close the channel and retrieve the coins they are entitled transaction which may be more beneficial to her than to – according to the latest channel state – and thus the latest one. neither party has to trust the other. Invalidating past commitments requires some care. In more detail, to open a channel Alice and Bob The reason is that it is impossible to actually make past first exchange a number of keys and desired timelocks commitments invalid without spending the funding out- relDelA, relDelB (explained below) and then build lo- put on-chain; doing this for every update would however cally some transactions. The “funding transaction” F defeat the purpose of LN. The following idea is leveraged contains a 2-of-2 multisig output with one “funding” instead: If Alice broadcasts an old commitment and Bob public key pkF,A, pkF,B for each counterparty. This mul- sees it, he can punish Alice by taking all the money in the tisig output needs signatures for both designated public channel. Therefore Alice is technically able to broadcast keys in order to be spent. F is funded with cF coins that an old commitment, but has no financial benefit in belong only to one of the two parties, say Alice. doing so. The same reasoning holds if Bob broadcasts an old commitment. On the donwside this imposes the requirement that parties must observe the blockchain pk ∧ pk F ,A F ,B periodically — see below the explanation of timelocks funding c F and how they facilitate a time window within which parties should react. Figure 1. Funding TX (on-chain): Rules over, coins below output. The punishing mechanism operates as follows. Sup- pose Alice considers posting her old local commitment Each party also builds a slightly different version of which has an output that carries her old share of the the “commitment transaction” CA,CB. Alice uses her funds. This output can be spent in two ways: either “delayed payment” key pkdcom,A and Bob’s “revocation” with a signature by Alice’s “delayed payment” secret key pkrev,B (received before), whereas Bob uses Alice’s key skdcom,A which is a usual ECDSA key, or with “payment” key pkcom,A (received before). Both CA and a signature by Bob’s “revocation” secret key skrev,B, CB spend the funding output of F and allow Alice to which is also an ECDSA key, but with an additional retrieve her funds if she acts honestly, as we will explain characteristic that we will explain soon. Thus, if Alice shortly. Alice sends Bob the signature of CB made with broadcasts an old commitment, Bob will be able to her skF,A and vice-versa. obtain her funds by spending her output using his “revo- cation” key. This privilege of course opens the possibility for Bob to abuse it (in particular, when a channel is pkrev,B∨ σF ,A ∧ σF ,B closed — see below — Bob may steal Alice’s funds by commA (relDelB ∧ pkdcom,A) funding c using such a revocation key) and hence this side effect F should also be carefully mitigated. The mitigation has the following form. At the time of creation of a new Figure 2. Alice’s initial commitment TX (off-chain): Required data commitment, both parties will know Bob’s “revocation” over input, spent output below input. public key pkrev,B, but no party knows its corresponding secret – the key can only be computed by combining one secret value skcom,n,A that Alice knows and one secret ∧ σF ,A σF ,B pkcom,A value skcom,n,B that Bob knows. Alice therefore can pre- commB funding cF vent Bob from using his revocation key until she sends him skcom,n,A. Therefore, Alice will send Bob skcom,n,A Figure 3. Bob’s initial commitment TX (off-chain): All coins belong only after the new commitment transaction is built and to Alice, so she can immediately spend them if Bob closes. signed. Thus Bob cannot abuse his revocation key on a commitment before this transaction is revoked. We She now broadcasts F ; once both parties see that it note that the underlying cryptographic mechanism that is confirmed, they generate and exchange new “commit- enables such “revocation keys” is not straightforward ment” keys (used for updating the channel later) and and, as part of our contributions, we formalise it as a new the channel is open. two-party cryptographic primitive. We call it “combined Every time they want to make a payment to each signature” and we prove that the construction hidden in other, they exchange a series of messages that have the LN implementation realizes it in the random oracle two effects. First, a new pair of commitment transac- model under the assumption that the underlying digital tions, along with their signatures by the funding keys, signature scheme is secure in the full version [25]. is created, one for each counterparty. Each of these The last element needed to make channel updates transactions ensures that, if broadcast, each party will secure is the already mentioned “relative timelock”. If

5 Figure 4. All transactions of an open channel with an HTLC in flight. Alice owns cA coins, Bob cB coins, and ch coins will be transferred to Bob if he discloses the preimage of h until the ledger has heightcltv blocks, otherwise they will return to Alice. “funding” is in the ledger, Alice keeps locally “commA” and “HTLCA”, and Bob keeps “commB ” and “HTLCB ”.

Alice broadcasts a commitment transaction, she is not a serious limitation. LN goes beyond that by allowing allowed to immediately spend her funds with her “de- multi-hop payments. In a situation where Alice has a layed payment” key. Instead, she has to wait for the channel with Bob and he has another channel with transaction to reach a pre-agreed block depth (the rel- Charlie, it is possible for Alice to pay Charlie off- ative timelock, negotiated during the opening of the chain by leveraging Bob’s help. Remarkably, this can channel and hardcoded in the output script of the com- be achieved without any one party trusting any of the mitment transaction) in order to give some time to Bob other two. One can think of Alice giving some “marked” to see the transaction and, if it does not correspond money to Bob, who in turn either delivers it to Charlie to the latest version of the channel, punish her with or returns it to Alice – it is impossible for Bob to keep his “revocation” key. This avoids a scenario in which the money. It is also impossible for Alice and Charlie to Alice broadcasts an old commitment transaction and make Bob pay for this transaction out of his pocket. immediately spends her output, which would prevent We will now give a brief overview of how this coun- Bob from ever proving that this commitment was old. terintuitive dynamic is made possible. Alice initiates the Lastly, if Alice wants to unilaterally close a channel, payment by asking Charlie to create a new hash for a all she has to do is broadcast her latest local commit- payment of x coins. Charlie chooses a random secret, ment (the only one not revoked) and any outstanding hashes it and sends the hash to Alice. Alice promises HTLC transactions (explained below) and wait for the Bob to pay him x in their channel if he shows her timelock to expire in order to spend her funds. The the preimage of this particular hash within a specific LN specification further allows for cooperative channel time frame. Bob makes the same promise to Charlie: if closure, achieved by negotiating and broadcasting the Charlie tells Bob the preimage of the same hash within a “closing transaction” which is not encumbered with a specific time frame (shorter than the one Bob has agreed timelock, providing immediate availability of funds. with Alice), Bob will pay him x in their common channel. As mentioned timelocks provide specific time win- Charlie then sends him the preimage (which is the secret dows within which both parties have to check the he generated initially) and Bob agrees to update the blockchain in order to punish a misbehaving counter- channel to a new version where x is moved from him party who broadcasts an old commitment transaction. to Charlie. Similarly, Bob sends the preimage to Alice This means that parties have to be regularly online to and once again Alice updates their channel to give Bob safeguard against theft. Furthermore, LN makes it possi- x coins. Therefore x coins were transmitted from Alice ble to trustlessly outsource this to so-called watchtowers, to Charlie and Bob did not gain or lose anything, he but this mechanism is not analyzed in the current work. just increased his balance in the channel with Alice and Multi-hop payments. Having funds locked down for reduced his balance by an equal amount in the channel exclusive use with a particular counterparty would be with Charlie.

6 This type of promise where a preimage is exchanged pchid) or (forceCloseChannel, receipt, pchid) from for money is called Hashed Time Locked Contract Alice (for a cooperative or unilateral close respectively), (HTLC). It is enforceable on-chain in case the payer it leaks to S the fact that E wants to close the relevant does not cooperatively update upon disclosure of the channel. preimage, thus no trust is needed. It is realised as In order to provide security guarantees, there are an additional output of the commitment transactions, various moments when FPayNet verifies whether certain which contains the specified hash and transfers its funds expected events have actually taken place. A number of either to the party that should provide the preimage messages prompt FPayNet to read from GLedger and per- or to the other party after a timeout. A corresponding form these checks. In the actual implementations of LN “HTLC transaction” that can spend this output is built these checks are done periodically by a polling daemon. by each party. In the previous example with Alice, Bob Such checks are done by FPayNet in the following cases: and Charlie, two HTLC transactions were signed and fulfilled in total for the payment to go through. Two up- • On receiving (poll) by Alice, FPayNet asks GLedger dates happened in each channel: one to sign the HTLC for Alice’s latest state ΣAlice and verifies that no and one to fulfill it. The time frames were chosen so bad events have happened. In particular, FPayNet that every intermediary has had the time to learn the halts if any of Alice’s channels has been closed preimage and give it to the previous party on the path. maliciously with a transaction at height h and, Figure4 shows all transactions implicated in a channel even though Alice has polled within [h, h + that has an HTLC in flight. delay(Alice) − 1], she did not manage to punish In LN zero-hop payments are also carried out using the counterparty. If FPayNet does not halt, it leaks HTLCs. to S the polling details (including the identity of LN gives the possibility for intermediaries to charge the poller and the state of the ledger in their view). a fee for their service, but such fees are not incorpo- • FPayNet expects S to send a (resolvePays, rated in the current analysis for the benefit of avoid- charged) message that gives details on the outcome ing the added complexity and making it easier for the of one or more multi-hop payments that include the functionality to keep track of the correct balances. We identity of the party that is charged. Moreover, for note in passing that the “wormhole” attack described each resolved payment, the message includes two in [30] is captured by our model, as an adversary that expiry values, expressed in absolute block height: controls two non-neighbouring nodes on a payment path OutgoingCltvExpiry, which is the highest block can skip the intermediate nodes. Nevertheless, such an in which the charged party could claim money attack is inconsequential in our analysis given the lack of from the previous hop (closer to the payer) and fees. Furthermore, LN leverages the Sphinx onion packet IncomingCltvExpiry, which is the lowest block in scheme [31] to increase the privacy of payments, but we which the charged party could claim money from do not formaly analyze the privacy of LN in this work – the next hop (closer to the payee). FPayNet checks we just use it in our protocol description to syntactically that for each payment the charged party was one match the message format used by LN. of the following: (a) the one that initiated the pay- ment, (b) a malicious party or (c) an honest party 4. Overview of F that is negligent. The latter case happens when the PayNet honest party either: One of our contributions is the specification of 1) did not poll in time to catch a malicious closure FPayNet, a functionality that describes the functional (similarly to the check performed when a poll and security guarantees given by an ideal payment message is handled, as described above) or network. Its definition can be found in the full ver- 2) did not poll twice while the block sion [25]. The central aim of FPayNet is opening payment height in the view of the player was in channels, keeping track of their state, updating them [OutgoingCltvExpiry, IncomingCltvExpiry − according to requested payments and closing them, as (2 + r) windowSize] with a distance of at least requested by honest players, all in a secure manner. In (2 + r) windowSize between the two polls or particular, the three main messages it can receive from 3) did not enforce the retrieval of the funds lost Alice are (openChannel), (pay), (closeChannel) as a result of this payment when the chain and (forceCloseChannel). in her view had height IncomingCltvExpiry − When FPayNet receives (openChannel, Alice, Bob, (2 + r) windowSize with a fulfillOnChain x, tid) from Alice, it informs simulator S of the intention message, as discussed below. of environment E to create a channel between Alice Note that (2 + r) windowSize is the maximum and Bob where Alice owns x coins. When it receives −−→ number of blocks an honest party needs to wait (pay, Bob, x, path, receipt) from Alice, it informs S from the moment a valid transaction is submitted that E asked to perform a multi-hop payment of x until it is added to the ledger state. F also −−→ PayNet coins from Alice to Bob along the path. In the same ensures that the two expiries (OutgoingCltvExpiry vein, when FPayNet receives (closeChannel, receipt, and IncomingCltvExpiry) have a distance of at

7 least relayDelay(Alice) + (2 + r) windowSize, oth- most complex part of LN is arguably the negotiations erwise it halts. In case the charged party was honest that happen when a multi-hop payment takes place, and non-negligent, FPayNet halts. It also halts if a due to the many channel updates needed; indeed, two particular payment resulted in a channel update for complete channel updates for each hop are needed for which S did not inform FPayNet. a successful payment to go through. The fact that a • FPayNet executes the function checkClosed(ΣAlice) proposal for an update can happen asynchronously with every time it receives ΣAlice from GLedger. In this the commitment to this update, along with the fact that case, it checks that every channel that E has asked a single commitment may commit to many indiviual to be closed or S designated as closed indeed has update proposals only adds to the complexity. It is a closing transaction that corresponds to its latest therefore only natural to want FPayNet to be unaware state in ΣAlice. Enough time is given for that trans- of these details. In order to disentangle the abstraction action to settle in ΣAlice, but if that time passes of FPayNet from such minutiae, we allow the adversary and the channel is still open or it is closed to a full control of the updates that are reported back to wrong version and no opportunity for punishment E via FPayNet. Nevertheless, FPayNet enforces that any was given, FPayNet halts. reporting deviations induced by the adversary will be A number of messages that support the protocol caught when a channel closes. This is quite intuitive: progress are also handled: Consider a user of the payment network that does not understand its inner workings but can read GLedger and • Every player has to send (register, delay, relay- count her funds there. FPayNet provides no guarantees Delay) before participating in the network. This regarding any specific interim reporting but the user is informs FPayNet how often the player has to poll. assured that in case she chooses to close the relevant “delay” corresponds to the maximum time between channel, her state in GLedger will be consistent with all polls so that malicious closures will be caught. the payments that went through. “relayDelay” is useful when the player is an interme- diary of a multi-hop payment. It roughly represents 5. Lightning Protocol Π Overview the size of the time window the player has to learn a LN preimage from the next and reveal it to the previous In order to prove that software adhering to the LN node. Subsequently FPayNet asks S to create and specification fulfills the security guarantees given by send a public key that will hold the player’s funds. FPayNet, a concrete protocol that implements LN in the This public key is subsequently sent back to the UC model is needed. To that end we define the formal player. protocol ΠLN, an overview of which is given here. • To complete her registration, Alice has to send the For the rest of this section, we will assume that (toppedUp) message. It lets FPayNet know that the Alice, Bob and Charlie are interactive Turing machine desired amount of initial funds have been trans- instances (ITIs) [26] that honestly execute ΠLN. Sim- ferred to Alice’s public key. FPayNet reads Alice’s ilarly to the ideal world, the main functions of Π state on G to retrieve this number and subse- LN Ledger are triggered when it receives (openChannel), (pay), quently allows Alice to participate in the payment (closeChannel) and (forceCloseChannel) from network after it updates her . onChainBalance E. These three messages along with (getNews) in- • When FPayNet receives (checkForNew, Alice, formally correspond to actions that a “human user” Bob, tid) from Alice, it asks G for Alice’s latest Ledger would instruct the system to perform. (register) and state Σ and looks for a funding transaction F Alice (toppedUp) are sent by E for player intialization. The in it. If one is found, S is asked to complete the rest of the messages sent from E prompt ΠLN to perform opening procedure. actions that a software implementation would sponta- • (pushFulfill, pchid), (pushAdd, pchid) and neously perform periodically. All messages sent between (commit, pchid) all nudge S to carry on with the Alice, Bob and Charlie correspond to messages specified protocol that updates the state of a specific channel. by LN. For clarity of exposition, we avoid mentioning FPayNet simply forwards these messages to S. the exact name and contents of every message. We refer • (fulfillOnChain) prompts S to close channels in the reader to the formal definition of ΠLN for further which the counterparty is not willing to pay, even details [25]. though they have promised to do so upon disclosure Registration. Before Alice can use the network, E first of a particular preimage. This message is simply has to send her a (register, delay, relayDelay) message. forwarded to S, but FPayNet takes a note that such She generates her persistent key and sends it back to E. a message was received and the current blockheight The latter may choose to add some funds to this key and in the view of the calling party. then send (toppedUp) to Alice, who checks her state Last but not least, E sends (getNews) to obtain in GLedger and records her on-chain balance. the latest changes regarding newly opened or closed Channel opening. When she receives (openChannel, channels, along with updates to the state of existing Alice, Bob, x, tid) from E, Alice initiates the message ones. Here we make an interesting observation: The sequence needed to open a channel with Bob, funded by

8 her with x coins. After following the steps described in to the appropriate value after the payment is complete. Section3, the funding transaction has been submitted After this last update, each party keeps a note to inform to GLedger. However the channel is not open yet. E about the new balance when it receives (getNews). At a later point E may send (checkForNew, Alice, Alice and Charlie also keep a note to inform E that the Bob, tid) to Alice. She then checks if her state in GLedger payment it had asked for succeeded. contains the funding transaction with the temporary ID Observe that while locked up in an HTLC, funds do tid and in that case she exchanges new commitment keys not belong to either player; they are rather in a tempo- with Bob, as per Section3. The channel is now open. rary, transitive state. If one party learns the preimage, Both parties keep a note to give E a receipt of the new the funds become theirs, whereas if it does not learn the channel the next time they receive (getNews). preimage after some time, the other party is entitled Channel closing. When sent by E, the messages to the funds. Also observe that within the UC frame- closeChannel and forceCloseChannel prompt work the necessary messages commit, pushFulfill Alice to close the channel cooperatively or unilaterally and pushAdd may never arrive, but in a correct soft- respectively, as explained in Section3. In both cases she ware implementation the corresponding actions happen takes a note to notify E that the channel is closed when automatically, without waiting for a prompt by the user. she receives (getNews). Polling. Lastly, E may send (poll) to Alice. She then Performing payments. We will now follow the exact reads her state in GLedger and checks for closed channels. steps needed for a multi-hop payment, filling in many de- If she finds maliciously closed channels (closed using old tails that we omitted from Section3. When she receives −−→ commitments), she punishes the counterparty and takes (pay, Charlie, x, path) from E, Alice attempts to pay all the funds in the channel. If she finds in an honestly −−→ Charlie x coins, using the provided path. Let us assume closed channel a preimage of an HTLC that she has that the path is Alice – Bob – Charlie. Alice asks Charlie previously signed and for which she is an intermediary, for an “invoice” with the HTLC hash, to which Charlie she records it and prepares to send it when she receives reacts by choosing a random preimage and sending back (pushFulfill). Finally, if she finds an honestly closed to Alice its hash. Alice then prepares a Sphinx [31] onion channel with an HTLC output for which she knows the packet with the relevant information for each party on preimage, she spends it immediately. For every closed −−→ the path and sends it to Bob. Bob peels his layer of the channel she finds, she keeps a note to report it to E the onion and, after performing sanity checks and extracting next time she receives (getNews). the hash, he takes a note of this pending HTLC. He does Remark 1 (Differences between LN and ΠLN). In LN, a not yet forward the onion to Charlie, because Alice is custom construction for generating a new secret during not yet committed to paying Bob. The latter happens each channel update is used. It reduces the space needed if Alice subsequently receives (commit, pchidAB) from to maintain a channel from O(n) to O(log n) in the E, where pchidAB is the ID of the Alice – Bob channel. number of updates. As far as we know, its security has She then sends Bob all the signatures needed to make not been formally analyzed. In the current paper we use the new commitment transaction spendable, who replies instead a PRF [32]. with the secret commitment key of the old commitment As mentioned earlier, LN uses a custom construc- transaction (thus revoking it), along with the public tion that takes advantage of elliptic curve homomorphic commitment key of the future commitment transaction properties in order to derive any number of keypairs by (to allow Alice to prepare the next update, when that combining a single “basepoint” with different “labels”. happens). LN demands that before Bob forwards the We instead use Identity Based Signatures [28], [29] (IBS) onion to Charlie, he must commit as well to the HTLC to to abstract the properties provided by the construction. Alice. This happens if he receives the relevant commit We also prove in the full version [25] that it actually message from E. Now that both parties have the HTLC implements an IBS. in their commitment transaction and all past commit- Additionally, we have chosen to simplify the protocol ment transactions are revoked, they consider this HTLC in a number of ways in order to keep the analysis “irrevocably committed”. tractable. In particular LN defines several additional Bob may then receive (pushAdd, pchidAB) from E. messages that signal various types of errors in transmis- Bob sends the onion to Charlie, who in turn peels it, sion. It also specifies exactly how message retransmission recognizes that the payment is for him and that indeed should happen upon reconnection, specifically for the he knows the preimage (since he generated it himself) case of connection failure while updating a channel. This and waits for the HTLC between him and Bob to be allows for a more robust system by excluding many cases irrevocably committed. After both Bob and Charlie of accidental channel closures. What is more, an LN user receive (commit), Charlie awaits for a (pushFulfill, can change their “delay” and “relayDelay” parameters pchidBC ) message from E. If it arrives, Charlie sends the even after registration, which is not the case in ΠLN. preimage to Bob, who sends it back to Alice. Once more Lastly, in order to incentivize users to act as interme- every party has to receive a (commit) message for each diaries or check for channel closures on behalf of others, of the channels it participates in in order to remove the LN provides for fees for these two roles. Furthermore, in HTLC and update the definitive balance of each player order to reduce transaction size and ensure that bitcoin

9 nodes relay the transactions, it specifies exact rules cpk2 ← CombinePubKey (mpk, pk) , for pruning outputs of too low value (known as “dust cpk1 = cpk2] = 1 outputs”). In the current analysis we do not consider I.e. for suitable input, CombinePubKey() and these features. CombineKey() produce the same public key. • ∀k ∈ N, m ∈ M, k
6. The Combined Signature primitive Pr[(mpk, msk) ← MasterKeyGen 1 , (pk, sk) ← KeyShareGen 1k
, (cpk, csk) ← CombineKey (mpk, msk, pk, sk) , As previously mentioned, we define a new primitive VerifyCS(SignCS(m, csk), m, cpk) = 1] = 1 for combining keys and generating signatures, which is I.e. for suitable input, honestly generated signatures leveraged in the revocation and punishment mechanism always verify correctly. of channel updates. Furthermore, we prove that the Beyond correctness, combined signatures have two construction designed by the creators of LN realizes security properties expressed as follows. Share-EUF se- this primitive. We provide here the concrete syntax and curity expresses security from the point of view of Alice, correctness definitions, along with the intuition behind and establishes that Bob cannot issue a valid combined it, the exact security definitions, a concrete construction signature if he does not possess Alice’s corresponding and proof of its security. secret share. Formally: Previous work on the subject of multi-party sig- natures [12], [33], [34], [35], [36], [37] focuses on use- A k
cases where some parties desire to generate a signature Game share-EUF 1 without revealing their private information; the latter 1: (aux, mpk, n) ← A (init) is created using an interactive protocol. The resulting 2: for i ← 1 to n do k
signatures can be verified by a single verification key, 3: (pki, ski) ← KeyShareGen 1 4: end for which is also included in the output of the key gener- ∗ ∗ ∗ ∗ 5: (cpk , pk , m , σ ) ← A (keys, aux, pk1, . . . , pkn) ation protocol. As we will see however, the primitive ∗ defined here has different aims and limitations and, to 6: if pk ∈ {pk1, . . . , pkn} ∧ cpk∗ = CombinePubKey (mpk, pk∗) ∧ our knowledge, has not been formalized yet. ∗ ∗ ∗ VerifyCS (σ , m , cpk ) = 1 then A combined signature is a two-party primitive, say 7: return 1 between Alice and Bob, with Bob being the signer and 8: else Alice the holder of a share of the secret key. This 9: return 0 share is essential for issuing signatures, which in turn 10: end if are verifiable with the “combined” verification key. The verification key is generated using public information Definition 1. A Combined Signatures scheme is share- drawn from Alice and Bob and is feasible without any EUF-secure if party knowing the corresponding signing key. Bob will h i be able to construct the signing key only if Alice shares ∀A ∈ PPT, Pr share-EUFA 1k
= 1 = negl (k) her secret information with him. or equivalently More specifically, the seven algorithms used by a Combined Signatures scheme are: E-share(k) = negl (k) , k
A k
• (mpk, msk) ← MasterKeyGen 1 where E-share(k) = sup {Pr[share-EUF 1 = 1]} k
A∈PPT • (pk, sk) ← KeyShareGen 1 • cpkl ← CombinePubKey (mpk, pk) On the other hand, master-EUF-CMA security is • (cpkl, cskl) ← CombineKey (mpk, msk, pk, sk) modeled very similarly to standard EUF-CMA security, • {0, 1} ← TestKey (pk, sk) with the difference that Bob (the signer) combines ma- • σ ← SignCS (m, csk) licious shares into his public key and issues signatures • {0, 1} ← VerifyCS (σ, m, cpk) with respect to such combined keys. The security prop- We demand that these three properties hold for a scheme erty ensures that these signatures provide no advantage to have correctness: to the adversary in terms of producing a forged message for a combined key of its choice. Formally: • ∀k ∈ N, k
Pr[(pk, sk) ← KeyShareGen 1 , Game master-EUF-CMAA 1k
TestKey(pk, sk) = 1] = 1 I.e. KeyShareGen() must always generate a valid 1: (mpk, msk) ← MasterKeyGen 1k
keypair. 2: i ← 0 • ∀k ∈ N, 3: (auxi, response) ← A (init, mpk) Pr[(mpk, msk) ← MasterKeyGen 1k
, 4: while response can be parsed as (pk, sk, m) do 5: i ← i + 1 (pk, sk) ← KeyShareGen 1k
, (cpk1, csk1) ← CombineKey (mpk, msk, pk, sk) ,

10 6: store pk, sk, m as pki, ski, mi 7: (cpki, cski) ← CombineKey (mpk, msk, pki, ski) return SignDS(m, csk) 8: σi ← SignCS (mi, cski) VerifyCS(σ, m, cpk): 9: (auxi, response) ← A (signature, auxi−1, σi) 10: end while return VerifyDS(σ, m, cpk) 11: parse response as (cpk∗, pk∗, m∗, σ∗) ∗ One can check by inspection that the syntax above 12: if m ∈/ {m1, . . . , mi} ∧ matches the one required by the Combined Signa- cpk∗ = CombinePubKey (mpk, pk∗) ∧ ∗ ∗ ∗ tures scheme definition. Furthermore, assuming that VerifyCS (σ , m , cpk ) = 1 then 13: return 1 SignDS() and VerifyDS() are provided by a correct 14: else Digital Signature construction, it is straightforward to 15: return 0 confirm that the construction here satisfies the Com- 16: end if bined Signatures correctness properties. We now move on to proving that the construction is Definition 2. A Combined Signatures scheme is master- also secure. EUF-CMA-secure if Lemma 1. The construction defined above is share-EUF- ∀A ∈ PPT, secure in the Random Oracle model under the assump- h i Pr master-EUF-CMAA 1k
= 1 = negl (k) tion that the underlying signature scheme is strongly EUF-CMA-secure and the range of the Random Oracle or equivalently coincides with that of the underlying signature scheme E-master(k) = negl (k) , signing keys. where Proof: Let k ∈ N, B PPT algorithm such that E-master(k) = sup {Pr[master-EUF − CMAA 1k
= 1]} h B k i A∈PPT Pr share-EUF 1
= 1 = a = non − negl (k) . Definition 3. A Combined Signatures scheme is combine-EUF-secure if it is both share-EUF-secure and We construct a PPT distinguisher A (Fig.5) such that master-EUF-CMA-secure. h A k
i In conclusion, a collection of algoritms is said to Pr EUF-CMA 1 = 1 = non − negl (k) be a secure Combined Signatures scheme if it conforms to the syntax of the seven aforementioned algorithms, that breaks the assumption, thus proving Lemma1. it satisfies the three correctness properties and pro- Let Y be the range of the random oracle. The mod- vides existential unforgeability against key-only attacks ified random oracle used in Fig.5 is indistinguishable with respect to key shares and existential unforgeability from the standard random oracle by PPT algorithms since the statistical distance of the standard random against chosen message attacks with respect to master 1 keys. oracle from the modified one is at most 2|Y | = negl (k) We here define the particular construction for Com- as they differ in at most one element. bined Signatures used in LN and prove its security. Let E denote the event in which B does not invoke Parameters: hash function H, group generator G CombinePubKey to produce cpk∗. In that case the val- ∗ ∗ MasterKeyGen(1k, rand): ues H (pk k mpk) and H (mpk k pk ) are decided after B terminates (Fig.5, line 24) and thus return (G · rand, rand) ∗ ∗ KeyShareGen(1k, rand): Pr [cpk = CombinePubKey (mpk, pk ) |E] = 1 return (G · rand, rand) = = negl (k) ⇒ |Y | CombinePubKey(mpk, pk): (1) Pr [cpk∗ = (mpk, pk∗) ∧ E] = return mpk ·H (mpk k pk) + pk ·H (pk k mpk) CombinePubKey = negl (k) . CombineKey(mpk, msk, pk, sk): return (CombinePubKey(mpk, pk), msk · It is H (mpk k pk) + sk ·H (pk k mpk)) (B wins) → (cpk∗ = CombinePubKey (mpk, pk∗)) ⇒ TestKey(pk, sk): Pr [B wins] ≤ if pk = G · sk then ∗ ∗ return 1 ≤ Pr [cpk = CombinePubKey (mpk, pk )] ⇒ else Pr [B wins ∧ E] ≤ return 0 ∗ ∗ (1) end if ≤ Pr [cpk = CombinePubKey (mpk, pk ) ∧ E] ⇒ SignCS(m, csk): Pr [B wins ∧ E] = negl (k) .

11 Algorithm A (vk) that in the event (F ∧ B wins ∧ ¬E), A wins the EUF- $ CMA game. A final observation is that the probability 1: j ← U [1,T (B)] // T (M) is the maximum running time of M that the events (B wins ∧ ¬E) and F are almost inde- 2: Random Oracle: for every first-seen query q from pendent, thus B set H (q) to a random value Pr [F ∧ B wins ∧ ¬E] = 3: return H (q) to B (2) 4: (aux, mpk, n) ← A (init) = Pr [F ] Pr [B wins ∧ ¬E] ± negl (k) = 5: for i ← 1 to n do k
a − negl (k) 6: (pki, ski) ← KeyShareGen 1 ± negl (k) = non − negl (k) 7: end for T (B) 8: Random Oracle: Let q be the jth first-seen query from B: 9: if q = (mpk k x) then Lemma 2. The construction above is master-EUF-CMA- 10: if H (x k mpk) unset then secure in the Random Oracle model under the assump- 11: set H (x k mpk) to a random value tion that the underlying signature scheme is strongly 12: end if EUF-CMA-secure and the range of the Random Oracle 13: set H (mpk k x) to coincides with that of the underlying signature scheme (vk − x ·H (x k mpk)) · mpk−1 14: else if q = (x k mpk) then signing keys. 15: if H (mpk k x) unset then Proof: Let k ∈ N, B PPT algorithm such that 16: set H (mpk k x) to a random value h i 17: end if Pr master-EUF-CMAB 1k
= 1 = a = non − negl (k) . 18: set H (x k mpk) to −1 (vk − mpk ·H (mpk k x)) · x We construct a PPT distinguisher A (Fig.6) such that 19: else h i 20: set H (q) to a random value Pr EUF-CMAA 1k
= 1 = non − negl (k) 21: end if 22: return H (q) to B that breaks the assumption, thus proving Lemma2. ∗ ∗ ∗ ∗ 23: (cpk , pk , m , σ ) ← B (keys, aux, pk1, . . . , pkn) ∗ The modified random oracle used in Fig.6 is indis- 24: if vk = cpk ∧ B wins the share-EUF game then // tinguishable from the standard random oracle for the A won the EUF-CMA game ∗ ∗ same reasons as in the proof of Lemma1. 25: return (m , σ ) 26: else Let E denote the event in which CombinePubKey ∗ 27: return fail is not invoked to produce cpk . In that case the values ∗ ∗ 28: end if H (pk k mpk) and H (mpk k pk ) are decided after B terminates (Fig.6, line 30) and thus Pr [cpk∗ = (mpk, pk∗) |E] = Figure 5. CombinePubKey = negl (k) ⇒ (3) Pr [cpk∗ = CombinePubKey (mpk, pk∗) ∧ E] = But we know that Pr [B wins] = Pr [B wins ∧ E] + Pr [B wins ∧ ¬E] and Pr [B wins] = a by the assump- = negl (k) . tion, thus We can reason like in the proof of Lemma1 to deduce that Pr [B wins ∧ ¬E] > a − negl (k) . (2) Pr [B wins ∧ ¬E] > a − negl (k) . (4) We now focus at the event ¬E. Let F the event in We now focus at the event ¬E. Let F the event in which the call of B to CombinePubKey to produce which the call of to CombinePubKey that produces cpk∗ results in the jth invocation of the Random Or- cpk∗ results in the jth invocation of the Random Or- acle. Since j is chosen uniformly at random and using acle. Since j is chosen uniformly at random and using Proposition 1 of [25], Pr [F |¬E] = 1 . Observe that T (B) Proposition 1 of [25], Pr [F |¬E] = 1 . Observe 1 T (B)+T (A) Pr [F |E] = 0 ⇒ Pr [F ] = Pr [F |¬E] = T (B) . 1 that Pr [F |E] = 0 ⇒ Pr [F ] = Pr [F |¬E] = T (B)+T (A) . In the case where the event (F ∧ B wins ∧ ¬E) holds, Once more we can reason in the same fashion as in it is the proof of Lemma1 to deduce that ∗ ∗ cpk = CombinePubKey (mpk, pk ) = Pr [F ∧ B wins ∧ ¬E] = ∗ ∗ ∗ mpk ·H (mpk k pk ) + pk ·H (pk k mpk) (4) = Pr [F ] Pr [B wins ∧ ¬E] ± negl (k) = Since F holds, the jth invocation of the Random Oracle a − negl (k) queried either the value H (mpk k pk∗) or H (pk∗ k mpk). ± negl (k) = non − negl (k) In either case (Fig.5, lines9-18), it is cpk∗ = vk. This T (B) + T (A) means that VerifyCS (σ∗, m∗, vk) = 1. We conclude

12 Algorithm A (vk) tionality GLedger and assuming the security of the un- $ derlying digital signature, identity-based signature, com- 1: j ← U [1,T (B) + T (A)] // T (M) is the maximum running time of M bined digital signature and PRF. Specifically, 2: Random Oracle: for every first-seen query q from ∀k ∈ N, PPT E, B set H (q) to a random value GLedger FPayNet,GLedger 3: return H (q) to B | Pr[ = 1] − Pr[ = 1]| ≤ ExecΠLN,Ad,E ExecS,E k
4: (mpk, msk) ← MasterKeyGen 1 2nmE-ds(k) + 6npE-ids(k) + 2nmpE-share(k)+ 5: Random Oracle: Let q be the jth first-seen query +2nmE-master(k) + 2E-prf(k) , from B or A: 6: if q = (mpk k x) then where n is the maximum number of registered users, m is 7: if H (x k mpk) unset then the maximum number of channels that a user is involved 8: set H (x k mpk) to a random value in, p is the maximum number of times that a channel is 9: end if updated and the “E-” terms correspond to the insecurity 10: set H (mpk k x) to (vk − x ·H (x k mpk)) · mpk−1 bounds of the primitives. 11: else if q = (x k mpk) then Proof Sketch: The proof is done in 5 steps of suc- 12: if H (mpk k x) unset then cessive game replacement. In the first lemma, we define a 13: set H (mpk k x) to a random value simulator S that internally simulates a full execution 14: end if LN 15: set H (x k mpk) to of ΠLN for each player, and a “dummy” functionality (vk − mpk ·H (mpk k x)) · x−1 that acts as a simple relay between E and SLN. We argue 16: else that this version of the ideal world trivially produces the 17: set H (q) to a random value exact same messages for E as the real world. 18: end if In each subsequent step, we incrementally move re- 19: return H (q) to B or A sponsibilities from the simulator to the functionality, 20: i ← 0 while ensuring the change is transparent to both E 21: (auxi, response) ← B (init, mpk) and A. Each step defines a different functionality that 22: while response can be parsed as (pk, sk, m) do handles some additional messages from E exactly like 23: i ← i + 1 F , until the last step where we use F itself. 24: store pk, sk, m as pk , sk , m PayNet PayNet i i i Correspondingly, the simulator of each step is adapted 25: (cpki, cski) ← CombineKey (mpk, msk, pki, ski) 26: σi ← SignCS (mi, cski) so that the new ideal execution is computationally in- 27: (auxi, response) ← B (signature, auxi−1, σi) distinguishable from the previous one. For each step we 28: end while exhaustively trace the differences from the previous step 29: parse response as (cpk∗, pk∗, m∗, σ∗) in order to prove that, given the same messages from E 30: if vk = cpk∗ ∧ B wins the master-EUF-CMA game and A, the resulting responses remain unchanged. then // A won the EUF-CMA game ∗ ∗ The second step, lets F handle registration messages, 31: return (m , σ ) along with the corruption messages from S. In the third 32: else step, the functionality additionally handles messages 33: return fail 34: end if related to channel opening. It behaves like FPayNet, but does not execute checkClosed(). The fourth step, has the functionality handle all messages sent during Figure 6. channel updates. Lastly, the entire FPayNet is used as functionality, by incorporating the message for closing a channel, executing checkClosed() normally and hand- The two results can then be combined to obtain the ing the message that returns to E the receipts for newly desired security property: opened, updated and closed channels. The last two steps Theorem 1. The construction above is combine-EUF- introduce a probability of failure in case the various secure in the Random Oracle model under the assumption types of signatures used in ΠLN are forged. We analyze that the underlying signature scheme is strongly EUF- these cases separately and argue that, if such forgeries CMA-secure. do not happen, the emulation is perfect. Therefore we can calculate the concrete security bounds shown in the Proof: The construction is combine-EUF-secure as theorem. a consequence of Lemma1, Lemma2 and the definition As a concrete example of the proof approach, the of combine-EUF-security. second step entails the following parts: First FPayNet,Reg is defined, which is a functionality that behaves exactly 7. Security proof overview like FPayNet when receiving the messages register, registerDone, toppedUp and corrupted, but sim- Theorem 2 (Lightning Payment Network Security). ply forwards all other messages along with the sender to The protocol ΠLN realises FPayNet given a global func- S. Then SLN−Reg is defined, which simulates all protocol

13 instances, but in response to register messages from to Alice and then (read) to Bob. If, and only if, Bob FPayNet,Reg, it provides the public key of the key it knows m, then EPL concludes this is the ideal world. This just generated (as FPayNet,Reg expects). It also keeps forces the ΠPerfectL protocol to achieve instant finality track of corruptions and informs FPayNet,Reg thereof. and will establish that a distinguishing advantage exists Lastly, we argue that the functionality and simulator no matter how ΠPerfectL is implemented. that were used in the first step can be replaced by their newly defined counterparts without introducing Functionality F any discernible difference to the transcript that any E PerfectL sees. This is achieved by exhaustive enumeration of all 1: State: List of txs L possible messages and comparison of the behaviour of the ideal and the real world for each, to conclude that 2: Upon receiving (Submit, m) from Alice or A, the change is transparent to E. The formal proof can be append m to L and send (Submit, Alice or A, m) to found in the full version [25]. A 3: Upon receiving (Read) from Alice, send (Read, L) 8. Instant finality ledgers are unrealisable to Alice

As already mentioned, previous attempts at formal- 9. Future Work and Conclusion ising payment channels in UC [13], [14], [15], [16] as- sume a variant of a ledger functionality with instant In order to remain tractable, the current analysis finality. We here define a representative variant of this omits some parts of the lightning specification. In par- approach FPerfectL (defined below) where all submitted ticular, the specification defines how intermediaries of transactions are instantly added to the ledger and imme- multi-hop payments can charge a fee for their service. diately available to be read by all players. Subsequently Furthermore, the per-update secret generation is not we argue that, albeit an attractive abstraction, such done with a PRF according to the specification: an a functionality is unrealisable, even under strong net- optimisation that reduces the storage overhead for the work assumptions, i.e. a multicast synchronous network counterparty is used instead. The security of this opti- 1 misation however has not been yet formally inspected. FN-MC. Such a network ensures that messages sent by honest parties will be instantly delivered to all other Additionally, the specification provisions for a number parties; no delays can be introduced by the adversary. of failure messages that help in keeping counterparties We refer the reader to the full version [25] for the formal informed of issues with requested payments and in alle- 1 viating the problem of unneeded precautionary channel definition of FN-MC. The adversary however may choose to send its own messages only to specific parties. This closures. Transactions that are added on-chain offer a allows the adversary to spread conflicting information or fee to the blockchain miners (unrelated to the fee of the withhold data from some parties. This adversarial ability off-chain multi-hop payments). When closing a channel precludes the possibility of such a ledger to be realised. cooperatively, this fee is contributed by both counterpar- The complete proof can be found in the full version [25]. ties, therefore the closing sequence of the specification includes an iterative negotiation of said fee where the Theorem 3 (Perfect Ledger is Unrealisable). For any two parties repeatedly propose a value based on their ITM ΠPerfectL there exist ITMs EPL, APL such that for settings until they converge to a compromise or fail to any ITM S agree. Lastly, most Bitcoin nodes do not relay transac- 1 ¯ F ,Gclock FPerfectL,G¯ tions that include outputs with tiny amounts of coins, Exec N-MC 6≈ Exec clock ΠPerfectL,APL,EPL S,EPL a.k.a “dust” outputs, to avoid bloating the blockchain. Proof Sketch: We take advantage of APL’s abil- The lightning specification provides extensive instruc- ity to selectively send messages to specific players. In tions as to how to prune such outputs. particular, EPL starts an execution with two players and All aforementioned parts of the protocol were not generates a random message m. In half of the executions analysed so that the security of the core parts of the (randomly selected), the adversary simulates a “broken” lightning protocol could be discussed without distrac- ΠPerfectL execution where the effects of submitting m tions. In order for the analysis to cover the entirety of the are only shared with one of the two players, say Alice current version of the lightning specification however, by APL (in the real world). The environment then sends the aforementioned features should be incorporated and (read) to the other player, say Bob. If Bob returns a their security should be proven. This expansion of the ledger containing m, then EPL concludes that it is the analysis is left as future work. ideal world, otherwise it sends (read) to Alice. If she In a different direction, big parts of our main security returns a ledger with m, then EPL concludes it is in the proof consist of an exhaustive enumeration of the pos- real world, otherwise it concludes it is in the ideal world. sible messages that E and A can send to the protocol, The above is not sufficient since a protocol may the simulator or the functionality and tracking how such choose to return an empty ledger; to counter this, in messages would change the flow of the execution of the the other half of the executions, EPL sends (submit, m) ideal and the real world. It is then argued that in all

14 cases the messages that would be sent to E and A are [4] Pass R., Seeman L., Shelat A.: Analysis of the Blockchain indistinguishable. These parts of the proof are good Protocol in Asynchronous Networks. IACR Cryptology ePrint candidates for rewriting in the environment of an auto- Archive: vol. 2016, p. 454: URL http://eprint.iacr.org/2016/ 454 (2016) mated proof assistant [38] to instill additional certainty that all possible execution paths are indeed checked [5] Garay J. A., Kiayias A., Leonardos N.: The Bitcoin Back- bone Protocol with Chains of Variable Difficulty. In J. Katz, and do not contain subtle sources of distinguishability. H. Shacham (editors), Advances in Cryptology - CRYPTO Combining our results with the recent mechanization of 2017 - 37th Annual International Cryptology Conference, UC via Easycrypt [39] would be a natural and interesting Santa Barbara, CA, USA, August 20-24, 2017, Proceed- direction for future work. ings, Part I: vol. 10401 of Lecture Notes in Computer The lightning specification is not static, but it is con- Science: pp. 291–323: Springer: ISBN 978-3-319-63687-0: doi:10.1007/978-3-319-63688-7\_10: URL https://doi.org/ tinuously undergoing a number of improvements. The 10.1007/978-3-319-63688-7_10 (2017) most noteworthy upcoming change is the introduction [6] Pass R., Shi E.: Hybrid Consensus: Efficient Consensus in the of Pointlocked TimeLocked Contracts (PTLCs). This Permissionless Model. In A.W. Richa (editor), 31st Interna- mechanism replaces HTLCs and promises to combat the tional Symposium on Distributed Computing, DISC 2017, “wormhole” attack [30], while increasing privacy. Our October 16-20, 2017, Vienna, Austria: vol. 91 of LIPIcs: work can be modified to cover the case of PTLCs with pp. 39:1–39:16: Schloss Dagstuhl - Leibniz-Zentrum fuer In- relative ease. It also provides a suitable framework for formatik: ISBN 978-3-95977-053-8: doi:10.4230/LIPIcs.DISC. 2017.39: URL https://doi.org/10.4230/LIPIcs.DISC.2017.39 future work that aims to shed light on the exact privacy (2017) benefit that PTLCs offer as opposed to HTLCs. [7] Micali S.: ALGORAND: The Efficient and Democratic The present analysis constitutes the first comprehen- Ledger. CoRR: vol. abs/1607.01341: URL http://arxiv.org/ sive treatment in the Universal Composability frame- abs/1607.01341 (2016) work of a deployed layer-2 protocol on top of a functional [8] Poon J., Dryja T.: The Bitcoin Lightning Net- ledger. It can be extended and adapted to analyze other work: Scalable Off-Chain Instant Payments. similar protocols that achieve different security goals or https://lightning.network/lightning-network-paper.pdf use another ledger as base layer. (2016) Conclusion. The present work constitutes a fortu- [9] Pass R., Shi E.: Thunderella: Blockchains with Optimistic nate result, since it conclusively proves that software Instant Confirmation. In J.B. Nielsen, V. Rijmen (editors), Advances in Cryptology - EUROCRYPT 2018 - 37th An- that adhere to the lightning specification cannot lose nual International Conference on the Theory and Applica- funds accidentally to a malicious protocol player. Indeed, tions of Cryptographic Techniques, Tel Aviv, Israel, April such a result reinforces trust to the lightning network 29 - May 3, 2018 Proceedings, Part II: vol. 10821 of Lec- and acts as a guarantee to the almost 900 bitcoins ture Notes in Computer Science: pp. 3–33: Springer: ISBN 978-3-319-78374-1: doi:10.1007/978-3-319-78375-8\_1: URL currently in circulation in the layer-2 protocol. https://doi.org/10.1007/978-3-319-78375-8_1 (2018) By leveraging the guarantees provided by the Uni- versal Composability framework, we further assert that [10] Badertscher C., Maurer U., Tschudi D., Zikas V.: Bitcoin as a transaction ledger: A composable treatment. In Annual the lightning protocol is freely composable with other International Cryptology Conference: pp. 324–356: Springer protocols. As such it can run side by side with arbitrary (2017) protocols, or be used as a subroutine to higher-level [11] Badertscher C., Gaži P., Kiayias A., Russell A., Zikas V.: protocols without needing to prove its security anew. Ouroboros genesis: Composable proof-of-stake blockchains By separating particular subroutines of the protocol with dynamic availability. In Proceedings of the 2018 ACM as distinct cryptographic primitives and analysing them SIGSAC Conference on Computer and Communications Se- individually, we have contributed to its cryptorgaphic curity: pp. 913–930: ACM (2018) agility. Lastly, by keeping it as protocol-agnostic as pos- [12] Nicolosi A., Krohn M. N., Dodis Y., Mazières D.: Proactive sible, our payment network functionality can be adapted Two-Party Signatures for User Authentication. In Proceed- to express the functional and security requirements of ings of the Network and Distributed System Security Sym- posium, NDSS 2003, San Diego, California, USA: The Inter- other layer-2 protocols with relative ease. net Society: ISBN 1-891562-16-9: URL http://www.isoc.org/ isoc/conferences/ndss/03/proceedings/papers/15.pdf (2003) References [13] Dziembowski S., Faust S., Hostáková K.: General State Chan- nel Networks. In Proceedings of the 2018 ACM SIGSAC [1] Croman K., Decker C., Eyal I., Gencer A. E., Juels A., Kosba Conference on Computer and Communications Security, CCS A., Miller A., Saxena P., Shi E., Sirer E. G., et al.: On 2018, Toronto, ON, Canada, October 15-19, 2018: pp. 949– scaling decentralized blockchains. In International Conference 966: doi:10.1145/3243734.3243856: URL https://doi.org/10. on Financial Cryptography and Data Security: pp. 106–125: 1145/3243734.3243856 (2018) Springer (2016) [14] Malavolta G., Moreno-Sanchez P., Kate A., Maffei M., Ravi [2] Nakamoto S.: Bitcoin: A Peer-to-Peer Electronic Cash System S.: Concurrency and Privacy with Payment-Channel Net- (2008) works. In Proceedings of the 2017 ACM SIGSAC Confer- [3] Garay J., Kiayias A., Leonardos N.: The Bitcoin Back- ence on Computer and Communications Security: CCS ’17: bone Protocol: Analysis and Applications. Cryptology ePrint pp. 455–471: ACM, New York, NY, USA: ISBN 978-1-4503- Archive, Report 2014/765: https://eprint.iacr.org/2014/765 4946-8: doi:10.1145/3133956.3134096: URL http://doi.acm. (2014) org/10.1145/3133956.3134096 (2017)

15 [15] Miller A., Bentov I., Kumaresan R., Cordi C., McCorry [28] Shamir A.: Identity-Based Cryptosystems and Signature P.: Sprites and State Channels: Payment Networks that Schemes. In Advances in Cryptology, Proceedings of Go Faster than Lightning. ArXiv preprint arXiv:1702.05812 CRYPTO ’84, Santa Barbara, California, USA, August 19-22, (2017) 1984, Proceedings: pp. 47–53: doi:10.1007/3-540-39568-7\_5: [16] Dziembowski S., Eckey L., Faust S., Malinowski D.: Pe- URL https://doi.org/10.1007/3-540-39568-7_5 (1984) run: Virtual Payment Hubs over Cryptocurrencies. In 2019 [29] Paterson K. G., Schuldt J. C. N.: Efficient Identity-Based 2019 IEEE Symposium on Security and Privacy (SP): pp. Signatures Secure in the Standard Model. In Information 344–361: IEEE Computer Society, Los Alamitos, CA, USA: Security and Privacy, 11th Australasian Conference, ACISP ISSN 2375–1207: doi:10.1109/SP.2019.00020: URL https:// 2006, Melbourne, Australia, July 3-5, 2006, Proceedings: pp. doi.ieeecomputersociety.org/10.1109/SP.2019.00020 (2019) 207–222: doi:10.1007/11780656\_18: URL https://doi.org/ [17] Spilman J.: Anti dos for tx replacement. https: 10.1007/11780656_18 (2006) //lists.linuxfoundation.org/pipermail/bitcoin-dev/ [30] Malavolta G., Moreno-Sanchez P., Schneidewind C., Kate 2013-April/002433.html (2013) A., Maffei M.: Anonymous Multi-Hop Locks for Blockchain [18] Decker C., Wattenhofer R.: A Fast and Scalable Payment Scalability and Interoperability. In 26th Annual Network and Network with Bitcoin Duplex Micropayment Channels. In Distributed System Security Symposium, NDSS 2019, San A. Pelc, A.A. Schwarzmann (editors), Stabilization, Safety, Diego, California, USA, February 24-27, 2019 (2019) and Security of Distributed Systems - 17th International [31] Danezis G., Goldberg I.: Sphinx: A compact and provably Symposium, SSS 2015, Edmonton, AB, Canada, August 18- secure mix format. In Security and Privacy, 2009 30th IEEE 21, 2015, Proceedings: vol. 9212 of Lecture Notes in Com- Symposium on: pp. 269–282: IEEE (2009) puter Science: pp. 3–18: Springer: ISBN 978-3-319-21740-6: doi:10.1007/978-3-319-21741-3\_1: URL https://doi.org/10. [32] Katz J., Lindell Y.: Introduction to Modern Cryptography, 1007/978-3-319-21741-3_1 (2015) Second Edition. CRC Press: ISBN 9781466570269 (2014) [19] Lind J., Naor O., Eyal I., Kelbert F., Pietzuch P. R., Sirer [33] Bellare M., Sandhu R. S.: The Security of Practical Two-Party E. G.: Teechain: Reducing Storage Costs on the Blockchain RSA Signature Schemes. IACR Cryptology ePrint Archive: With Offline Payment Channels. In Proceedings of the 11th vol. 2001, p. 60: URL http://eprint.iacr.org/2001/060 (2001) ACM International Systems and Storage Conference, SYS- [34] Boyd C.: Digital Multisignatures. Cryptography and Coding: TOR 2018, HAIFA, Israel, June 04-07, 2018: p. 125: ACM: pp. 241–246: URL https://ci.nii.ac.jp/naid/10013157942/en/ doi:10.1145/3211890.3211904: URL https://doi.org/10.1145/ (1986) 3211890.3211904 (2018) [35] Ganesan R.: Yaksha: augmenting Kerberos with public key [20] Green M., Miers I.: Bolt: Anonymous Payment Channels cryptography. In 1995 Symposium on Network and Dis- for Decentralized Currencies. In Thuraisingham et al. [40]: tributed System Security, (S)NDSS ’95, San Diego, Cal- pp. 473–489: doi:10.1145/3133956.3134093: URL https://doi. ifornia, USA, February 16-17, 1995: pp. 132–143: doi: org/10.1145/3133956.3134093 (2017) 10.1109/NDSS.1995.390639: URL https://doi.org/10.1109/ [21] Heilman E., Alshenibr L., Baldimtsi F., Scafuro A., Goldberg NDSS.1995.390639 (1995) S.: TumbleBit: An Untrusted Bitcoin-Compatible Anony- [36] MacKenzie P. D., Reiter M. K.: Two-Party Generation of mous Payment Hub. In 24th Annual Network and Distributed DSA Signatures. In Advances in Cryptology - CRYPTO 2001, System Security Symposium, NDSS 2017, San Diego, Califor- 21st Annual International Cryptology Conference, Santa Bar- nia, USA, February 26 - March 1, 2017: The Internet Society: bara, California, USA, August 19-23, 2001, Proceedings: pp. URL https://www.ndss-symposium.org/ndss2017/ (2017) 137–154: doi:10.1007/3-540-44647-8\_8: URL https://doi. [22] Khalil R., Gervais A.: Revive: Rebalancing Off-Blockchain org/10.1007/3-540-44647-8_8 (2001) Payment Networks. In Thuraisingham et al. [40]: pp. 439– 453: doi:10.1145/3133956.3134033: URL https://doi.org/10. [37] Ganesan R., Yacobi Y.: A secure joint signature and key 1145/3133956.3134033 (2017) exchange system. Bellcore TM: vol. 24531 (1994) [23] Prihodko P., Zhigulin S., Sahno M., Ostrovskiy A.: Flare: An [38] McCarthy J.: Computer Programs for Checking Mathemat- Approach to Routing in Lightning Network: White Paper. ical Proofs. Proceedings of the Fifth Symposium in Pure https://bitfury.com/content/downloads/whitepaper_flare_ Mathematics of the American Mathematical Society: pp. 219– an_approach_to_routing_in_lightning_network_7_7_ 227: american Mathematical Society (1961) 2016.pdf (2016) [39] Canetti R., Stoughton A., Varia M.: EasyUC: Using Easy- [24] Sivaraman V., Venkatakrishnan S. B., Alizadeh M., Fanti G. Crypt to Mechanize Proofs of Universally Composable Secu- C., Viswanath P.: Routing Cryptocurrency with the Spider rity. In 32nd IEEE Computer Security Foundations Sympo- Network. CoRR: vol. abs/1809.05088: URL http://arxiv.org/ sium, CSF 2019, Hoboken, NJ, USA, June 25-28, 2019: pp. abs/1809.05088 (2018) 167–183: IEEE: ISBN 978-1-7281-1407-1: doi:10.1109/CSF. 2019.00019: URL https://doi.org/10.1109/CSF.2019.00019 [25] Kiayias A., Litos O. S. T.: A Composable Security Treatment (2019) of the Lightning Network. https://eprint.iacr.org/2019/778 (2019) [40] Thuraisingham B. M., Evans D., Malkin T., Xu D. (editors): Proceedings of the 2017 ACM SIGSAC Conference on Com- [26] Canetti R.: Universally Composable Security: A New puter and Communications Security, CCS 2017, Dallas, TX, Paradigm for Cryptographic Protocols. In 42nd Annual Sym- USA, October 30 - November 03, 2017: ACM: ISBN 978-1- posium on Foundations of Computer Science, FOCS 2001, 4503-4946-8: doi:10.1145/3133956: URL https://doi.org/10. 14-17 October 2001, Las Vegas, Nevada, USA: pp. 136–145: 1145/3133956 (2017) doi:10.1109/SFCS.2001.959888: URL https://eprint.iacr.org/ 2000/067.pdf (2001) [27] Canetti R., Dodis Y., Pass R., Walfish S.: Universally Com- posable Security with Global Setup. In Theory of Cryp- tography, 4th Theory of Cryptography Conference, TCC 2007, Amsterdam, The Netherlands, February 21-24, 2007, Proceedings: pp. 61–85: doi:10.1007/978-3-540-70936-7\_4: URL https://doi.org/10.1007/978-3-540-70936-7_4 (2007)

16