HTLCs that are close to timing out upstream are potentially dangerous.
HTLCs that are close to timing out upstream are potentially dangerous. If we received the pre-image for those HTLCs, we need to get a remote signed updated commitment that removes this HTLC. Otherwise when we get close to the upstream timeout, we risk an on-chain race condition between their HTLC timeout and our HTLC success in case of a force-close.
(Since version ) see corresponding Javadoc for more information.
about remoteNextCommitInfo: we either: - have built and signed their next commit tx with their next revocation hash which can now be discarded - have their next per-commitment point So, when we've signed and sent a commit message and are waiting for their revocation message, theirNextCommitInfo is their next commit tx. The rest of the time, it is their next per-commitment point