Expired payment in ACINQ channel

[akumaigorodski]

A 45 SAT payment has been sent through phone <-> ACINQ channel a few days ago, as of now it is expired (but channel is still up since I've stopped closing them automatically), payment hash is 3dd1ed8148d617f1705eeec896a569b0dc36de5726bafe13b3ca439b28c2bb81.

[akumaigorodski]

Channel ID is 54d5886b4e975aba8f813205b2ba45bd7440bc65339757f8bccab27ba4f7511c

[pm47]

Damn, nice catch again! This is similar to #649, but a little bit different:

(a) Let's say remote is at commitment N
(b) We send an htlc and sign commitment N+1
(c) Counterparty decides to unilaterally close before receiving our new signature, using commitment N
(d) As soon as commitment N is confirmed, we need to fail the htlc, because the commitment it was included in will never reach the chain.

NB: since #649 we would have failed the htlc if our commitment (which also didn't contain the htlc) had made it to the chain.

This should be done here:

eclair/eclair-core/src/main/scala/fr/acinq/eclair/channel/Helpers.scala

Lines 736 to 752 in 12a80af

	/**
	* If a local commitment tx reaches min_depth, we need to fail the outgoing htlcs that only us had signed, because
	* they will never reach the blockchain.
	*
	* Those are only present in the remote's commitment.
	*
	* @param localCommit
	* @param remoteCommit
	* @param tx
	* @param log
	* @return
	*/
	def overriddenHtlcs(localCommit: LocalCommit, remoteCommit: RemoteCommit, tx: Transaction)(implicit log: LoggingAdapter): Set[UpdateAddHtlc] =
	if (localCommit.publishableTxs.commitTx.tx.txid == tx.txid) {
	// NB: from the p.o.v of remote, their incoming htlcs are our outgoing htlcs
	remoteCommit.spec.htlcs.filter(_.direction == IN).map(_.add) -- localCommit.spec.htlcs.filter(_.direction == OUT).map(_.add)
	} else Set.empty

Currently the failing of htlcs is only triggered by downstream channels. I'm thinking that for extra safety, the upstream channel (the one that received the htlc) could decide to fail the htlc right before the expiration, it is probably always better than closing the channel.