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

Rusty Russell rusty at rustcorp.com.au
Mon Apr 6 01:20:18 UTC 2020


Hi ZmnSCPxj,

        This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.

> Secondly, C needs to prove that the channel it is willing to close involves the payment attempt, and is not some other channel closure that it is attempting to use to fulfill its own soft timeout.
> Since the unilateral close transaction *is* the proof-of-closure, B (and A) can inspect the transaction outputs and see (with some additional data from C) that one of the outputs is to an HTLC that matches the payment hash.
>
> Thus, B (and A) can believe that the proof-of-closure proves that whoever is presenting it is free of wrongdoing, as whoever is actually causing the delay has been punished (by someone being willing to close a channel with the culprit), and that the proof-of-closure commits to this particular payment attempt and no other (because it commits to a particular payment hash).

As you note below, the payment might be considered dust, or an
unresponsive peer has not yet acked the HTLC.

My previous proposal was to limit the damage somewhat by requiring that
C offer a signed list of some limited number of HTLCs it is claiming
were caught, alongside the closure proof (you can merkle this, but
that's a detail).  That closure claim gets socialized, and if there are
multiple different claim lists for the tx then C is a bad actor and we
no longer respect its closure proof.

You also missed how the timeout would work, which is important.  How
long does node N wait for a proof?  In my construction, it's 30 seconds,
plus get another 30 seconds for each decryption of the onion it
receives.

Otherwise, you can't know how long you've got to provide this closure
proof, or how long to wait for it.

In addition, for closure proofs to work, nodes need to agree on what is
a valid, standard, high-enough-fee commitment transaction.

Cheers,
Rusty.


More information about the Lightning-dev mailing list