Lightning: Force-closed channel in limbo, closing tx hash incorrect ?

[camalolo]

Hello

I force closed a channel after the cooperative closing failed, but due to my mistake of using low fees, the transaction was never confirmed. I believe it is not even in the mempool now.

This is the transaction from lightning-cli listtransactions :

 {
         "hash": "352d80a7267164bb203e032b948c2f97c90b5eb2afeaae8abf5200366448d4a0",
         "rawtx": "0200000000010165d4e26ab695aa317ffe8c1e2097a864f3ef8023e7bdc6f1ccd44952c6e17e540000000000ffffffff02c1ad0100000000001600141922a154246600b536142cae4e92c89e45a5fe0de8eb050000000000160014607b49b1b86a1ffe5cc1497bbfcbbd45f8b4a2840400473044022064741af98ac1f30d2df74f0b4f1f71ab4bcb4a29416df3467aed025dced879b602205d283d388b87e38cf114bf05894b1cd8b70f35e695a3001f5a1903b207fca77d014830450221008f5389315e5549f5de60ff43e79aafcfd99e48c8b6c310ecb786e9c76c964755022074953b8f5b6c8a20788b9c3b87d5bf984688fef57760233350d4f18ce8abc073014752210252adb37af00b9f68b6b63fac6b0cb942fa231e043bbf54d53957373eebace0db2103586a053d44b4cea34caa13f14fe2fd6e5a96c09ea798811f8874939a25a2ce2552ae00000000",
         "blockheight": 0,
         "txindex": 0,
         "locktime": 0,
         "version": 2,
         "inputs": [
            {
               "txid": "547ee1c65249d4ccf1c6bde72380eff364a897201e8cfe7f31aa95b66ae2d465",
               "index": 0,
               "sequence": 4294967295
            }
         ],
         "outputs": [
            {
               "index": 0,
               "satoshis": "110017000msat",
               "scriptPubKey": "00141922a154246600b536142cae4e92c89e45a5fe0d"
            },
            {
               "index": 1,
               "satoshis": "388072000msat",
               "scriptPubKey": "0014607b49b1b86a1ffe5cc1497bbfcbbd45f8b4a284"
            }
         ]
      }

Now I I go to any blockchain explorer, I cannot find the transaction with hash 352d80a7267164bb203e032b948c2f97c90b5eb2afeaae8abf5200366448d4a0 :

https://blockstream.info/tx/352d80a7267164bb203e032b948c2f97c90b5eb2afeaae8abf5200366448d4a0
https://www.blockchain.com/search?search=352d80a7267164bb203e032b948c2f97c90b5eb2afeaae8abf5200366448d4a0

But if I check the original transaction that opened the channel (547ee1c65249d4ccf1c6bde72380eff364a897201e8cfe7f31aa95b66ae2d465), it is here and confirmed :

https://www.blockchain.com/btc/tx/547ee1c65249d4ccf1c6bde72380eff364a897201e8cfe7f31aa95b66ae2d465

And following the outputs, I can find a force close transaction, but with a different hash !

https://www.blockchain.com/btc/address/bc1qevy9nqd93xtlam4d8syz6el2umf9898zxe50rxpdvwxxq3z4ta6qlur9mj

=> The (unconfirmed) force close transaction has the hash c54da9a0c5946a8cb509a9ed24b1a3333e38a55c608b5ba95e9eb62c421dd8f3

It seems to have a slightly different fee from the original force-close transaction that lightning-cli shows in listtransactions output

My questions :

• Is that normal ? Does lightningd automatically resend the transactions with higher fees as time goes by ?
• Is there anything I can do to resend the force close transaction but with much more reasonable fees so it gets confirmed soon ?

Thank you so much for your help

[cdecker]

Hi camalolo, that transaction (352d80) seems to have indeed dropped
from the mempool, due to low fees. However it appears that there is
now a collaborative close [c54da9] being confirmed as I write
this. Apparently the collaborative close was rebroadcast either by you
or your peer so the channel should eventually be closed successfully,
with the lower fee than the unilateral. The delay is due to the
mempool contention due to high transaction volume, and slow feerate
estimate adjustment.

If you want to re-send the transaction manually because you think it
now has a better chance due to lower mempool usage, you can use the
rawtx field you have listed above and using lightning-cli sendrawtransaction [rawtx], and this will use your configured bitcoin
backend to resubmit the transaction.

As for the differing transaction IDs that's because one is a
collaborative close, signed by both you and your peer, with lower fees
since you don't need the longer script paths, and generally
collaborative closes don't have to overestimate the fees, since we
want the tx to confirm now, not some time in the future when we don't
know what the feerate is going to be.

It can however also happen that there are multiple unilateral close
txs when attempting to force-close multiple times, each time
generating a new signature and thus changing the transaction
ID. Structurally the transactions should not be different at all.

Hope this helps, and that the channel is going to be closed soon :-)

[camalolo]

Hello Christian, thank you very much for taking the time to reply in such a detailed manner ! I appreciate it !

[camalolo]

Christian, I forgot to ask one question, I hope you can answer here.

In theory, what would happen if the close transaction (whether cooperative or unilateral) never ever gets confirmed ? How would one recover the funds in the channel in that case ? Can I re-force close the channel uniterally (maybe with higher fees) ?

Sorry if it's a stupid question, I just cannot find a clear answer online. Seems most people have the problem with the open transaction, in which case it's just safe to "forget" the channel. But in my case, I don't think it would be safe to do that ?

Thank you again.

[cdecker]

Sadly it is currently not possible to bump fees on a unilateral close, since the fees are committed to in the commitment transaction (you'd need your peer to sign off on the new fees since their signature eod get invalidated by the fee change). We are working on a spec amendment that'd allow using CPFP via anchor outputs to allow variable fees on commitment and HTLC transactions, so this may be possible some time soon (once both peers support anchor outputs).

[camalolo]

Great news. Thanks for your good work !