Log In Sign Up

CryptoMaze: Atomic Off-Chain Payments in Payment Channel Network

by   Subhra Mazumdar, et al.

Payment protocols developed to realize off-chain transactions in Payment channel network (PCN) assumes the underlying routing algorithm transfers the payment via a single path. However, a path may not have sufficient capacity to route a transaction. It is inevitable to split the payment across multiple paths. If we run independent instances of the protocol on each path, the execution may fail in some of the paths, leading to partial transfer of funds. A payer has to reattempt the entire process for the residual amount. We propose a secure and privacy-preserving payment protocol, CryptoMaze. Instead of independent paths, the funds are transferred from sender to receiver across several payment channels responsible for routing, in a breadth-first fashion. Payments are resolved faster at reduced setup cost, compared to existing state-of-the-art. Correlation among the partial payments in captured, guaranteeing atomicity. Further, two party ECDSA signature can be used for establishing scriptless locks among parties involved in the payment. It reduces space overhead by leveraging on core Bitcoin scripts. We provide a formal model in the Universal Composability framework and state the privacy goals achieved by CryptoMaze. We compare the performance of our protocol with the existing single path based payment protocol, Multi-hop HTLC, applied iteratively on one path at a time on several instances. It is observed that CryptoMaze requires less communication overhead and low execution time, demonstrating efficiency and scalability.


page 1

page 2

page 3

page 4


HushRelay: A Privacy-Preserving, Efficient, and Scalable Routing Algorithm for Off-Chain Payments

Payment channel networks (PCN) are used in cryptocurrencies to enhance t...

Security and Privacy of Lightning Network Payments with Uncertain Channel Balances

The Lightning Network (LN) is a prominent payment channel network aimed ...

Boomerang: Redundancy Improves Latency and Throughput in Payment Networks

In multi-path routing schemes for payment-channel networks, Alice transf...

Probing Channel Balances in the Lightning Network

As Lightning network payments are neither broadcasted nor publicly store...

Concurrency and Privacy with Payment-Channel Networks

Permissionless blockchains protocols such as Bitcoin are inherently limi...

RouTEE: A Secure Payment Network Routing Hub using Trusted Execution Environments

Cryptocurrencies such as Bitcoin and Ethereum have made payment transact...

Towards a Game-Theoretic Security Analysis of Off-Chain Protocols

Off-chain protocols constitute one of the most promising approaches to s...

1 Introduction

Cryptocurrencies, like Bitcoin [39], is gaining prominence as an alternative method of payment. Blockchain, a decentralized public ledger, forms the backbone of such currencies. It not only allows transacting parties to remain pseudonymous but also guarantees reliability and security. The records stored in this distributed ledger are immutable and can be verified by anyone in the network. It is replicated across users who use consensus algorithms like Proof-of-Work [39], [40], [9], Proof-of-Stake [28], [29]) for reaching an agreement. However, consensus algorithms have their own computation-overhead and quite resource-intensive. It slows down the performance and reduces scalability [13], [41]. Hence, scaling blockchain transactions has become a pressing concern, in order to compete with traditional methods of payment like Visa, PayPal [51] etc.

1.1 Background

In this section, we provide the required background on the payment channel network, routing and atomic multi-path payment. The terms source/payer means the sender node. Similarly, sink/payee/destination means the receiver node and transaction means payment transfer.

Payment Channel

Several Layer 2 solutions like [14], [15], [32] have been proposed for enhancing scalability of Blockchain. Amongst these, Payment Channel, like Lightning Network for Bitcoin [41] and Raiden Network for Ethereum [4], stood out as a widely deployed solution. Any two users, with mutual consent, can open a payment channel by locking their funds. These two parties can perform several off-chain payments between themselves, without recording it on blockchain. This is done by locally agreeing on the new deposit balance, enforced cryptographically by hash-based scripts [41], scriptless locking [35]. A party can close the payment channel, with or without the cooperation of counterparty, broadcasting the latest transaction on blockchain. Broadcasting of older transaction leads to loss of funds of the cheating party. Since opening and closing of payment channel is a costly operation, in terms of time and amount of funds locked, parties that are not connected directly leverage on the set of existing payment channels for transfer of funds. This set of payment channels form the Payment Channel Network or PCN [41].

