I have attempted to open a channel recently, but accidentally set the fee for the funding transaction too low. Now the funding tx has been stuck in the mempool for over a week. Is there some way to close the channel even though it was never actually opened?
Technically you can double spend the output that was used for the funding TX with a higher fee. Then the channel will never be opened. Practically I don't think any of the lightning network implementations offer an api to do so.
2Technically it is possible with c-lightning, but the instructions are involved and require some devtools to get the last few steps working. I'm hoping to write the missing tools and a plugin tying them all together, so this becomes easier. Feb 3, 2021 at 11:55
I started out writing this answer while trying to do it myself, but then found out that we don't yet have tools to manually edit partially signed Bitcoin transactions (PSBTs) which is the very last step before we finalize the double-spend. So this answer is currently incomplete, but I'm planning on building out that tooling and write a plugin that automates all of this, so it get much easier 😉
Given that you're asking for c-lightning let me walk you through the options you have:
Wait and rebroadcast
If the fee is not way too low, and the peer hasn't given up yet, you could have a chance of still establishing the channel, by confirming the original funding transaction. It might require you to rebroadcast the transaction from time to time when it drops out of the mempool. To do so take note of the funding transaction that was returned when calling
fundchannel or retrieve it from the database by looking its ID up:
CHANID=$(lightning-cli listpeers [peer_id] | jq '.peers.channel_id') sqlite3 $HOME/.lightning/bitcoin/lightningd.sqlite3 \ "SELECT hex(rawtx) FROM transactions WHERE hex(id) LIKE '$CHANID'"
This will get you the funding tx for that particular peer. You can use
bitcoin-cli decoderawtransaction to decode the transactions and verify that the txid matches the
funding_txid in the
lightning-cli listpeers output.
You can then rebroadcast using the
bitcoin-cli sendrawtransaction or
lightning-cli sendrawtransaction methods.
I suggest waiting at least over the weekend, since fees drop considerably, increasing chances of the tx confirming anyway.
Double-spending the funding transaction
If you need the funds somewhere else, or decided the channel isn't worth waiting for you can also double-spend any of the inputs and the funding transaction will never be able to confirm.
🚧 Notice that you wont be able to open a new channel with that specific peer until both sides have given up, as from c-lightning's point of view it may still happen and we need to be ready if it does 🚧
To do this look up the funding transaction like above, then use the following to list the inputs of the funding transaction:
bitcoin-cli decoderawtransaction [tx] | jq '.vin | [.txid, .vout]'
Next we synchronize the UTXO status with
bitcoind, since we marked the outputs spent by the funding transaction as spent (note that you need to have c-lightning compiled with
DEVELOPER=1 for this to be available):
Now pick a subset of the inputs and create a new transaction, that collides with the funding transaction on purpose to double-spend it:
lightning-cli utxopsbt satoshi=all feerate=normal startweight=756 utxos=["ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB:0"]
This gives you a partially signed Bitcoin transaction (PSBT), which has one input
ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB:0 (matching the result from the
decoderawtransaction results above) and no output. Notice the startweight is 756sipa, which is approximately the size of a single-input-single-output transaction which we're trying to build.
This isn't a valid transaction yet, so we need to add an output that goes back into your wallet. To do this we first generate an address to send to your wallet:
And now we need to amend the PSBT to include an output with all funds (minus the fee) going to that new address.
... but we don't have tools in place yet to manually edit a PSBT, or at least I'm no aware of any. I'll follow up once we have.
The channel was really just a test, hence the low fee. However, the problem is now I cant open a new channel to the same peer because I am not allowed more than one channel to the same peer. I guess I will wait over the weekend and see if the problem fixes itself. Feb 3, 2021 at 13:16
It's not a huge problem. But would it technically be possible to do a collaborative close to cancel the channel opening using CPFP? Feb 3, 2021 at 13:25
The funding only requires the signature from the funder, the fundee doesn't have a stake yet. We have a proposal for dual-funding with replace-by-fee to address just this issue :+1: Feb 3, 2021 at 13:27
But does the fundee have anything to loose by just signing the collaborative closing transaction that pays everything back to the funder to cancel the channel? Idk, I am probably missing some problem with that solution, it seems the most elegant though. Feb 3, 2021 at 14:46
It's just a matter of efficiency: double-spending is a single transaction, closing requires both the funding as well as the closing transaction. That being said, I don't see why the peer couldn't just sign a collaborative close right away, and then forget about it. Feb 3, 2021 at 15:22
Cannot close a channel which has not been opened yet, but you can either bump the fee of the transaction by CPFP or cancel by double spending the unconfirmed input.
Notes when using LND:
Do not leave a channel open pending for more than 2 weeks because it will result to a failed state.
If there is a change output can use CPFP (https://api.lightning.community/?shell#bumpfee):
lncli wallet bumpfee --sat_per_byte 110 TXID:INDEX
RBF cannot be used for a channel funding txn. Lightningwiki.net article: https://lightningwiki.net/index.php/Bumping_fee_for_lightning_channel_open
Overview of the options by LL: https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions
Can cancel the transaction so it is spent to a change address in Electrum: https://github.com/openoms/lightning-node-management/blob/master/RestoreLNDonchainFundsInElectrum.md#manage-the-lnd-onchain-funds-in-electrum-wallet