DeepAI
Log In Sign Up

Griefing-Penalty: Countermeasure for Griefing Attack in Bitcoin-compatible PCNs

05/19/2020
by   Prabal Banerjee, et al.
CSIRO
0

Payment Channel Networks or PCNs have gained prominence ensuring faster relaying of transactions. However, this Layer-two solution has its own fair share of problems. Topological analysis on Lightning Network reveals that Griefing Attack is a major problem whereby an adversary intentionally exhausts the channel capacity of the network. It can be used for mounting series of targeted attacks like Denial-of-Service Attack, Node Isolation Attack and Channel Exhaustion Attack on honest participants as well. Though the attack does not always result in a direct monetary gain of the attacker, blocking of channel capacity for several days prevented several nodes from processing any future transaction request, leading to substantial collateral damage. Certain portions of the payment channel network get stalled which hampers the throughput and utility of the network. Mitigating Griefing Attack still remains an open problem. In this paper, we propose an efficient countermeasure for the attack, known as Griefing-Penalty. Mounting such an attack requires the attacker to pay a penalty proportional to the collateral cost of executing a payment. The penalty is used for compensating parties who incurred loss by locking funds. Our proposed strategy works for any timelock based payment protocol and ensures faster resolution of payments. To illustrate it, we propose a new payment protocol HTLC-GP or Hashed Timelock Contract with Griefing-Penalty. It not only preserves privacy but also ensures that an attacker cannot ascribe blame on any honest intermediary present in the path relaying a payment.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

03/20/2022

Strategic Analysis to defend against Griefing Attack in Lightning Network

Payments routed in Lightning Network are susceptible to a griefing attac...
06/15/2020

Flood Loot: A Systemic Attack On The Lightning Network

The Lightning Network promises to alleviate Bitcoin's known scalability ...
04/23/2019

Discharged Payment Channels: Quantifying the Lightning Network's Resilience to Topology-Based Attacks

