[Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack

ZmnSCPxj ZmnSCPxj at protonmail.com
Fri Jun 5 11:23:12 UTC 2020


Good morning Subhra,

> We had mentioned in the paper under Discussions (Section 6.3) that we do not handle attacks concerning soft-griefing, i.e., if a party withholds the preimage for a long time but releases just before the expiration of locktime. We think with the current set of instructions supported in Bitcoin, it is hard to settle soft-griefing related disputes, accounting penalty for each unit of elapsed time. In case of soft-griefing, we neither impose the griefing penalty, nor is there a chance to reverse-grief.

In fact, what you call the "soft-grief" *is* the griefing attack you expect to see on the network.

If the receiver R let the time elapse, then the forwarding node just before the receiver R will close the channel.
Closing a channel and later re-establishing it (in order to mount the attack again, remember, this is an attempt to DoS your competitors, and is thus best done continuously) is expensive.

Thus all griefing attacks will, in practice, involve what you call "soft" griefing, i.e. the payment is cancelled just before the timeout arrives, before the last forwarding node closes the channel.
But it is precisely this "soft" griefing which is the problem.

So:

* It is immaterial that you punish R if it lets the time elapse --- channel close is sufficient punishment.
* What is material is that if R cancels the payment *just before* the lock time, it should be punished --- there is currently no way to do this.

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list