Payment Channel Network

A Payment Channel Network (PCN) [34] is defined as a bidirected graph , where is the set of accounts dealing with cryptocurrency and is the set of payment channels opened between a pair of accounts. A PCN is defined with respect to a blockchain. Apart from the opening and closing of the payment channel, none of the transaction gets recorded on the blockchain. Upon closing the channel, cryptocurrency gets deposited into each user’s wallet according to the most recent balance in the payment channel. Every node charge a processing fee , for relaying funds across the network. Each payment channel has an associated capacity , denoting the amount locked by and denoting the amount locked by . signifies the residual amount of coins can transfer to . Suppose that a node , also denoted by , wants to transfer amount to node through a path , with each node charging a processing fee . If , then funds can be relayed across the channel . The capacity is updated as follows : and .

Routing Payment across a Single Path

The major challenge in designing any protocol for PCN is to ensure the privacy of the payer and payee and hiding the payment value transferred. No party, other than the payer and payee, should get any information about the transaction. Routing algorithm generally focused on finding a single path for routing a transaction and were centralized in nature. Canal [50] uses a centralized server for computing the path, Flare [42] requires intermediate nodes to inform the source node about their residual capacity. However, in order to preserve the transaction privacy, it was not in the best interest to have a single coordinator with all information control the routing algorithm.

Any routing or payment algorithm designed for such a network must be decentralized, where individual nodes take decisions based on the information received from its neighbor. Several payment algorithms like [38], [21], [37], [34], [35] deal with the transfer of payment between payer and payee across a single path. However, finding a single route for routing high-valued transaction becomes a challenging task, especially after several payments got executed in the network. Channels in a path may not have sufficient balance to relay the funds. It is better to split such high-valued transaction across several paths. This is analogous to the situation of breaking a high-valued transaction into several microtransactions.

Splitting Payment across Multiple Paths and Problem of Atomicity

As discussed, it is better to split the high-valued transaction and transmit it over different paths. It eliminates the constraint of finding out a single route from sender to receiver with sufficient channel capacity to support larger payment. Several distributed routing algorithms [43], [42], [33], [45], [50], [53], [26], [36] have been proposed for relaying transaction across multiple paths. But applying existing privacy-preserving payment protocols on each of the path concurrently doesn’t guarantee atomicity. Each instance of the protocol runs independent of the other. It is quite possible that an instance of the protocol might fail in a particular path due to resource constraint or malicious behavior of nodes [18], [44].

Figure 1: Failure of payment in path S->D->E->R

In the example shown in Fig. 1, payment from sender S to receiver R is split across three paths, S->D->E->R, S->B->C->R and S->F->G->R. On each path, Hashed Timelock Contract [41] is used concurrently for ensuring secure transfer of funds. For the two paths S->B->C->R and S->F->G->R, the payment hash used is and with R releasing the preimage x and y respectively. However for the path S->D->E->R, R does not have the preimage. It immediately reports error and cancels contract with E. E in turn asks D to cancel contract and finally S cancels contract with D, resulting in payment failure. But this results in partial of transfer, violating atomicity. This problem is encountered since each path is considered in isolation and the commitment used across each path are not correlated.

Atomic Multi-Path Payment

The goal of the receiver is to receive the full payment. In other words, the payment must be atomic - either all the microtransactions succeeds or it fails completely. If funds get transferred partially, sender has to make several attempts for the residual amount. Existing payment protocols like [2], [8] uses secret sharing [47] for achieving correlation in commitments used across multiple paths. Receiver is able to claim payment if and only if all the paths have confirmed locking of funds for transfer of payments. It reconstructs the secrets from the shares received and resolves the payment. This method guarantees atomicity but either at the cost of high latency or redundancy, involving high computation overhead. Failure of forwarding payment across some path stalls the entire transaction.

This leads to the question of whether is it possible to design an efficient, atomic payment protocol with low setup cost, ensuring secure transfer of funds from payer to payee across several paths (not necessarily edge-disjoint) in the network.

1.2 High Level Overview of CryptoMaze

Figure 2: Protocol fails in node C of

