Return transaction unconfirmed after 432 blocks on their unilateral close

[koljenovic]

Connected to 02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432 and funded a channel with txid 593a369244f6ab2b96d68548f76c760a95a6ffff1d2b37a7c499302c456b2497. The channel went up but immediately it was unilaterally closed by them and the funds went into waiting, the channel closed and the funds were sent back with the transaction below, which is still listed as unconfirmed after more than 432 blocks, tried dev-rescan-outputs, nothing changed.

{ "txid" : "41c177c38cbe883a053802cb06f6da36bc151535c5c21a7c30ee2372f9c8e875", "output" : 0, "value" : 298416, "status" : "unconfirmed" }

I also tried opening another channel with a different node, that one failed too with OUR_UNILATERAL, the return transaction was issued and confirmed, and the channel closed.

Also the address where the unconfirmed funds have ended up bc1qfk2azttjssqtsnaq7j7v7cm53w04rscshwjy8t is not listed in the dev-listaddrs output.

[cdecker]

Seems we are forgetting to increment the bip32_max_index. Could you run lightning-cli newaddr a few times and see if the address is added?

[cdecker]

One thing to note is that the unconfirmed state does not have any effect on you being able to spend it, but I'd like to fix the display.

[koljenovic]

Tried a couple hundred newaddr without success, also tried #1156 (comment) and the address does not show up. Will try withdrawing all.

[cdecker]

Oh, right I see what happened here, the their_unilateral/to_us output is not part of the HD key derivation, but it's a key that is generated cooperatively with the peer (don't ask me why), which means that it can't be returned using dev-listaddrs. That simply means that we need a special case for that type of output.

[koljenovic]

I can confirm successful withdrawal with txid dfa92b718aa13f77951662a876a4f379e1a573c3142540acd7868b042c353897. I believe we tracked the source of the issue regarding the address listing so it can be fixed. Thanks for your help. 😃

[cdecker]

Thanks for reporting this and the update, I'll check how to add tracking for that special case.

[cdecker]

I opened #1209 to track this specific issue.