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

ZmnSCPxj ZmnSCPxj at protonmail.com
Sun Apr 12 08:30:29 UTC 2020


Good morning Nadav, and list,

Thinking even further:

* It is trivially cheap for E to start up new nodes F and G and start up channels FA and GC.
* It then becomes possible for E to lock up funds of B via F->A->B->C->G and G->C->B->A->F.
* Even closure of FA and GC does not affect EA and EB.

So I am not certain that this attack is solvable at all via inter-node interactions, since we must also consider the possibility of some throwaway node being created for the purpose of executing this attack.

Perhaps the remaining possible solution is to require that nodes also lock up some funds (in a UTXO that is *separate* from any channels, and from other fidelity bonds, like what belcher suggests for JoinMarket makers, and what is intended for defiads).
This creates an economically-barred identity, which we might ascribe blame to, and perhaps with sufficient amount of proofs, allow someone to create a "proof-of-bad-behavior" that can be believed by other nodes on the network.
The locked up fidelity bonds are an additional cost that an attacker must bear which their possible victims will not bear.

Perhaps the "superbolt network" idea might consider adding such a mitigation, as it also requires some form of persistent identity anyway.

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list