Considering all the above factors, we reached a conclusion that if we want to achieve atomicity as well as low latency, it is better to avoid sending payments via multiple paths. In a flow network, except the source and sink, the incoming flow is equal the outgoing flow. So if a node knows the total cumulative flow and does not receive enough incoming off-chain contracts accounting for it, then it will abort the protocol without proceeding further. In multiple path setting, only receiver has knowledge of the number of partial payments created. Consider the case as shown in Fig.2, with a off-chain contract established on path and path , concurrently. If the payment protocol encounters error at node C of path , then the contracts will be canceled in the channels AC and SA corresponding to . However, R will wait for certain time before triggering failure on path . Except R, none of the intermediate nodes knew about the correlation between off-chain contracts established in and .

Figure 3: Handling failure of payment in CryptoMaze

We propose a new privacy-preserving payment protocol, CryptoMaze, providing an instantiation of the same in Fig. 3. Each node involved in the payment has knowledge about its incoming contracts and outgoing contracts and information about the neighbours which will be sending the request for contract formation. This information helps in faster resolution of payments in the event of failure. Over here, D knows that it will receive incoming contracts from both B and C. Upon not receiving any response from node C, it would have triggered a failure, asking B to cancel all its incoming off-chain contracts. Meanwhile C would have triggered failure as well, canceling contracts on AC. A needs at least one signal from any of its outgoing neighbour for canceling all the incoming contracts. It receives one, either from B or C and cancels contract established with S. The benefit of forming contract on each channel in a breadth first fashion minimizes the number of contract established on shared edges, as paths need not be edge-disjoint.

1.3 Our Contributions

  • [leftmargin=*]

  • We have proposed a privacy-preserving payment protocol, CryptoMaze, for secure transfer of funds from payer to payee, guaranteeing atomicity, i.e. either the payment succeeds fully or fails entirely. It transfers funds across across several payment channels involved in routing in a breath-first fashion, instead of considering each path individually. This ensures faster resolution of payment.

  • Two party ECDSA signature [35] can be easily integrated into our framework for establishing scritpless locking. This reduces space overhead unlike other script-based payment protocols which depends on cryptographic primitives.

  • We have defined the privacy notions of CryptoMaze based on the Universal Composability framework and provided a detailed security analysis. The security of our proposed scheme depends on the discrete logarithm problem in random oracle.

  • We have implemented the proposed protocol on real instances - Ripple Network [34] and Lightning Network [46]. The code is given in [1]. CryptoMaze takes around 10s to complete the payment with a communication overhead of less than 1.5 MB compared to Multi-hop HTLC, which takes around 65s to complete the protocol and incurs a communication overhead of 26 MB. In an instance of Lightning Network, it takes around 485ms and communication overhead of 0.16 MB as compared to 10.6s and communication overhead of 24 MB by Multi-hop HTLC.

  • The proposed payment protocol is modular and functionally independent and hence works perfectly for any underlying routing algorithm.

1.4 Organization

Section 2 defines the problem statement, privacy goals and a formal definition of the security under Universal Composability Model is given in Section 2.2. The basic operations in ideal world is stated in Section 2.3. The details of our proposed protocol is stated in Section 3, with formal description of CryptoMaze in Section 3.4 and its privacy analysis in Section 3.5. Performance Analysis of CryptoMaze protocol is provided in Section 4. Section 5 discusses the state-of-the-art in PCN and Section 6 concludes the paper.

2 Problem Statement & Motivation

We formalize the notion of a PCN which allows faster atomic transfer of payment from sender to receiver. An ideal world functionality for the PCN has been provided, discussing the privacy goals.

Definition 1

