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

[ZmnSCPxj]

Good morning Dave,

> > Ah, right, E knows the revocation for the unilateral close of EE,
> > because it is a self-channel, sigh. And by this revocation clause it
> > can claim the money immediately and put it into a channel as well.
>
> If it's a self channel, E can also just RBF replace the close
> transaction with a minimally-sized 1-input, 1-output transaction.
>
> In addition, if typical mempools are full and the closing transaction
> feerate is very low (i.e. because anchor outputs are meant to be used)
> E may also be able to create a close transaction that will be
> dropped from typical mempools in the near future and may never
> confirm, allowing E to continue using the channel in attacks against its
> other peers.

Most nodes are programmed to presume that once a possible close of a channel is seen on a mempool, the channel is closed and the node will no longer sign any updates on it, so this is only possible if E controls the other end of the channel, i.e. this is just another variant of the EE channel.

In particular, once E has released any closing transaction as proof-of-closure, C, B, A etc. can keep posting it to the mempool even if it drops out, so E would probably not want to revoke that closing transaction as its counterparty can then revoke it and take the funds in the channel.
So this is safe only if the counterparty cooperates, or in other words, if E and its counterparty are the same entity.

Regards,
ZmnSCPxj