ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-20 📝 Original message: Good morning Subhra et ...
📅 Original date posted:2020-05-20
📝 Original message:
Good morning Subhra et al,
I am unsure whether you actually solve the Reverse-Griefing attack that the Griefing-Penalty enables.
It seems to me that Reverse-Griefing is worse than Griefing, since it causes loss of funds already owned, whereas griefing only causes loss of opportunity to earn.
In particular:
> 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.
Given we route using onion routing, it would be trivial to create a loop in the route so that the same node occurs twice in it, thus trivially meeting the "at least two nodes in the path must be corrupted" requirement.
That is, the sender and the receiver can be the same node, making it appear twice in the path.
> Though we assume honest party will act rationally, in reality a party is selfish
This does not make sense.
Rationality requires some goal to work toward.
Often, the goal is "look out for number one" i.e. be selfish.
Thus, an economically rational selfish entity is not a contradiction in terms: instead, it is simply applying its rationality towards its own self-interest.
Can you clarify what *goal* you are assuming the party has, which the party is applying its rationality towards?
--
In general, all work towards such open standards as Lightning Network and so on have the motivating goal of "creating value": by fixing problems and improving specs, everyone gets a better Lightning Network and (hopefully) benefits.
However this is not the ultimate goal towards we work toward.
Instead, this is an instrumental goal, with the ultimate goal being to acquire more value; the act of creating value is then performed in the hope that the increase in global value will also translate to an increase in your own value.
Thus, any forwarding node, by increasing liquidity on the Lightning Network, does so in the hope that it will capture some of the increased value:
* Directly, by earning fees.
* Indirectly, by promoting the use of Lightning and earning more future fees.
* Even more indirectly, by promoting the use of Lightning on top of Bitcoin and increasing the value of any Bitcoin held in channels.
Thus ultimately all honest behavior is ultimately honestly-rationally-selfish behavior.
So if an honestly-self-rational node could be tempted to setting up reverse-griefing attacks, it seems to me that grief-penalty cannot work well as a solution to griefing.
The solution should really prevent griefing without introducing any reverse-griefing.
Regards,
ZmnSCPxj
> Hi,
>
> We went through the discussion of Griefing Attack and after a thorough analysis, we realized that the attack cannot be prevented as the adversary doesn’t suffer any loss of funds.
>
> We propose an efficient countermeasure for the attack, known as Griefing-Penalty. Our proposed strategy works for any timelock based payment protocol. The penalty compensates for the loss incurred by the intermediaries, affected by griefing attack. You will find the paper Griefing-Penalty: Countermeasure for Griefing Attack in Bitcoin-compatible PCNs on arXiv. We look forward to hearing from the community on the feasibility of the approach and whether it can be implemented or not.
>
> Our Contribution to the paper:
>
> • 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
>
> We will briefly summarize the problem and our contribution through an example.
>
> The problem of Griefing Attack explained briefly
>
> Consider the situation where A wants to transfer 1 msat to C. It figures out a path connecting it to C, in the form A->B->C. A establishes an HTLC with B, locking 1 msat in the contract having expiration time of say 2 days. B after receiving the incoming contract, forms a contract with C, locking 1 msat in the contract with locktime of 1 day.
>
> A------------------------->B---------------------->C
>
> HTLC(1msat, 2 day) HTLC(1msat, 1 day)
>
> Now if C griefs, funds of A and B remain locked as they cannot resolve HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1 msat. The problem with this construction is that C doesn’t lose anything.
>
> Griefing-Penalty: a strategy to penalize the adversary
>
> Hence we have come up with the following idea:
>
> 1) An off-chain contract established between 2 parties requires both the parties to lock funds – one party locking the amount that is to be forwarded and the other party locking the fund which can be claimed as a penalty, if this party griefs.
>
> 2) The penalty locked is proportional to the product of the amount being forwarded and the expiration time of the contract. All the parties affected by griefing must get compensation since their liquidity is tied up for a certain period of time.
>
> Considering the example used for demonstrating griefing attack. We modify the contract and term it as HTLC-GP (Hashed Timelock Contract with Griefing Penalty). We assume a rate of penalty, say 0.01 per hour, for calculating the penalty the party has to lock in order to accept an off-chain contract request.
>
> A forwards the term of the contract to B, requesting B to lock 0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the total amount locked in the contract is 1.48 msat. In the same way, B forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24 msat as a penalty. B locks 1 msat in the contract, so the total amount locked in the contract is 1.24 msat. If the payment is not resolved within 1 day, all the parties who have forwarded the contract will claim the penalty locked in the contract.
>
> A-------------------------------------->B-------------------------------->C
>
> HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day)
>
> If C releases the preimage before the expiration of locktime, it will claim the full amount locked in the contract, i.e. 1.24 msat. Similarly, B claims 1.48 msat from the contract established with A.
>
> Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the contract. C loses 0.24 msat. When B cancels contract with A, it will settle by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is not desired as B was not involved in mounting the attack. As per the objective, even B should earn a remuneration as it got affected by griefing.
>
> Hence, B should have asked C to lock funds in the contract which can be used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat = 0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with itself as compensation.
>
> A-------------------------------------->B-------------------------------->C
>
> HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day)
>
> A------------------------------------->B-------------------------------->C (griefs)
>
> (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 msat)
>
> --
> Yours sincerely,
> Subhra Mazumdar.
📝 Original message:
Good morning Subhra et al,
I am unsure whether you actually solve the Reverse-Griefing attack that the Griefing-Penalty enables.
It seems to me that Reverse-Griefing is worse than Griefing, since it causes loss of funds already owned, whereas griefing only causes loss of opportunity to earn.
In particular:
> 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.
Given we route using onion routing, it would be trivial to create a loop in the route so that the same node occurs twice in it, thus trivially meeting the "at least two nodes in the path must be corrupted" requirement.
That is, the sender and the receiver can be the same node, making it appear twice in the path.
> Though we assume honest party will act rationally, in reality a party is selfish
This does not make sense.
Rationality requires some goal to work toward.
Often, the goal is "look out for number one" i.e. be selfish.
Thus, an economically rational selfish entity is not a contradiction in terms: instead, it is simply applying its rationality towards its own self-interest.
Can you clarify what *goal* you are assuming the party has, which the party is applying its rationality towards?
--
In general, all work towards such open standards as Lightning Network and so on have the motivating goal of "creating value": by fixing problems and improving specs, everyone gets a better Lightning Network and (hopefully) benefits.
However this is not the ultimate goal towards we work toward.
Instead, this is an instrumental goal, with the ultimate goal being to acquire more value; the act of creating value is then performed in the hope that the increase in global value will also translate to an increase in your own value.
Thus, any forwarding node, by increasing liquidity on the Lightning Network, does so in the hope that it will capture some of the increased value:
* Directly, by earning fees.
* Indirectly, by promoting the use of Lightning and earning more future fees.
* Even more indirectly, by promoting the use of Lightning on top of Bitcoin and increasing the value of any Bitcoin held in channels.
Thus ultimately all honest behavior is ultimately honestly-rationally-selfish behavior.
So if an honestly-self-rational node could be tempted to setting up reverse-griefing attacks, it seems to me that grief-penalty cannot work well as a solution to griefing.
The solution should really prevent griefing without introducing any reverse-griefing.
Regards,
ZmnSCPxj
> Hi,
>
> We went through the discussion of Griefing Attack and after a thorough analysis, we realized that the attack cannot be prevented as the adversary doesn’t suffer any loss of funds.
>
> We propose an efficient countermeasure for the attack, known as Griefing-Penalty. Our proposed strategy works for any timelock based payment protocol. The penalty compensates for the loss incurred by the intermediaries, affected by griefing attack. You will find the paper Griefing-Penalty: Countermeasure for Griefing Attack in Bitcoin-compatible PCNs on arXiv. We look forward to hearing from the community on the feasibility of the approach and whether it can be implemented or not.
>
> Our Contribution to the paper:
>
> • 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
>
> We will briefly summarize the problem and our contribution through an example.
>
> The problem of Griefing Attack explained briefly
>
> Consider the situation where A wants to transfer 1 msat to C. It figures out a path connecting it to C, in the form A->B->C. A establishes an HTLC with B, locking 1 msat in the contract having expiration time of say 2 days. B after receiving the incoming contract, forms a contract with C, locking 1 msat in the contract with locktime of 1 day.
>
> A------------------------->B---------------------->C
>
> HTLC(1msat, 2 day) HTLC(1msat, 1 day)
>
> Now if C griefs, funds of A and B remain locked as they cannot resolve HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1 msat. The problem with this construction is that C doesn’t lose anything.
>
> Griefing-Penalty: a strategy to penalize the adversary
>
> Hence we have come up with the following idea:
>
> 1) An off-chain contract established between 2 parties requires both the parties to lock funds – one party locking the amount that is to be forwarded and the other party locking the fund which can be claimed as a penalty, if this party griefs.
>
> 2) The penalty locked is proportional to the product of the amount being forwarded and the expiration time of the contract. All the parties affected by griefing must get compensation since their liquidity is tied up for a certain period of time.
>
> Considering the example used for demonstrating griefing attack. We modify the contract and term it as HTLC-GP (Hashed Timelock Contract with Griefing Penalty). We assume a rate of penalty, say 0.01 per hour, for calculating the penalty the party has to lock in order to accept an off-chain contract request.
>
> A forwards the term of the contract to B, requesting B to lock 0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the total amount locked in the contract is 1.48 msat. In the same way, B forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24 msat as a penalty. B locks 1 msat in the contract, so the total amount locked in the contract is 1.24 msat. If the payment is not resolved within 1 day, all the parties who have forwarded the contract will claim the penalty locked in the contract.
>
> A-------------------------------------->B-------------------------------->C
>
> HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day)
>
> If C releases the preimage before the expiration of locktime, it will claim the full amount locked in the contract, i.e. 1.24 msat. Similarly, B claims 1.48 msat from the contract established with A.
>
> Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the contract. C loses 0.24 msat. When B cancels contract with A, it will settle by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is not desired as B was not involved in mounting the attack. As per the objective, even B should earn a remuneration as it got affected by griefing.
>
> Hence, B should have asked C to lock funds in the contract which can be used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat = 0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with itself as compensation.
>
> A-------------------------------------->B-------------------------------->C
>
> HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day)
>
> A------------------------------------->B-------------------------------->C (griefs)
>
> (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 msat)
>
> --
> Yours sincerely,
> Subhra Mazumdar.