A PCN is defined as a bidirected graph , where is the set of accounts dealing with cryptocurrency and is the set of payment channels opened between a pair of accounts. Each payment channel is defined by tuple , where is the channel identifier, denotes the initial deposit amount of in the channel, denotes the initial deposit amount of in the channel, denotes the current balance of in the channel, denotes the current balance of in the channel, where and is the channel timeout period. We consider a blockchain which will records the node’s bitcoin address, denoted by , and its on-chain balance, addressed by . The current timestamp of blockchain as . Basic operations of PCN consists three operations (openPaymentChannel,closePaymentChannel,payChannel) -

  • [leftmargin=*]

  • openPaymentChannel : For a given pair of accounts , with initial balances and , , and a channel timeout period as , and mutually cooperate to open a channel denoted by , where is the channel identifier, provided both and has authorized to do so. If it succeeds, the blockchain is updated as follows: and and it returns 1. Upon failure, it returns 0.

  • closePaymentChannel : Given a channel identifier for channel , retrieve . If timeout period has expired, i.e. then update as follows : and , remove the entry from and return 0. Else, update blockchain as follows: and , remove the entry from and return 1.

  • payChannel : Given a set of payment channels responsible for relaying of funds from payer to payee . is denoted by set of channel identifiers . Retrieve for each channel. wants to transfer to , provided has authorized the same. If , then update the channel as and return 1. Else none of the balances of the payment channels in is modified and payChannel returns 0.

2.1 Privacy Goals of the Protocol

  • [leftmargin=*]

  • Value Privacy - It guarantees that neither the participants involved in routing the payment nor any corrupted user outside the payment path will have any knowledge about the transaction amount being send from sender to receiver.

  • Relationship Anonymity - Given two simultaneous successful pay operations and via same set of intermediaries where and , with each intermediate channel forwarding the same amount of flow for both the cases. If at least one intermediate party is honest and rest all are corrupted, then none of the corrupted intermediate parties can distinguish between payment and

    with probability more than 1/2.

  • Consistency - The protocol is consistent if none of the nodes can claim funds from the predecessor contract without obtaining the solution from the successor time-locked contracts. Non-adjacent parties, upon collusion, cannot unlock their contracts by bypassing honest intermediaries.

  • Atomicity - A payment is said to be atomic if the receiver can claim the payment upon receiving all the partial payment flow. The payment channels involved in routing aggregate their individual secrets and provide it to the receiver. Upon receiving this value, the receiver can withdraw funds from the network. If any of the party misbehaves and does not lock fund then the transaction fails.

2.2 Ideal World Functionality

For modeling security and privacy definition of payment across several payment channels under concurrent execution of an instance of CryptoMaze, we take the help of Universal Composability framework, first proposed by Canetti et al. [12]. Our modeling of ideal functionality is similar to [34] in terms of notation and assumption, opening and closing of channel. However the difference lies in the procedure of payment. We do not consider linear path based payment. Instead we check the condition on each channel whether the incoming off-chain contracts are consistent to form the outgoing off-chain contracts.

2.2.1 Attacker Model

Using the model suggested in [34]

, the nodes of the network are modeled as interactive Turing machines, denoted by

, denotes the initiator of protocol and denotes the receiver, which communicates with an ideal functionality via secure and authenticated channels. We model the attacker as a PPT machine that is allowed to corrupt a subset of nodes in the network. Upon corruption, it gets access to its internal state and controls any transmission of information to and from the corrupted node. As of now, only static corruption is allowed, i.e. adversary must specify the nodes it wants to corrupt before the start of the protocol.

2.2.2 Communication Model

For encoding anonymous communication between two parties in the ideal world, we define it in the following way - Using anonymous message transmission functionality , sends packet , containing the secret message to . is leaked to [12], [11], without revealing the content of the message and the identity of the sender.

An attacker can delay the delivery of messages arbitrarily. The network model is assumed to be synchronous [12], [16], where any message sent out at round, gets delivered to the intended recipient at round. Computation in this model is assumed to be instantaneous. However, since we deal with the asynchronous network in the real world, a maximum time bound for message transmission is set. If no message is delivered by the pre-decided expiration time, then the message is considered as .

2.2.3 Assumptions

We define an ideal functionality for the PCN. Dummy parties in the set communicate with each other via . If a user in the network wishes to communicate anonymously with user , it will use . Consider an underlying blockchain which acts like a trusted append-only ledger recording opening and closing of payment channels. An ideal functionality maintains locally. is updated as per the transaction between parties. Any user can send a read instruction to , where the whole transcript of is sent as a reply. The number of entries of is denoted by . An arbitrary condition can be specified in the contract in order to execute a transactions in . is entrusted to enforce that a contract is fulfilled before the corresponding transaction is executed. Time is modeled as the number of entries of the blockchain . By adding dummy entries to , time can be elapsed artificially. Users figure out the current time by counting the entries of . uses and as subroutines.


