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 ProofofWork [39], [40], [9], ProofofStake [28], [29]) for reaching an agreement. However, consensus algorithms have their own computationoverhead and quite resourceintensive. 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 multipath 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 offchain payments between themselves, without recording it on blockchain. This is done by locally agreeing on the new deposit balance, enforced cryptographically by hashbased 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 highvalued 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 highvalued transaction across several paths. This is analogous to the situation of breaking a highvalued transaction into several microtransactions.
Splitting Payment across Multiple Paths and Problem of Atomicity
As discussed, it is better to split the highvalued 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 privacypreserving 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].
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 MultiPath 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 edgedisjoint) in the network.
1.2 High Level Overview of CryptoMaze
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 offchain 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 offchain 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 offchain contracts established in and .
We propose a new privacypreserving 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 offchain 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 edgedisjoint.
1.3 Our Contributions

[leftmargin=*]

We have proposed a privacypreserving 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 breathfirst 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 scriptbased 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 Multihop 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 Multihop 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 stateoftheart 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 onchain 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 timelocked contracts. Nonadjacent 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 offchain contracts are consistent to form the outgoing offchain 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 predecided 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 appendonly 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.
Notations
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 offchain payments, denoted by [34]. Upon executing an offchain 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 onchain, 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 .

Discussion
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 UCsecure. Formally stated,
Theorem 2.1
Given that is the security parameter, a protocol denoted by , UCrealizes an ideal functionality if for all computationally bounded adversary attacking there exist a probabilistic polynomialtime 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 coordinate 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 coordinate 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 breadthfirst 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 .
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 
(1) 
where is the public key of . is constructed as
(2) 
If then and , where is defined in Eqn. 4. For each node , we construct
(3) 
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
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
(4) 
Given the information for vertex , it constructs the value where
(5) 
and checks the following 
(6) 
For all outgoing neighbours of , it constructs as defined in Eq. 4. For all incoming neighbours of ,
(7) 
If all the equations hold true, then sends value to as well as forms the contract . For forming an offchain 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
(8) 
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
(9) 
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.
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.