Status is saying to wait 8000 years.

"status":[
"ONCHAIN:Tracking our own unilateral close",
"ONCHAIN:6 outputs unresolved: in 4294967281 blocks will spend OUR_HTLC () using OUR_HTLC_TIMEOUT_TX"

Is there another / more detailed way to view the funds and timeouts in limbo from unilateral closes? Hopefully there is not a real lock of that duration?

Investigating further this recent one is not the first channel to close like this with unreasonable lock on the htlc (apparently?) . I'll share the output points, they are unspent in this transaction that settled 6 weeks ago

https://mempool.space/tx/9a274ce1885182c3fab67cce9ad8d83f6de717692eea6982939687ee130858d4

They appear to match the two htlcs in value:

"htlcs": [
                  {
                     "direction": "out",
                     "id": 66624,
                     "amount_msat": 600317573,
                     "expiry": 807207,
                     "payment_hash": "",
                     "state": "SENT_ADD_ACK_REVOCATION"
                  },
                  {
                     "direction": "out",
                     "id": 66625,
                     "amount_msat": 600317573,
                     "expiry": 807207,
                     "payment_hash": "",
                     "state": "SENT_ADD_ACK_REVOCATION"
                  }
               ]

So on chain funds do seem to actually be stuck here which is bad.

[cdecker]

It would appear that we have an integer underflow, since that number you posted above is UINT32_MAX - 15.

[NishantBansal2003]

It would appear that we have an integer underflow, since that number you posted above is UINT32_MAX - 15.

Hey @cdecker, I was looking into this issue and had a question: how could there be any integer underflow, given that it seems to have already been handled here?

lightning/onchaind/onchaind.c

Lines 931 to 950 in 9ce885b

	if (best) {
	/* If we've broadcast and not seen yet, this happens */
	if (best->proposal->depth_required <= best->depth) {
	peer_billboard(false,
	"%u outputs unresolved: waiting confirmation that we spent %s (%s) using %s",
	num_not_irrevocably_resolved(outs),
	output_type_name(best->output_type),
	fmt_bitcoin_outpoint(tmpctx, &best->outpoint),
	tx_type_name(best->proposal->tx_type));
	} else {
	peer_billboard(false,
	"%u outputs unresolved: in %u blocks will spend %s (%s) using %s",
	num_not_irrevocably_resolved(outs),
	best->proposal->depth_required - best->depth,
	output_type_name(best->output_type),
	fmt_bitcoin_outpoint(tmpctx, &best->outpoint),
	tx_type_name(best->proposal->tx_type));
	}
	return;
	}

Not sure if the uninitialised variable (is there any possibility of depth_required or depth being uninitialised?) can cause this integer underflow behavior?

[cdecker]

Hm, good point, I don't know. It won't be uninitialized data because we'd just get random values in there if it were and valgrind would tell us if we based a decision on uninit data. It also can't be a race because all our daemons are single threaded.