Any payment channel existing in is denoted by , where is the channel identifier of the payment channel existing between dummy parties and , is the capacity of the channel, is the expiration time of the channel and is the fee charged by the node . maintains two lists internally - one for keeping track of the list of closed channels, denoted by and one for keeping track of the list of off-chain payments, denoted by [34]. Upon executing an off-chain payment in the channel , is entered into where is the payment forwarded to node by and is the expiration time of the payment, is the event identifier. When a channel is closed on-chain, the channel identifier is entered into list . For routing payment from to , payment channels involved in doing so is put in set , added serially upon breadth first traversal of the network, starting from . The flow in each channel present in is denoted by .

2.3 Basic Operations of Payment Channel Network in Ideal World

initialized pair of local empty lists . Users in set can query for opening and closing of channel, provided they are valid operations in sync with the state in . We describe the basic operations in PCN in the ideal world - open channel, close channel and payChannel.

  • [leftmargin=*]

  • OPEN CHANNEL : Considering a user wants to open a channel with . invokes by sending the message , where is the channel capacity, is the expiration time of the channel and is the associated fee charged on using the channel. If there is no other entry in and no other inconsistencies are found, sends to . Upon authorization by both parties, adds to and to where is the event identifier. The event identifier is returned to and .

  • CLOSE CHANNEL : For a channel between and , if either of the party wants to close the channel, it invokes with the message ). checks for an entry in of the form and checks the list for an entry , given that is a valid event identifier. If or , , then aborts. Else is added to and gets added to . Both and is notified with the message .

  • PAY: Given the tuple as input from , executes the following protocol:

    • [leftmargin=*]

    • For a given node , , samples a random and checks for an entry , , samples a random and checks for an entry . If all these entries exists, then it forms , conveys to via anonymous communication channel. As special case, it sends to . checks whether for a given payment channel having entries of the form , the following conditions hold true: and . If it holds true, then adds to , being the last updated capacity of the payment channel . If any of the conditions fails, removes all such entries from entered in this session and aborts.

    • For all , queries with , through an anonymous channel. If a node returns to then update to in . , remove from .


The ideal functionality captures the privacy properties of PCN:

  • [leftmargin=*]

  • Value Privacy: Since the payment value is split across multiple channels, we claim that intermediate nodes as well as any adversary (without any access to ) lying outside the payment path cannot figure out the total amount of the transaction.

  • Relationship Anonymity: If there exist at least one honest intermediate node, then it receives unique event identifier from for each payment over any of its outgoing payment channel. Since all the event identifiers are independently generated, any corrupted node neither draw correlation nor figure out which of the payment or got forwarded firs with probability greater then 1/2.

  • Consistency: As per the second step of payment, if a node returns failure while processing payment, none of the incoming payment channels can process their payment.

  • Atomicity: maintains all the contract list for each user and keeps track of their status in . In the first step of payment, if at any node there is not enough capacity or discrepancy in expiration time of event, then a failure is returned to . In case all conditions gets satisfied, only then does the second step gets executed, with being able to claim payment.

Definition 2

UC Definition of Security. An environment present in both the ideal and real world invokes the steps of execution of an instance by providing the input and receiving the output. If cannot distinguish between in the real world and the ideal world functionality, then it is said to be UC-secure. Formally stated,

Theorem 2.1

Given that is the security parameter, a protocol denoted by , UC-realizes an ideal functionality if for all computationally bounded adversary attacking there exist a probabilistic polynomial-time simulator such that for all probabilistic polynomial time environment such that and are computationally indistinguishable.

3 Our Proposed Construction

3.1 Network Model and its Assumptions

The topology of the network is known by any node in the network since any opening or closing of a channel is recorded on the blockchain. The payer chooses a set of paths to the receiver according to her own criteria. The current value on each payment channel is not published but instead kept locally by the users sharing a payment channel. Every user is aware of the payment fees charged by each other user in the PCN. Pairs of users sharing a payment channel communicate through secure and authenticated channels.

