<p>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 <em>much</em> easier </p>
<hr />
<p>Given that you're asking for c-lightning let me walk you through the options you have:</p>
<h2>Wait and rebroadcast</h2>
<p>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 <code>fundchannel</code> or retrieve it from the database by looking its ID up:</p>
<pre><code>CHANID=$(lightning-cli listpeers [peer_id] | jq '.peers[].channel_id')
sqlite3 $HOME/.lightning/bitcoin/lightningd.sqlite3 \
        &quot;SELECT hex(rawtx) FROM transactions WHERE hex(id) LIKE '$CHANID'&quot;
</code></pre>
<p>This will get you the funding tx for that particular peer. You can use <code>bitcoin-cli decoderawtransaction</code> to decode the transactions and verify that the txid matches the <code>funding_txid</code> in the <code>lightning-cli listpeers</code> output.</p>
<p>You can then rebroadcast using the <code>bitcoin-cli sendrawtransaction</code> or <code>lightning-cli sendrawtransaction</code> methods.</p>
<p>I suggest waiting at least over the weekend, since fees drop considerably, increasing chances of the tx confirming anyway.</p>
<h2>Double-spending the funding transaction</h2>
<p>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.</p>
<p> 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 </p>
<p>To do this look up the funding transaction like above, then use the following to list the inputs of the funding transaction:</p>
<pre><code>bitcoin-cli decoderawtransaction [tx] | jq '.vin[] | [.txid, .vout]'
</code></pre>
<p>Next we synchronize the UTXO status with <code>bitcoind</code>, since we marked the outputs spent by the funding transaction as spent (note that you need to have c-lightning compiled with <code>DEVELOPER=1</code> for this to be available):</p>
<pre><code>lightning-cli dev-rescan-outputs
</code></pre>
<p>Now pick a subset of the inputs and create a new transaction, that collides with the funding transaction on purpose to double-spend it:</p>
<pre><code>lightning-cli utxopsbt satoshi=all feerate=normal startweight=756 utxos=[&quot;ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB:0&quot;]
</code></pre>
<p>This gives you a partially signed Bitcoin transaction (PSBT), which has one input <code>ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB:0</code> (matching the result from the <code>decoderawtransaction</code> 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.</p>
<p>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:</p>
<pre><code>lightning-cli newaddr
</code></pre>
<p>And now we need to amend the PSBT to include an output with all funds (minus the fee) going to that new address.</p>
<p>... 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.</p>

CC BY-SA 4.0
2021-02-03T13:16:14.847Z
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.
PyrolitePancake
CC BY-SA 4.0
2021-02-03T13:25:24.127Z
It's not a huge problem. But would it technically be possible to do a collaborative close to cancel the channel opening using CPFP?
PyrolitePancake
CC BY-SA 4.0
2021-02-03T13:27:09.003Z
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:
cdecker
CC BY-SA 4.0
2021-02-03T14:46:11.423Z
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.
PyrolitePancake
CC BY-SA 4.0
2021-02-03T15:22:45.013Z
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.
cdecker
CC BY-SA 4.0
2021-02-03T11:54:07.710Z
2021-02-03T11:54:07.710Z
cdecker
<p>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.</p>
<p>Notes when using LND:</p>
<p>Do not leave a channel open pending for more than 2 weeks because it will result to a failed state.</p>
<p>If there is a change output can use CPFP (<a href="https://api.lightning.community/?shell#bumpfee" rel="nofollow noreferrer">https://api.lightning.community/?shell#bumpfee</a>):</p>
<p><code>lncli wallet bumpfee --sat_per_byte 110 TXID:INDEX</code></p>
<p>RBF cannot be used for a channel funding txn.
Lightningwiki.net article:  <a href="https://lightningwiki.net/index.php/Bumping_fee_for_lightning_channel_open" rel="nofollow noreferrer">https://lightningwiki.net/index.php/Bumping_fee_for_lightning_channel_open</a></p>
<p>Overview of the options by LL: <a href="https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions" rel="nofollow noreferrer">https://docs.lightning.engineering/lightning-network-tools/lnd/unconfirmed-bitcoin-transactions</a></p>
<p>Can cancel the transaction so it is spent to a change address in Electrum:
<a href="https://github.com/openoms/lightning-node-management/blob/master/RestoreLNDonchainFundsInElectrum.md#manage-the-lnd-onchain-funds-in-electrum-wallet" rel="nofollow noreferrer">https://github.com/openoms/lightning-node-management/blob/master/RestoreLNDonchainFundsInElectrum.md#manage-the-lnd-onchain-funds-in-electrum-wallet</a></p>

CC BY-SA 4.0
2021-02-25T10:28:29.213Z
2021-05-27T14:07:37.513Z
2021-05-27T14:07:37.513Z
openoms
<p>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.</p>

CC BY-SA 4.0
2021-02-03T11:55:03.657Z
Technically 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.
cdecker
CC BY-SA 4.0
2021-02-03T08:00:24.097Z
2021-02-03T08:00:24.097Z
Rene Pickhardt
<p>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?</p>

<lightning-network><core-lightning><ln-closing-channels>
Can a channel be closed while the funding tx is still stuck in the mempool?
PyrolitePancake
# Can a channel be closed while the funding tx is still stuck in the mempool?

(Asked by: username_0 on 2021-02-03)

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?

**Tags:** lightning-network, core-lightning, ln-closing-channels


---

## 3 answers

### Answer by username_3 on 2021-02-03. Score: 7 | Accepted answer

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.

> **Comments:**
> **username_1**: Technically 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.  

---

### Answer by username_1 on 2021-02-03. Score: 6

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):

```
lightning-cli dev-rescan-outputs

```

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:

```
lightning-cli newaddr

```

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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: It's not a huge problem. But would it technically be possible to do a collaborative close to cancel the channel opening using CPFP?  
> **username_1**: 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:  
> **username_0**: 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.  
> **username_1**: 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.  

---

### Answer by username_2 on 2021-02-25. Score: 2

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/username_2/lightning-node-management/blob/master/RestoreLNDonchainFundsInElectrum.md#manage-the-lnd-onchain-funds-in-electrum-wallet>


---

