[Lightning-dev] Proof-of-closure as griefing attack mitigation

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Apr 2 00:43:11 UTC 2020


Good morning Nadav,


> Love the idea! I have a couple questions though:
>
> I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective. Consider a similar network to the one you described where we have channels A - B - C and A - E - C but where we add a "fake" channel E - E'. Now if the attacker sets up a payment from E to E' using the route E - C - B - A - E - E', then the attacker can successfully lock up all of B's channels (as is desirable to get rid of competition) and also generate a false proof of closure for the E - E' channel. Even if this false proof (which is a commitment tx) ends up being published on chain, E has lost no ability to route and has successfully made B unable to route between A and C. If my understanding of the proposal is correct, and it may not be, then the punishment for grieving payments is the threat of closing channels that would benefit from the grieving attack. But adding a new channel on the end to be closed seems to invalidate this punishment?

The consideration is that much of the cost of a channel is with the setup and teardown --- E could always just reopen the CE channel again later.
Thus, the cost that E bears in setting up EE and tearing down EE would be still similar to the cost of losing CE and reestablishing it again.
Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere).
Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one.

So the mere existence of EE, to be later sacrificed, is enough punishment on E.
I think.

>
> A second question I have is if you think that it would be advisable to use up-front payments (pay for attempt, not just success) on payments with abnormally high soft timeouts? If all this works, this combination seems to be a way to enable hodl invoices under the proof of closure proposal.

Possibly, though this increases the complexity of the proposal even more.

>I just thought of a potentially more serious problem, at least for Poon-Dryja channels, isn't it true that giving a proof of closure is equivalent to actually closing the channel since once other parties have copies of the fully signed commitment transaction, it cannot be safely revoked since other parties now have the ability to publish an old state? I might be missing something but this seems like a big problem.

Since this is a proof-of-***closure***, this is indeed an actual closing of the channel.
It would not be proof-of-closure if the channel was not being closed, but proof-of-something-else.

What is desired is simply that C can plausibly say "I punished somebody else by closing on them, please do not punish me for punishing them".

Regards,
ZmnSCPxj



More information about the Lightning-dev mailing list