3.2 Cryptographic Building Blocks

Consider an elliptic curve group with generator , with and be the security parameter.

Discrete Logarithm Problem

Given the elliptic curve over a finite field , where and is prime, the elliptic curve discrete logarithm problem (ECDLP) is the following computational problem: Given points , find an integer such that , if exists. This computational problem is called the Elliptic Curve Discrete Logarithm Problem which forms the the fundamental building block for elliptic curve cryptography [19].

Two Party ECDSA Signature

An efficient two party ECDSA protocol stated by Lindell [31]. Given a collision resistant hash function . A private and public key pair is generated by sampling a random value and corresponding public key . The signature algorithm over a message proceeds as follows - Sample a random value , construct and . Take , which is the x co-ordinate of . Compute and . The signature is the tuple . Note that also forms a valid signature.

Given (m,r,s) and public key , the verification algorithm proceeds as follows - Compute and calculate . Let x co-ordinate of S’ be . If then return 1 else return 0.

3.3 Subroutines used in CryptoMaze

We define the subroutines KeyGen, Setup, TimeLockContractCreate and TimeLockContractRelease, which will be used in the payment phase of our protocol.

3.3.1 KeyGen Phase

Each node independently samples a pair of public key and private key , where and is a point on the elliptic curve. The public key is a long term key and it is used repeatedly across different instance of the protocol, until and unless the secret key gets compromised.

3.3.2 Setup Phase

Given a flow across a network for relaying funds from payer to payee, we map it into set of payment channels, denoted by , ordered as per breadth-first traversal. Starting from receiver node, the channels are ordered as per the algorithm stated in Procedure 1.

Consider the network, as shown in Fig.4. Starting from , it has one incoming payment channel with positive flow. This channel is inserted into the set . R is inserted into the queue . This continues till the last node in is the sender S. The set constructed is .

1 Input:
2 Output:
3 Initialize set and a queue .
4 Insert the receiver node into .
5 while  is not empty do
6       . Mark as visited.
7       Find out the incoming neighbours of which has a positive flow in order to route the payment.
8       Insert these payment channel, with as the counterparty, into the set and delete it from the set .
9       Insert all unvisited incoming neighbours of into .
10 end while
Procedure 1 Mapping set of paths into set of payment channels
Figure 4: CryptoMaze : Setup

3.3.3 Preprocessing Phase

Consider a function as random oracle. samples independent strings . Since receiver node is the one with no outgoing flow, funds of payment channel denoted by , with receiver node as one of the counterparty is locked for the least time. Let this be . For timelocked contracts established with any other pair of nodes , check the value for some positive value of . Assign as the lock time for the contract on payment channel . For each channel , denoted by with flow value , a commitment for locking funds is constructed in the following way -


where is the public key of . is constructed as


If then and , where is defined in Eqn. 4. For each node , we construct


where is defined in Eqn. 4. For all the outgoing neighbours of , will be constructed as shown in Eq. 2. For all the incoming neighbours of , will be constructed as shown in Eq. 1. The packets constructed for vertex is . Receiver vertex receives the following information - Sender nodes uses an anonymous secure communication channel to transfer the packets to each of the members .

3.3.4 TimeLockContractCreate Phase

Figure 5: CryptoMaze : TimeLockContractCreate Phase

Any node , except , waits for incoming contract to be formed for a minimal amount of threshold time ( of the order of milliseconds). Any contract formed between and any of its incoming neighbour, say , is of the form . It also obtains a value where


Given the information for vertex , it constructs the value where


and checks the following -


For all outgoing neighbours of , it constructs as defined in Eq. 4. For all incoming neighbours of ,


If all the equations hold true, then sends value to as well as forms the contract . For forming an off-chain contract in a channel , we leverage on ECDSA based scriptless locking, as defined in [35]. It is compatible with Bitcoin and incurs less space overhead required for other cryptographic operations like hash based scripts [41].

3.3.5 TimeLockContractRelease Phase

The release phase starts from the receiver node where it checks whether it can construct the discrete log of