The Lightning Network is the most widely used payment channel network (P...
06/02/2020

Time-Dilation Attacks on the Lightning Network

Lightning Network (LN) is a widely-used network of payment channels enab...
02/16/2020

Congestion Attacks in Payment Channel Networks

Payment channel networks provide a fast and scalable solution to relay f...
09/15/2019

Hijacking Routes in Payment Channel Networks: A Predictability Tradeoff

Off-chain transaction networks can mitigate the scalability issues of to...
06/25/2022

Cascading Failures in Smart Grids under Random, Targeted and Adaptive Attacks

We study cascading failures in smart grids, where an attacker selectivel...

1 Abstract

Payment Channel Networks or PCNs have gained prominence ensuring faster relaying of transactions. However, this Layer-two solution has its own fair share of problems. Topological analysis on Lightning Network reveals that Griefing Attack is a major problem whereby an adversary intentionally exhausts the channel capacity of the network. It can be used for mounting series of targeted attacks like Denial-of-Service Attack, Node Isolation Attack and Channel Exhaustion Attack on honest participants as well. Though the attack does not always result in a direct monetary gain of the attacker, blocking of channel capacity for several days prevented several nodes from processing any future transaction request, leading to substantial collateral damage. Certain portions of the payment channel network get stalled which hampers the throughput and utility of the network. Mitigating Griefing Attack still remains an open problem.

In this paper, we propose an efficient countermeasure for the attack, known as Griefing-Penalty. Mounting such an attack requires the attacker to pay a penalty proportional to the collateral cost of executing a payment. The penalty is used for compensating parties who incurred loss by locking funds. Our proposed strategy works for any timelock based payment protocol and ensures faster resolution of payments. To illustrate it, we propose a new payment protocol HTLC-GP or Hashed Timelock Contract with Griefing-Penalty. It not only preserves privacy but also ensures that an attacker cannot ascribe blame on any honest intermediary present in the path relaying a payment.

2 Introduction

Since the inception of Bitcoin [1] in 2009, blockchain technology has seen widespread adoption in the payment space. Many blockchain-based payment solutions have been defined but Bitcoin and Ethereum [2] remain the top two platforms in terms of market capitalization with a combined cap of 185 Billion USD [3]. Despite many desired features like decentralization and pseudonymity, a constant criticism faced by Bitcoin and Ethereum is that of scalability.

Several works have proposed protocol level changes in Layer-one to increase scalability like sharding [4], [5], alternate consensus architecture [6], [7], [8], [9], [10], [11], side-chains [12]. These changes are hard to implement as they need consensus from the community, revamping the trust assumptions of the base layer and changing the codebase. Recent works have tried to come up with solutions in Layer-two [13]. It massively cuts down data processing on the blockchain by running computations off-chain. The amount of data storage on Layer-one is minimized. Taking transactions off the base layer, while still anchored to it, would free up processing resources to do other things. Also Layer-two relies on Layer-one for security.

Though several solutions like [14], [15], [4] have been proposed, Payment Channel [15] stood out as a practically deployable answer to the scalability issue. It is modular in nature, without requiring any fundamental changes in the protocol layer. Any two parties with some deposit made in the Blockchain network can mutually open a payment channel by locking their funds for a certain time-period. The funds locked in the channel enable several off-chain payments to be carried out between these two parties, by locally agreeing on the new deposit balance. Except for opening and closing of the payment channel, none of the transaction gets recorded on-chain. In case of dispute, any party can unilaterally broadcast the latest valid transaction in the blockchain and terminate the channel. A malicious party will lose all the fund locked in the channel if he or she tries to broadcast any older transaction. Since opening a payment channel has its overhead 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 [16]. It is modeled as a bidirectional weighted graph where nodes are entities who can issue payments to other participants in the network by using channels, also the termed as the edges of the PCN.

Griefing Attack. Given a PCN, consider a payment has to be made via payment channels, where . Let us index each channel by where . The channel connected directly to the payer is indexed 1 and channel ending with payee is indexed . For executing the payment, an amount is locked in each of the payment channel for a period of , which is also termed as locktime. is the worst-case confirmation time when the transaction is settled on-chain. Once the amount gets locked, it cannot be utilized before the elapse of the locktime. If an adversary controlling channel , where , refuses to resolve the contract off-chain and raises a dispute, then the time taken to resolve it will be . It manages to lock coins in the payment channels preceding it just by locking coins in channel . If the adversary is controlling the receiver then without incurring any cost for mounting the attack, it locks for a time period of . If an adversary manages to capture any node present in the middle of the path, then the attack results in worst-case collateral damage. The amount of fund locked is approximately for a time period of , thus total loss incurred is .

Figure 1: Griefing Attack: when node R ignores HTLC request
Figure 2: Funds locked in the path for 1 day
Example 1

A wants to transfer fund to a node R. It leverages on the existing payment channels AB, BC, CD and DR for relaying funds from A to R, as shown in Fig.1. A locks fund with B for a period of 4 days, B locks its fund with C for a period of 3 days, C locks funds with D for a period of 2 days and ultimately D locks fund with R for 1 day. R ignores the request and refrains from releasing the payment condition, as shown in Fig.2. The payment fails with D rolling back to its previous state after one day. D terminates its off-chain contract with C, C cancels its contract with B, B and A following suit as well. Hence R manages to lock 1 unit coin in each payment channel for one entire day. None of the channel can utilize the amount before the locktime of channel DR elapses.

Figure 3: Sybil nodes carry out payment

Motivation of Griefing Attack. An adversary, controlling both the sender and receiver, submits a high-valued payment request in the network with the intention of locking liquidity of intermediate channels. Neither the sender nor the receiver gains economically but it successfully reduces the network throughput. It may setup several sybil nodes at strategic positions and amplify the damage by submitting several payment requests. A substantial part of the network gets blocked for a considerable amount of time. In absence of the attack, any affected participants of the network could have earned sufficient remuneration by accepting several transaction requests within that duration.

An adversary may try to eliminate its competitor in the business of forwarding payments. It strategically mounts channel exhaustion attack upon its competitor by carrying out self-payment of value equivalent to the liquidity of its outgoing payment channels. The adversary sets the victim as an intermediate node in the path carrying out the self-payment. The victim cannot utilize the fund till the adversary decide to claim the payment. As a consequence, several future payment request which could have been routed through the victim node now gets routed through the adversary. It reaps indirect economic benefit by claiming the processing fee for routing such transactions.

Any rational intermediate node might not be motivated to carry out griefing attack as it would lose out on earning fee from processing the transaction, as stated in [17]. However, if the attacker is able to capture some hub nodes then definitely it will try to route large number of transactions through it in order to maximize the damage.

In this paper, we consider these three main motivations for mounting a Griefing Attack:

  • Stalling network using self payment or by using sybil nodes: The adversary controls the sender and receiver of several payment requests, blocking multiple intermediaries from accepting any other payments to be routed through it [18], [17], as shown in Fig. 3.

    Figure 4: Eliminating a competitor
  • Eliminating a competitor from the network: The adversary tries to eliminate a competitor and block all its existing channel’s outgoing capacity [19], [17]. It carries out self payment of value equivalent to the victim’s outgoing channel capacity, jamming all the channels of the victim node. In Fig. 4, Node B has outgoing channel with A and C, each of capacity 0.1 BTC. Node D has channel with A and C, each of capacity 0.2 BTC. It conducts self-payment of 0.05 BTC, in each direction. Upon griefing for 24 hrs, D denies B from accepting any transaction request. A and C, having residual outgoing capacity of 0.1 BTC each in channel AD and CD, is now forced to route all the payments via D.

    Figure 5: DoS attack by a hub node
  • Stalling network using intermediary: The adversary controls a node with high degree centrality and broadcasts its processing fee to be extremely low in order to ensure multiple payments get routed through the such nodes [20]. It later ignores all the payment by not forwarding the message to outgoing neighbours, locking funds across multiple paths thereby affecting a large portion of the network. Fig. 5 demonstrates a DoS attack by hub node. It charges a very low processing fee compared to other hub node (here it is E). It ignores all payment request and stalls the network.

2.1 Overview of Griefing-Penalty

Griefing Attack in Bitcoin-compatible PCNs cannot be prevented as long as malicious node has nothing to lose or in other words, it has nothing at stake. This problem can be answered if we penalize the attacker, also termed as griefer, for ignoring the incoming off-chain contract request. This penalty is termed as Griefing-Penalty 222In payment channel, penalty refers to claiming of the entire fund locked in the channel by an affected party if its counterparty misbehaves by broadcasting an older transaction. Hence to distinguish the two concepts, we use the term Griefing-Penalty where a party has to incur loss for capturing channel fund.. Not only does it have to pay compensation for locking the fund of its channel’s counterparty but it has to compensate other parties which got affected by the attack.

The griefing-penalty imposed on an adversary for mounting griefing attack on a path of length is proportional to the summation of collateral cost of each payment channel involved in routing. Collateral cost per payment channel is defined as the product of the amount locked in the off-chain contract and the expiration time of the contract. The reason behind considering the expiration time of the contract for accounting of griefing-penalty is to punish griefer for denying service to other participants in the path. The money remaining locked in the channels could have been utilised by the intermediaries for earning processing fee by processing several other payment requests. Thus, we force any party accepting incoming off-chain contract request to invest a substantial amount of liquidity. This will definitely disincentivize an adversary from mounting the attack due to the cost involved.

Figure 6: Formation of contract under Griefing-Penalty

Let us demonstrate it through an example, shown in Fig.6. Alice wants to transfer p units to Bob via payment channels (Alice-Dave, Dave-Charlie, Charlie-Bob). Alice forms an off-chain contract with Dave locking units for a time period of days. Given that the rate of griefing-penalty is units per day, being a fraction, Dave is expected to lock units of fund as griefing-penalty with the off-chain contract. Dave has to transfer units to Charlie, it forms a similar off-chain contract for a time period of days. The griefing-penalty for the channel (Dave-Charlie) is . However, upon griefing, Charlie is expected to pay compensation to both Dave and Alice. Hence it has to pay a cumulative griefing-penalty . The total money locked in the off-chain contract between Dave and Charlie is . Charlie transfers units to Bob by forming an off-chain contract for locktime of days, with both parties locking units of funds. units is the cumulative penalty to be distributed among Alice, Dave and Charlie, if Bob refuses to resolve the payment before expiration of locktime. Suppose Bob griefs and refuses to resolve the payment, waiting for days to elapse. He will have to transfer units of funds to Charlie, as per the terms of the contract. Charlie unlocks units of funds after the contract expires and withdraws units from the compensation it receives. He forwards to Dave. Dave withdraws and forwards the rest of the amount to Alice. Note that except Bob, none of the parties lose funds in order to compensate any of the affected parties.

2.1.1 Reverse-Griefing

As a consequence of griefing-penalty, a malicious party can now ascribe the blame of griefing on an honest party as well. Consider a timelocked contract exist between party and , where will forward payment to provided it satisfies the terms of the contract within a given time-period. Failure to provide a witness for resolving the payment within the given timeout period results in paying a pre-determined penalty to . If is honest and due to some unforeseen circumstances, it cannot satisfy the terms of the contract then it will immediately request to terminate the contract by mutual agreement. However, takes advantage of the situation and ignores the request for termination. It knows that has no way to resolve the contract on-chain as it lacks the witness. After the locktime elapses, broadcasts its transaction claiming the full griefing-penalty from . Though B was not involved in griefing, still it ends up losing a considerable amount of fund.

Figure 7: D and F are malicious, D reverse-griefs, E is victimized

2.1.2 A different strategy for mounting Griefing-attack

Leveraging on reverse-griefing, an adversary can mount griefing-attack without paying any penalty. It may simply refuse to sign an incoming off-chain contract or maliciously terminate the contract by sending an error message. If there exist a node in the path, in close proximity to the adversary, which is either greedy or finds that money earned by reverse-griefing is higher than the profit it will make by processing future transaction requests, then there is a high probability that this node will act as a griefer. Even better, if the adversary manages to corrupt another node in the path then the attack will definitely get mounted. We illustrate the strategy via Fig.

7. Node preceding and the node succeeding in the path are controlled by the same adversary. Let us denote it as and respectively. refuses to sign the off-chain contract request by . E requests to cancel the contract and form a new commitment transaction. refuses to terminate the contract and waits till the locktime of the contract elapses. becomes a victim of reverse-griefing and ends up paying a cumulative penalty for nodes and . on the other hand, manages to lock funds in the path from to for the next 2 days. Hence, we see in this situation, not only did the adversary manage to lock funds in the path but earned a profit by ascribing the blame on an honest node.

To avoid such situation, we make certain assumptions in our System Model and Adversarial Model, as stated in Section 4.2 and Section 4.3. Based on it, we argue that reverse-griefing is not a good strategy for earning money, hence any rational player would choose to follow the protocol instead of keeping its funds locked.

2.2 Our Contributions

  • We propose a countermeasure for mitigating griefing attack in Bitcoin-compatible PCNs, known as Griefing-Penalty. It punishes the griefer by forcing it to pay compensation to all the parties whose funds got locked for a certain time-period as a result of the attack.

  • The loss of funds incurred upon mounting griefing-attack is proportional to the collateral cost of each channel involved in routing the payment.

  • To illustrate the benefit of the proposed countermeasure, we propose a new payment protocol, called as HTLC-GP or Hashed Timelock Contract with Griefing-Penalty.

  • We provide a security analysis which proves that our protocol is privacy preserving as well as mitigates loss due to griefing attack by compensating the honest nodes.

Notation Description
Payment Channel Network, represents the set of payment channels
Payer/Sender,
Payee/Receiver,
Amount to be transferred from S to R
Path connecting S to R
Length of the path
Nodes in
Amount of funds locked by in the payment channel
Net balance of that can be transferred to via off-chain transaction
Processing fee charged by for forwarding the payment
Security Parameter
A standard one-way function
Worst-case confirmation time when a transaction is settled on-chain
Rate of griefing penalty (per minute)
Table 1: Notations used in the paper

3 Background

3.1 Payment Channel Network

A Payment Channel Network (PCN) [21] 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. Correctness of payment across each channel is enforced cryptographically by hash-based scripts [16], scriptless locking [22]. 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 residual capacity is updated as follows : and .

3.2 Hashed Time-lock Contract

Hashed Time-lock Contract (HTLC) [16], [21] is a payment protocol which allows secure transfers of funds from payer to payee , using a network of channels across an -hop route . The payee creates a condition defined by where is a random string and is a random oracle [23]. The condition is shared with . It now shares the condition with for construction of the HTLC. Between any pair of adjacent nodes , the hashed time-lock contract is defined by - implies that this contract locks units of fund of party that can be released to party only if it releases the correct preimage for which within timeout . If doesn’t release within time , then settles the dispute on-chain by broadcasting the transaction which rolls back amount to its wallet. If wants to terminate its HTLC off-chain with then the HTLC is invalidated by creating a new commitment transaction with the updated balance of and . This HTLC is then set at each payment channel present on the path to the receiver.

The payment gets resolved quickly if all the participants collaborate. However, if receiver or any other intermediate node ignores the incoming contract request and wait for the expiration of the off-chain contract, the funds remain locked in the path. Note that after the timeout period, all the parties withdraw the fund locked in the contract. The griefer doesn’t lose any money in the process.

4 Problem Statement & System Overview

4.1 Problem Definition

Problem 1

Given a payment channel network defined by , where is the nodes with deposit in the Bitcoin network and defines the payment channels. A payment of amount has to be made from payer to payee via the path via payment channels . Each intermediate node charge a processing fee, denoted as . Assuming that the path has enough capacity for routing the payment, each party establish an off-chain contract with and locks , , in the contract for a time-period of . If intentionally withholds the solution without resolving the incoming off-chain contract, then waits for the timelock to expire, after which funds can be withdrawn from the contract. Note that rest of the parties waits for the same time-period, keeping their funds locked in their respective off-chain contract. This is known as Griefing Attack. The attack stalls a part of the network for a considerable time period, where an adversary temporarily claim channel capacity. Our objective is to design a strategy whereby the griefer incurs substantial loss for ignoring request for resolving the off-chain timelocked contracts.

4.2 System Model

The topology of the payment channel network is known by any node in the network since opening or closing of a payment channel is recorded on the blockchain. Pairs of honest users, sharing a payment channel, communicate through secure and authenticated channels. An honest party willing to send funds to another party, will adhere to the protocol. It will not tamper with the terms and conditions of off-chain contract meant for each of the intermediate payment channels, involved in relaying the payment. The model of communication is considered to be synchronous, with all the parties following a global clock for settling payments off-chain.

We assume that for a given node, individual griefing-penalty earned upon elapse of locktime of the off-chain contract is less than the expected revenue earned by processing several transaction request within the given locktime. We assume that all the nodes in the network are rational, whose intention is to maximize the earning by remaining active in the network. Hence any such rational player would prefer to utilize their funds rather than earn penalty by reverse-griefing and keep their funds locked in a channel.

4.3 Adversarial Model & Assumptions

An adversary introduces multiple sybil nodes and places them strategically (targeting the hub nodes) in the network in order to maximize the collateral damage. Such sybil nodes may be involved in self payment or transfer funds from one sybil node to the other for mounting griefing attack. For ease of analysis, we assume that at most one node present in the path relaying a payment request is controlled by the adversary. Our assumption is based on the observation made in [18], [20]. In order to reduce the cost of the attack, the optimal choice is corrupting one node per payment or an adversary executing a self-payment.

An adversary can perform the following arbitrary actions in order to keep funds locked in the network for substantial amount of time:

  • Withholding the solution and not resolving the incoming off-chain payment request.

  • Refrain from forwarding the off-chain payment request to the next neighbour.

  • Reverse-grief by ignoring request for termination of contract.

  • Refuse to sign any incoming contract request.

  • Terminate the contract citing lack of witness or error in parameters.

An adversary would perform such actions provided it is able to achieve at least one of the motivation, stated in Section 2. If none of the objective is satisfied, then it would prefer to follow the protocol and utilize the funds in order to avoid payment of griefing-penalty. The idea behind such an assumption is by mounting a Griefing Attack the adversary gains a tacit revenue. Unless it is able to successfully mount the attack, it would rather be rational and earn like honest nodes than have its fund locked up in a failed attempt.

We have discussed in details the consequences of griefing attack by multiple parties in a single path in Section 6.3.

4.4 System Goals

  • Guaranteed compensation for an honest node: All the parties affected by the griefing attack will be remunerated by the griefer. Except the griefer, no one must lose fund in order to pay compensation to any of the affected parties.

  • Privacy: None of the intermediate nodes involved in routing a payment must be able to identify its exact position in the path as well as figure out the identity of sender and receiver of payment.

5 Generic Solution for countering Griefing Attack

Designing fair protocols on Bitcoin, where the adversary was forced to pay a mutually predefined monetary penalty to compensate the loss of honest parties, was first introduced in Bentov et al. [24]. They used a claim-or-refund functionality where the sender deposits money which is later transferred to the receiver contingent on whether the receiver acts honestly or not. In the two party case, the functionality allows a sender to send coins to receiver if provides a witness that satisfies some mutually agreed precondition within a predefined time period. To achieve the same, both parties deposit some coins at the start of the protocol. Then R releases the witness which the functionality checks for correctness. If correct, the receiver claims its due share of coins along with its deposit. Otherwise, the sender gets a penalty to compensate for its loss which is funded by the receiver’s deposit.

In our multiparty model, intends to transfer payment of amount to via multiple intermediaries . A party forms an off-chain contract with using a pre-defined commitment. Both the parties lock money in the contract, with depositing the amount that has to be transferred to contingent to the knowledge of decommitment within a certain time-period . The latter, on the other hand, locks a certain amount as penalty. It can be claimed by after elapse of , if doesn’t respond. The terms of the off-chain contract is replicated across all payment channels involved in routing the payment from to . If a node defers from rendering service, it will pay a price for its irrational behavior. The amount charged as penalty by a node is directly proportional to the loss it incurs in terms of collateral cost, i.e. . Inspired from this idea, we propose a countermeasure for griefing attack, Griefing-Penalty, to solve the problem of griefing in Bitcoin-compatible PCN, as defined in Section 4.1. We consider a generic two-party off-chain timelocked contract and illustrate the effectiveness of the proposed strategy in countering griefing attack.

5.1 Two-party Off-Chain Timelocked Contract with Griefing-Penalty

Consider a timelocked contract established between two parties. The terms of the contract are enforceable via blockchain. If a party X wants to transfer amount to party Y and rate of penalty is per minute, then party X will establish an off-chain contract with Y, with a contract resolution time of days. X will lock amount and party Y will lock with the off-chain contract.

For example, consider two parties Alice and Bob with a payment channel in between them, each having locked a fund of 5 msat. Suppose Alice wants to transfer 1 msat to Bob, it establishes the contract with as the commitment and a locktime of 3 days. Both the parties have to agree to the following terms of the contract, with rate of penalty being 0.001 per minute:

  • Alice expects a prompt reply from Bob. If Bob does not respond within 3 days, he will bear a penalty of 0.001*24*60*3*1= 4.32 msat. Hence Alice locks 1 msat and Bob has to lock 4.32 msat with the contract. Hence total amount locked in contract is 5.32 msat.

  • If Bob can produce to Alice an unknown random input data within 3 days, then Alice will settle the contract with Bob unlocking 5.32 msat.

  • If 3 days have elapsed and Bob has not been able to produce , then he loses 5.32 msat to Alice. Alice gets back 5.32 msat.

  • Either party may (and should) pay out according to the terms of this contract in any method of the participants choosing and close out this contract early so long as both participants in this contract agree.

  • Any violation of the above terms incurs a maximum griefing-penalty equal to the funds locked up in this contract.

6 Hashed Timelock Contract with Griefing-Penalty (HTLC-GP)

We propose a new payment protocol for Bitcoin-compatible PCNs by incorporating Griefing-Penalty into HTLC [16]. The function as defined as collision-resistant Hash function . Consider the previous instance of a channel between Alice and Bob, where Alice has established an HTLC-GP with Bob for transferring 1 msat. Rate of griefing-penalty being 0.001 per minute. The terms of the contract is as follows: Given in the contract, Bob can claim fund of 1 msat from Alice contingent to the knowledge of , within a time-period of 3 days. If Bob fails to do so, then after a timeout of 3 days, it pays a penalty of 4.32 msat to Alice.

Construction of two-party off-chain Revocable HTLC-GP

Figure 8: Revocable HTLC-GP

The establishment of two-party HTLC-GP between Alice and Bob has been illustrated in Fig. 8, the structure being similar to construction of Off-Chain Revocable HTLC [16]. Both parties have locked funds of 5 msat each, which gets included as the Funding Transaction. Alice intends to transfer 1 msat to Bob, using the same conditions as explained in Section 5.1. Bob locks 4.32 msat and Alice locks 1 msat into HTLC-GP. Bob can withdraw the entire amount contingent to the knowledge of preimage corresponding to the payment hash. If Bob fails to respond, upon expiration of locktime Alice claims the entire amount. Thus both the parties mutually agree to form second commitment transaction (CT1a/CT1b). Output 2 of CT1a describes how funds get locked in HTLC-GP. 5.32 msat will be encumbered in an HTLC-GP. If a party wants to unilaterally close the channel then it broadcasts latest Commitment Transaction. The parties are remunerated as per terms of the contract. If CT1a is broadcasted and Bob has produced R within 3 days, it can immediately claim the fund of 5.32 msat by broadcasting HTLC-GP Execution Delivery 1a. Revocable Sequence Maturity Contract (RSMC) embedding [16] used in the output HTLC-GP Timeout Delivery 1a ensures that if Alice broadcasts this transaction, it has to wait for 1000 block confirmation time before it can spend 5.32 msat. This extra waiting time serves as a buffer time for resolving dispute. If Alice had made a false claim of CT1a being the latest state of the channel, Bob will raise a dispute and spend Alice’s channel deposit.

The same state of channel is replicated in CT1b. However, the difference lies in how each party can spend their respective output with respect to the copy of the transaction they have. If CT1b is broadcasted and Bob has not been able to produce R within a period of 3 days, then it can claim fund of 5.32 msat after 3 days by broadcasting HTLC-GP Timeout delivery 1b. If Bob has the preimage R, it can immediately broadcast HTLC-GP Execution Delivery 1b. However this output is encumbered by 1000 block confirmation time, the explanation being the same as we had stated for HTLC-GP Timeout Delivery 1a. These changes can be easily integrated into the Bitcoin script.

6.1 Our Proposed Construction

For secure transfers of funds from to , the former selects an optimal route for transferring funds to the payee, as per its routing strategy. Let the path be via which payer will relay fund of value to payee . Each party charge a service fee of for relaying the fund. Hence the total amount that needs to transfer is . We denote each , and . Each node samples pair of secret key and public key .

Possibility of Reverse-Griefing in HTLC-GP and its Countermeasure. In Bitcoin Lightning Network [16], onion routing is used for propagating the terms of HTLC. An HMAC provided with the data allowed the forwarding node to check integrity of data. Since we introduce griefing-penalty, a malicious forwarding node might try to cheat by changing the terms of the off-chain contract it extends to an honest party. The honest party, upon finding discrepancy, reports failure to the malicious party. If the malicious party refrains from canceling the contract, the honest party becomes a victim of reverse-griefing and ends up paying the full compensation. To prevent an honest node from losing funds, it will do a one step look-ahead whereby terms of the outgoing contracts will be checked before committing to the terms of incoming off-chain contract. In case of any discrepancy, it denies accepting the incoming contract and sends a failure message.

Parameters used

  • Rate of Griefing-penalty: The griefing-penalty rate per minute decides the amount to be deducted as compensation from the balance of a node responsible for griefing. Usually, lies between 0 and 1. It is set as a global parameter.

  • Routing Attempt Cost : has to figure out the path by probing channels which will be able to route the transaction. This may require several attempts and hence adds an extra computational as well as resource overhead on . In the event of griefing, adds the cost of routing attempt to the compensation withdrawn from griefer. Additionally, introduction of the routing attempt fee to the cumulative penalty preserves sender privacy, as discussed in Theorem 2. This is a variable quantity and the quantity is kept hidden from other nodes but generally a sender sets the value and preferably .

shares with , where is a function used for blinding the exact value of , adding the extra cost for routing to the compensation it must claim from . Since is the source, the maximum penalty it must claim from is . But seeing the griefing-penalty value, can infer that the incoming off-chain contract has been sent out by the source of the payment. Even other nodes can figure out their position in the path with the information of cumulative griefin-penalty. Hence adds the routing attempt cost along with the flow it sends to . The latter cannot infer whether is routing attempt fee or the cumulative flow from any predecessors of .

The maximum compensation, which can be earned by is , where is the amount to be transferred to , if contract is resolved successfully within . If is at fault, then it has to pay compensation to all the parties which got affected starting from till . Hence compensation charged by each channel , must be withdrawn from the faulty node . The total griefing-penalty to be paid is , so that each party gets a compensation of and withdraws a compensation of .

Our protocol involves three phases - Pre-processing Phase, Locking Phase and Release Phase. We discuss each phase in details:

  • Pre-processing Phase: uses onion routing for propagating the information needed by each node to construct off-chain contract with , across the path . It sends to , where , as defined in Procedure 2. decrypts , gets and the next destination (over here ) to which the packet must be forwarded. Hence in the Locking Phase, each node receives the packet from , checks the correctness of incoming and outgoing contract’s terms and condition, locks funds with , to be claimed contingent to some condition within a time-period of .

    Figure 9: HTLC-GP lock phase
  • Locking Phase: If gets a valid request from , it will initiate the locking phase. Each node sends the terms and condition of off-chain contract to . As illustrated in Fig 9, the off-chain contract is defined as follows: will be paid to provided it reveals within a period of else unlocks from the contract and pays as griefing-penalty.’

    If there is discrepancy in the terms of the outgoing contract, to be formed with , and the terms of the incoming contract request forwarded , then does not accept the incoming off-chain contract. The receiver checks the following before accepting the contract from : the amount it has to lock in the contract is approximately , the amount locked by is and the expiration time of the contract differs at least by . If any of the condition is violated, it refrains from accepting the incoming contract request.

    For any channel , if HTLC-GP gets established, the amount locked for a period of is , where comes from deposit and comes from deposit. We state the details of Locking Phase in Procedure 1, Procedure 2 and Procedure 3 for sender, other intermediate nodes and receiver respectively.

    1 Input:
    2 calculate
    3 if  and  then
    4      
    5       for  do
    6            
    7            
    8            
    9            
    10       end for
    11      Form the packet for onion routing , where denotes standard encryption with public key .
    12       Send
    13       if acknowledgement received from  then
    14            
    15            
    16             Form with
    17             Record
    18            
    19       end if
    20      else
    21             abort
    22       end if
    23      
    24 end if
    25else
    26       abort.
    27 end if
    Procedure 1 Locking Phase for
    1 Input:
    2 receives encrypted message from , decrypts and receives and .
    3 if  and and and and  then
    4       Sends acknowledgement to
    5       Send to
    6       if acknowledgement received from  then
    7            
    8            
    9             establish with
    10             Record
    11            
    12       end if
    13      else
    14             abort
    15       end if
    16      
    17 end if
    18else
    19      
    20       abort.
    21 end if
    Procedure 2 Locking_Phase (for )
    1 Input:
    2 receives encrypted message from , decrypts and receives and .
    3 if  and and  then
    4       Sends acknowledgement to
    5      
    6 end if
    7else
    8       abort.
    9 end if
    Procedure 3 Locking_Phase for
  • Release Phase: It is triggered by which upon receiving off-chain contract from , releases the preimage to and resolves the contract off-chain, as shown in Procedure 4. In case of dispute, it goes on-chain for settling the contract. This is repeated for other parties , which upon obtaining the preimage claims payment from the counterparty.

    If griefs and refuses to release preimage to , it has to pay the a griefing-penalty for affecting the nodes , so that all the nodes obtain their due compensation. Note that we make an assumption here that either the contracts are settled instantly or any of the node must have griefed and caused delay in settlement.

    With the locktime of off-chain contract between set to and considering a synchronous model of communication, is set as the threshold time for demanding griefing-penalty from the counterparty while settling the contract off-chain, as shown in Procedure 5. In other words, if any rational intermediate node finds that its counterparty comes with a request of off-chain termination of HTLC-GP after elapse of unit of time, it serves as proof that some party down the line had griefed and hence the delay. It will claim the full compensation from the counterparty while terminating the contract off-chain.

    1 Input:
    2 if   then
    3       if  then
    4             if  releases to  then
    5                   if  and mutually agree to terminate HTLC_GP then
    6                        
    7                        
    8                   end if
    9                  else
    10                         goes on-chain for settlement by claiming .
    11                   end if
    12                  
    13             end if
    14            
    15       end if
    16      else
    17             goes on-chain for settlement, claims .
    18       end if
    19      Call Release_Phase()
    20      
    21 end if
    22else
    23      
    24 end if
    Procedure 4 Release_Phase for
    Input : error message,
    1 if  then
    2       if  and mutually agree to terminate HTLC_GP then
    3             if  then
    4                  
    5                  
    6             end if
    7            else
    8                  
    9                  
    10             end if
    11            
    12            
    13       end if
    14      else
    15             /*After elapse of */
    16             goes on-chain for settlement, claims .
    17       end if
    18      
    19 end if
    Procedure 5 cancel
    1 Input:
    2
    3
    Procedure 6 terminate

6.2 Security Analysis

Correctness of payment based on the commitment used for each off-chain contract is dependent on the underlying one-way function being used. Over here, we consider the commitment used is a hash value where payment can be claimed contingent to the knowledge of preimage. So the security of HTLC-GP boils down to the fact: Hash functions are easy to compute but hard to invert. In Theorem 1, we provide a proof of correctness to show that except griefer, none of the honest intermediate party loses funds to pay a compensation to any other affected party. In Theorem 2, we proof that our proposed payment protocol preserves privacy.

Theorem 1

Given a payment request to be transferred via path , if a party griefs then it is required to pay a penalty which is used for compensating all the affected parties. Apart from the griefer, none of the honest parties lose funds in the process.

Proof Sketch: We consider the three possible cases:

  • Rest of the parties being honest, receiver griefs: In the Pre-processing Phase, the sender being honest, there is no deviation from the protocol.

    In the Locking Phase, the receiver is the last node in the path and hence there is no scope of griefing by refusing to forward HTLC-GP to its next neighbour. It can deny accepting an incoming HTLC-GP from node , thereby forcing to cancel HTLC-GP with and so on. As to are honest, all parties will prefer canceling the HTLC-GP and free up their funds than hold on to the HTLC-GP to earn the griefing penalty.

    In the Release Phase, the receiver can grief by either refusing to terminate the contract or withholding the witness from . It will lock funds in the path for a period of . As a consequence, it pays a cumulative penalty of , where is the griefing-penalty charged by channel for keeping funds locked until time and is the griefing-penalty charged by channel . Except , every node in the path earn the maximum compensation.

  • Sender and receiver is honest, any intermediate party griefs: For the Pre-processing Phase, the argument is similar to the previous case.

    In the Locking Phase, can grief by not forwarding the HTLC-GP to . If it doesn’t cancel the contract with , it ends up paying a cumulative penalty of .

    In the Release Phase, can grief in the following ways:

    • It refuses to terminate the contract or withholds the witness from : Pays the same penalty, as it would have incurred during a griefing attack in the Locking Phase.

    • If doesn’t respond to the request off-chain termination of contract, then will claim its reward by revealing the preimage on-chain and closing the channel . Hence reverse-griefing is not possible in this case.

  • Rest of the parties being honest, sender griefs: While executing the Pre-processing Phase, if the sender sends malformed packets through the path, there can be two possibilities:

    • Any intermediate parties figure out discrepancy in the terms of the contract.

    • Receiver detects error in the parameters (insufficient locktime, wrong amount being transferred, incorrect payment hash) and doesn’t release the preimage.

    In either of the case, this would result in sending an error message to the preceding contracts and request for its off-chain termination. All parties being honest immediately cancel their contracts with . may reverse-grief and force to pay penalty. But as stated, mounting this attack does not fulfil any of the objectives of griefing attack. Even it had been the case that is the victim which it was trying to sabotage, it manages to block just a fraction of funds deposited by in the channel . It is not able to exhaust its channel or isolate . Hence it would rather prefer to free up funds than keep it locked in the channel.

Corollary 1

If the adversary initiates a self payment and mounts a Griefing Attack, none of its objectives are fulfilled.

Proof Sketch: As mentioned in Section 2, an adversary can conduct a self payment so that it can either lock funds in a path for a substantial amount of time or eliminate a competitor in the network by preventing it from processing any payment request. We argue that our design thwarts off such an attack. We consider the two main motivations of such a self payment:

  • Stalling network: If the adversary wants to stall a network, the strategy would be to create longer paths between the sender and receiver so as to have maximum network coverage.

    If the adversary corrupts the Pre-processing and Locking Phase, only the channel between and contains unresolved contract for the timelocked period. This does not allow the adversary to stall a large portion of the network because only one edge per path gets affected. Hence, a rational adversary would choose to free up those funds and utilize them elsewhere than get stuck in the unsuccessful Griefing Attack.

    If the adversary corrupts the Release Phase, as shown in Theorem 1, the adversary needs to pay the penalty for all the intermediaries in the path, making the attack uneconomic.

  • Eliminating a competitor: To eliminate a competitor, the adversary has to block all outgoing funds available to the victim node in its existing channels. The only economic attack where the adversary will not lose fund for paying penalty is non acceptance of HTLC-GP in Locking Phase. Rest of the nodes will cancel their off-chain contract formed with the counterparty. However, can reverse-grief by not responding to ’s request. But as argued in Theorem 1, it has no effect on the victim’s existing channel’s outgoing capacities, rendering the attack useless to the adversary.

    If the adversary withholds the witness in Release Phase then the objective of eliminating the competitor is accomplished. It earns the extra processing fee by forcing future payment requests to be routed through itself. However, this profit is earned at the cost of paying a griefing-penalty, which is a multiple of the capacity of victim’s outgoing payment channels. Definitely the profit margin reduces. If the penalty rate is set accordingly, the system ensures that the penalty incurred exceed the profit earned and the purpose of the attack stands defeated.

Theorem 2

Given the information of griefing-penalty in the off-chain contract, an intermediate node cannot infer its exact position in the path for routing payment.

Proof Sketch: For routing payment of amount from to via intermediaries , several instances of off-chain contract is established across the payment channels. The amount locked by party and in their off-chain contract is and , respectively. Let us assume that there exists an algorithm which reveals the exact position of any intermediate node in the path. This implies that given the information of cumulative griefing-penalty mentioned in the contract, it can distinguish between the penalty charged by channel and penalty charged by channel , which is . However, was added by node as an extra compensation charged to cover up for routing attempt expense as well as hiding its identity from its next neighbour. This is information is private and not known by any node except . Additionally, the value of is set such that . Any number being selected from being equiprobable, the probability of distinguishing becomes negligible.

Note: In practical application, there is a limit on the routing attempt fee which a sender can charge. The set from which is selected is significantly smaller compared to . But even under such circumstances, the best inference made by any intermediate node about its location is that it is located at position where acts as the blinding factor.

6.3 Discussions

Certain problems which has not been addressed by our proposed strategy:

  • Other forms of griefing attack: We do not consider the case where a counterparty resolves the contract just before the expiration of locktime. Imposing a penalty based on the amount of elapsed time has been has been discussed in [25] as hold fee. However, in an asynchronous system it is difficult to record the amount of elapsed time, since time interval may have different meaning to different nodes in the network. For example, a malicious party manipulates the clock so that time elapse slowly compared to other parties. Alternately, in a synchronous system even though all nodes depend on a global clock, there is no way to judge who speaks the truth and who is lying. It might be the case the party who has to pay a penalty tampers the information of elapsed time and pays a lower penalty. No one can raise a dispute as Bitcoin script currently lacks the capability of enabling execution of transaction for each time interval elapsed. The closest match is the CheckSequenceVerify opcode. However this enables broadcast of a transaction after a certain block height has been reached. But there is no way to execute transaction like this: If t’ time units have elapsed, pay amount . If t’+1 time units have elapsed, pay amount . CheckSequenceVerify imposed on the first condition of elapse of t’ time unit makes it eligible for broadcasting event after elapse of time t’+1. Hence imposing penalty for milder form of griefing has not been considered.

  • Possibility of earning money by reverse-griefing: Here we consider that any malicious party has the motive to grief to either eliminate a competitor or stall the network. As a side effect of the proposed penalty mechanism, it is now possible for parties to reverse-grief and victimize its counterparty. This problem is bound to occur when both the party has locked fund in the contract, to be claimed by the other party upon deviation from the protocol. Both the parties have a way of earning money, either acting honestly or dishonestly. We glance through the possibilities by which a node can make money illegitimately:

    • An adversarial sender tampers with the terms of the contract (sending less amount to receiver, setting wrong timelock [26], etc.). Assuming rest of the parties to be honest, contracts will be canceled, when termination is triggered by receiver. But the party which has accepted contract from the adversary will suffer because now the latter stops responding. Off-chain termination of contract is possible if and only if two parties mutually agree. In the event of non cooperation, the honest party is forced to pay penalty as per terms of the contract. Plus there is no way to ascribe blame on the party who has reverse-griefed.

    • If apart from sender and receiver, some other nodes in the path are corrupted as well, then it is the best situation. Sender tampers with the terms of the contract. Receiver terminates the contract off-chain. Some intermediate node reverse-grief by not responding to the request of off-chain termination of contract. All the nodes preceding it suffer as a result of locking of funds for substantial amount of time. The objective of stalling the network is accomplished but at the cost of ascribing the blame on an honest node. So this leads to a situation where even griefing attack results in monetary gain.

      • An observation: Previously, the optimal choice was to select just one node which griefs and locks funds in the entire path. With the introduction of griefing-penalty, in order to avoid paying a compensation, at least two nodes in the path must be corrupted, as per the argument made above.

    • It is not easy to judge the course of action of any intermediate party carrying out the payment. With a two options of making money, either follow protocol and earn a processing fee or get a compensation for being griefed. Though we assume honest party will act rationally, in reality a party is selfish and its strategy will be to formulate a dynamic course of action which will result in maximum monetary gain, as per the situation. If a party finds that its channel may not be utilized much in future and it won’t be earning a good amount of processing fee, it will certainly wait for the situation where the counterparty comes with a request of canceling the contract off-chain due to some discrepancy in the terms of the contract. It can then reverse-grief and make a good amount of profit.

  • Compensation withdrawn for off-chain termination of contract: As described in the protocol, after elapse of time units, rest of the party withdraws the maximum compensation i.e. an amount which it should receive had it been griefed for the entire locktime stated in the contract. We avoid paying compensation based on the amount of time elapsed. Consider the situation where A wants to pay money to E, via path AB, BC, CD and DE. Suppose AB has a locktime of 4 days, BC has a locktime of 3 days, CD has a locktime of 2 days and DE has a locktime of 1 day. If we consider a time-elapsed based penalty, then E will pay a cumulative penalty incurred for locking funds of all the channel for 1 day, D will pay a cumulative penalty incurred for locking funds in channel CD, BC and AB for 2 days, C pays a cumulative penalty incurred for 3 days to party B and A, and B pays a penalty for locking funds for 4 days. If E griefs, it pays a compensation to A, B, C and D at the rate of keeping funds locked for 1 day. Now D asks C to terminate the contract off-chain, paying a compensation for 1 day. C might start reverse-griefing, forcing D to pay compensation for keeping funds locked for 2 days. D will lose out fund as it has to pay compensation for one extra day loss. Hence to prevent an honest party from being victimized, we implement the following strategy: The first party to launch a griefing attack in a path has to pay the maximum compensation for rest of the nodes preceding it.

  • High Collateral at stake - A party accepting any incoming off-chain contract has to lock a substantial amount as penalty. This can lead to a decrease in throughput because of the increase in liquidity being tied up for each payment. However, the problem can be countered by adjusting the value of . We infer that a staggered locktime across the path involved in transferring the payment adds to the problem of collateral cost as well. As a countermeasure, we would like to propose a constant locktime payment protocol so that any griefer can affect at most one party by refusing to accept any payment request. Rest of the parties can resolve the payment and won’t be affected by an adversary who had griefed somewhere down the line.

7 Related Works

Impact of Griefing Attack

Griefing Attack in HTLCs was first mentioned in [27]. As countermeasure, it was proposed to split big amounts into smaller packetized payments. However, the problem of griefing was correlated to the trust in the counterparties. In off-chain payment, the word trust must be taken with a pinch of salt since there is no way to predict behavior of participants. Later, it was shown in [20], how griefing attack along with channel exhaustion can be potentially applied for eliminating specific edges and paths in the payment channel network. It was possible to isolate a node by blocking the outgoing channel by conducting self payment of value equivalent to the channel capacity. Hijacking of routes by malicious nodes who abruptly drop their processing fee in order to attract several payments to be routed through it has been discussed in [28]. Intermediary node intentionally goes offline and sender waits for the HTLC to expire before making another attempt for payment. If such a node has high centrality measure then it can potentially launch Denial-of-Service attack by stalling large number of transactions. Repeated route selection via such malicious nodes will never allow payments to succeed. Paralyzing the network for multiple days by overloading each channel with maximum unresolved HTLCs has been studied in [29], [28]. The impact of the attack is quite disastrous as none of the channel can accept new requests. Also, an adversary can form a payment channel with a hub node and render it useless by blocking its channel capacity. Both the work shows that cost of the attack is quite low compared to the impact and can be optimized as well. Similarly, [30] shows how adversary can perform a balance lockdown in Lightning Network by conducting self payment in the network. A follow up on this line of work, recently Bank run attacks on Bitcoin’s Lightning Network was emperically analyzed in [18]. Here the adversary generates a number of sybil nodes, establishes channels with existing nodes in the PCN. It then initiates several multi-hop payments between such sybil nodes and griefs them simultaneously. It was observed just by targeting 1.5% of the highly connected nodes in the network, approximately 83% of the network capacity can be locked for several days.

Certain Countermeasures

Several ideas have been stated to prevent an honest node from becoming a victim of griefing attack. A limit on the number of incoming channel as well as the channel capacity was proposed in [20] as countermeasure for node isolation attack. However, the attacker may split the funds over multiple identities and channels to bypass the restrictions imposed. Some game theoretic approach for analyzing the strategies of attacker and defender was proposed in [28]. Faster resolution of HTLC has been stated in [29] as another method to avoid the disadvantage of having staggered locktime across payment channel. However, such a feature would violate the purpose of having HTLC timeout which acts as safety net against other possible malicious activities. All these payment protocol had a staggered locktime over each channel responsible for routing the payment. The collateral cost incurred for staggered locktime protocols is substantial. Sprites [31], an ethereum styled payment network, first proposed the idea of using constant locktime for resolving payment. However, privacy was violated as the path information, identity of sender and receiver was known by all participants involved in routing the payment. Similar concept of reducing collateral cost using constant locktime contracts was proposed for Bitcoin-compatible payment networks in [19]. However, it violated relationship anonymity and the proposed protocol is yet to be realized practically.

Alternate mitigation strategies by incentivizing or punishing nodes have been stated in the past. Use of up-front payment was first proposed in [32]. In up-front payment, a party has to pay fee to the other party for accepting the HTLC. An excess fee paid is returned back to the sender upon successful resolution of payment. This introduces a lot of economic barrier where up-front payment may exceed the transaction fee. For small valued payment, a large up-front payment is a serious problem. Also, any intermediate party may cheat and stop forwarding the HTLC to the next party. In the event of failure, a sender incurs a loss as the malicious party will never refund the money. Later, in [33], [25], the concept of reverse-bond was proposed which is similar to our proposed strategy. The counterparty accepting the HTLC will have to pay a hold- fee on a per unit interval basis, as if it has rented the HTLC. However, it has not been stated formally how this can be realized plus there is no way to track per unit interval in a decentralized asynchronous setup. In [17], a proposal of Proof-of-Closure of channels was proposed, where by each HTLC will have a hard timeout and a soft timeout period. If in a channel, a counterparty crosses the limit of soft timeout in resolving the HTLC, then the party which had forwarded the HTLC will drop the channel on-chain. Simultaneously, it will send a report of closure of channel upstream. The node preceding it will not close its channel upon elapse of soft timeout after receiving the report. It checks the validity of the report and notifies its predecessor in turn. It was stated that closure of channel is the loss incurred by the node trying to grief. However, a malicious node can setup several sybil nodes just for this purpose so that channel closure doesn’t affect its normal activity in the network.

8 Conclusion & Future Work

In this paper, we have proposed a strategy for mitigating griefing attack in Bitcoin-compatible PCNs by imposing penalty on the adversary. This increases the total cost for launching such an attack as well as compensates other nodes in the network affected by griefing. We have shown how our proposed strategy works in a timelocked payments by proposing a new protocol HTLC-GP. It can be easily incorporated into the existing HTLC framework of Lightning Network [16]. As our next step, we intend to provide a proof-of-concept implementation of HTLC-GP as well as do some empirical analysis on the Lightning Network thereby justifying the effectiveness of the proposed strategy.

References

  • [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Cryptography Mailing list at https://metzdowd.com, 03 2009.
  • [2] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” Ethereum project yellow paper, vol. 151, pp. 1–32, 2014.
  • [3] “Cryptocurrency market capitalizations.” https://coinmarketcap.com/. Accessed: 2020-05-05.
  • [4] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, “A secure sharding protocol for open blockchains,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 17–30, ACM, 2016.
  • [5] A. E. Gencer, R. van Renesse, and E. G. Sirer, “Service-oriented sharding with aspen,” arXiv preprint arXiv:1611.06816, 2016.
  • [6] A. Kiayias, A. Russell, B. David, and R. Oliynykov, “Ouroboros: A provably secure proof-of-stake blockchain protocol,” in Annual International Cryptology Conference, pp. 357–388, Springer, 2017.
  • [7] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz, “Permacoin: Repurposing bitcoin work for data preservation,” in 2014 IEEE Symposium on Security and Privacy, pp. 475–490, IEEE, 2014.
  • [8] V. Buterin and V. Griffith, “Casper the friendly finality gadget,” arXiv preprint arXiv:1710.09437, 2017.
  • [9] S. Park, A. Kwon, G. Fuchsbauer, P. Gaži, J. Alwen, and K. Pietrzak, “Spacemint: A cryptocurrency based on proofs of space,” in International Conference on Financial Cryptography and Data Security, pp. 480–499, Springer, 2018.
  • [10] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, “Bitcoin-ng: A scalable blockchain protocol,” in 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), pp. 45–59, 2016.
  • [11] R. Pass and E. Shi, “Hybrid consensus: Efficient consensus in the permissionless model,” in 31st International Symposium on Distributed Computing (DISC 2017), Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2017.
  • [12] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling blockchain innovations with pegged sidechains,” URL: http://www. opensciencereview. com/papers/123/enablingblockchain-innovations-with-pegged-sidechains, vol. 72, 2014.
  • [13] L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais, “Sok: Off the chain transactions,” IACR Cryptology ePrint Archive, vol. 2019, p. 360, 2019.
  • [14] C. Decker, R. Russell, and O. Osuntokun, “eltoo: A simple layer2 protocol for bitcoin,” White paper: https://blockstream. com/eltoo. pdf, 2018.
  • [15] C. Decker and R. Wattenhofer, “A fast and scalable payment network with bitcoin duplex micropayment channels,” in Symposium on Self-Stabilizing Systems, pp. 3–18, Springer, 2015.
  • [16] J. Poon and T. Dryja, “The bitcoin lightning network: Scalable off-chain instant payments,” 2016.
  • [17] “Proof-of-closure as griefing attack mitigation.” https://lists.linuxfoundation.org/pipermail/ lightning-dev/2020-April/002608.html, April 2020.
  • [18] Z. Lu, R. Han, and J. Yu, “Bank run payment channel networks,” Cryptology ePrint Archive: Report 2020/456, 2020.
  • [19] C. Egger, P. Moreno-Sanchez, and M. Maffei, “Atomic multi-channel updates with constant collateral in bitcoin-compatible payment-channel networks,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pp. 801–815, 2019.
  • [20] E. Rohrer, J. Malliaris, and F. Tschorsch, “Discharged payment channels: Quantifying the lightning network’s resilience to topology-based attacks,” in 2019 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pp. 347–356, IEEE, 2019.
  • [21] G. Malavolta, P. Moreno-Sanchez, A. Kate, M. Maffei, and S. Ravi, “Concurrency and privacy with payment-channel networks,” in Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pp. 455–471, 2017.
  • [22] G. Malavolta, P. Moreno-Sanchez, C. Schneidewind, A. Kate, and M. Maffei, “Anonymous multi-hop locks for blockchain scalability and interoperability.,” in NDSS, 2019.
  • [23] M. Bellare and P. Rogaway, “Random oracles are practical: A paradigm for designing efficient protocols,” in Proceedings of the 1st ACM conference on Computer and communications security, pp. 62–73, ACM, 1993.
  • [24] I. Bentov and R. Kumaresan, “How to use bitcoin to design fair protocols,” in Advances in Cryptology – CRYPTO 2014 (J. A. Garay and R. Gennaro, eds.), (Berlin, Heidelberg), pp. 421–439, Springer Berlin Heidelberg, 2014.
  • [25] “A proposal for up-front payments: Hold fee.” https://lists.linuxfoundation.org/pipermail/ lightning-dev/2020-February/002548.html, February 2020.
  • [26] “Bolt 4: Onion routing protocol.” https://github.com/lightningnetwork/lightning-rfc/blob/ master/04-onion-routing.md#returning-errors.
  • [27] D. Robinson, “Htlcs considered harmful,” in Stanford Blockchain Conference, 2019.
  • [28] S. Tochner, S. Schmid, and A. Zohar, “Hijacking routes in payment channel networks: A predictability tradeoff,” arXiv preprint arXiv:1909.06890, 2019.
  • [29] A. Mizrahi and A. Zohar, “Congestion attacks in payment channel networks,” arXiv preprint arXiv:2002.06564, 2020.
  • [30] C. Pérez-Sola, A. Ranchal-Pedrosa, J. Herrera-Joancomartí, G. Navarro-Arribas, and J. Garcia-Alfaro, “Lockdown: Balance availability attack against lightning network channels,” 2019.
  • [31] A. Miller, I. Bentov, S. Bakshi, R. Kumaresan, and P. McCorry, “Sprites and state channels: Payment networks that go faster than lightning,” in International Conference on Financial Cryptography and Data Security, pp. 508–526, Springer, 2019.
  • [32] “A proposal for up-front payments.” https://lists.linuxfoundation.org/pipermail/ lightning-dev/2019-November/002282.html, November 2019.
  • [33] “A proposal for up-front payments: Reverse bond payment.” https://lists.linuxfoundation.org/pipermail/ lightning-dev/2020-February/002547.html, February 2020.
  • [34] S. Tikhomirov, P. Moreno-Sanchez, and M. Maffei, “A quantitative analysis of security, anonymity and scalability for the lightning network,” Cryptology ePrint Archive: Report 2020/303, 2020.
  • [35] I. Eyal, A. E. Gencer, E. G. Sirer, and R. V. Renesse, “Bitcoin-ng: A scalable blockchain protocol,” in 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), (Santa Clara, CA), pp. 45–59, USENIX Association, Mar. 2016.