This shows that the key required by to claim the money is indirectly dependent on the participation of all the channels present in the route . If any of the node deviates from the protocol then the payment will fail. It then proceeds to release the condition for all the incoming contracts in order to claim the money.

We provide a generic procedure of the release phase followed by a node for its incoming contract formed with node . It constructs


The value is revealed to node . Since we use ECDSA based scriptless locking, node will provide the required information for completing the ECDSA signature, which can be verified by .

3.4 Formal Description of the Protocol

The operation openPaymentChannel and closePaymentChannel has already been defined as follows:

openPaymentChannel : This operation results in opening of channel between user and . Given the initial bitcoin addresses of and , each party, upon authorization, deposits and in the channel denoted by channel identifier . The channel timeout period is . After the operation of bitcoin deposit gets successfully added to the blockchain, it is reported as success by returning 1. Upon failure, 0 is returned,

closePaymentChannel : This operations allows two users and mutually agree to close a channel between them denoted by channel identifier . Get the balance of each and in the channel denoted by and . Update the bitcoin balance as per this information and reflect the same in the Bitcoin blockchain. Return 1 if the operation is successful else return 0.

KeyGen Upon receiving from and from : [leftmargin=*] Sample a secret key Compute a public key Output the message to and Store Lock Upon receiving from both and : [leftmargin=*] If is already stored, abort. Check if for the given has been stored. Sample and compute Query the Random Oracle at point , which returns . Compute Send a output to and Store Verify Upon receiving from both and : [leftmargin=*] If is not stored then abort. Parse and retrieve Query the Random Oracle at point , which returns . Compute and Check , if true return to

Figure 6: Interface of ideal world functionality

We first define the interfaces of ideal functionality in Fig. 6, which has access to a Random Oracle. The interfaces are KeyGen, Lock and Verify. KeyGen generates a common public key for a payment channel between parties and . The Lock Phase is same as generating ECDSA signature but with a difference that instead of , we use the value sampled by sender for establishing locks in each channel. The construction is same as defined in [35]. The Verify phase ensures that the correct key is released for completing the signature and a valid party gets to claim the money, as stated in the timelock contract.

payChannel: Given a network flow for routing the transaction from to using the payment channels in , obtained after execution of Setup Phase. The details of payChannel for sender, receiver and intermediate nodes, considering our protocol has access to ideal functionalities and .

In Procedure 2, sender first calculates the cost of routing the transaction through the channels in , including the fee charged by each intermediate hop, denoted by value . It checks whether it has enough funds remaining in its channel to route the payment, given that is the flow from to each of its outgoing neighbour . If not, it will abort the payment. Else it constructs the contract information for each intermediate node, as shown in Preprocessing Phase. The information is propagated to each user via anonymous channel. Next, it establishes contract with each of its outgoing neighbour, assigning a legitimate timeout period within which the counterparty has to resolve the payment.

The intermediate parties get the terms of the contract from the intermediate node along with a decision, as shown in Procedure 3. If the decision is forward, then it will check the consistency of incoming contracts with the terms stated for outgoing contract. Upon validation, it calls the subroutine TimeLockContractCreate and accesses to establish a partial ECDSA signature on the contract. Only a counterparty with valid information can complete the signature and claim payment upon verification. If the decision is OK, then it calls TimeLockContractRelease module, constructs the key to be propagated to the incoming contracts for completing the signature. The party receiving the key checks whether the signature is complete by querying . Upon verification, the success message is propagated to the predecessor. If any of the phase fails or no decision is sent out, then abort is triggered. Abort restores the channel balance to its previous valid state and requests all parties to cancel the contract.

The receiver gets the secret share from all the nodes and constructs , as shown in Procedure 4. Even if one payment channel fails in establishing contract, receiver will not be able to claim payment. This guarantees the property of atomicity. Receiver triggers the release phase and sends the information along with the decision OK to all its incoming neighbours.

1 Input:
3 if   then
4       for  do
6       end for
7      , is the maximum level traversed during bfs on the set of paths .
8       for  do
9             Call Preprocessing Phase on node
10             Get
11             Send to via .
13       end for
14      Get to
15       Send to via .
16       for  do
17             Generate a random message
18             sends the message to , receives a public key
19             query on
20             if