Core Lightning Bump fee

[frbitten]

There could be a bumpfee option in the RTL interface.

I requested the closure of a channel through RTL but it was created with a very low fee and the transaction does not confirm. There could be a way to do a bumpfee on the closing transaction.

Is there any way to do this via the command line?

I'm using RTL 0.14 and Core Lightning 23.08.01

[saubyk]

Hi @frbitten you need to know the closing transaction ID (which you can also trace from the channel opening transaction as well).
Also assuming that this is a cooperative close and not force close.
Once you have the pending transaction ID for your local balance, you can generate a new address and spend that unconfirmed UTXO, to the new address with a high enough fee that it creates a higher cumulative fee rate for both the transactions.
Please note that all of the above is via the command line.

[saubyk]

Please note that you cannot do the above for the force close.

[frbitten]

Theoretically I understand what needs to be done. But when practicing, I don't know which commands to use. Because in Core lightning I only see command for opening transaction bumpfee.
How do I do a closing transaction? It's a collaborative transaction and I already have her TxId.
In bitcoin-cli I saw the bumpfee command but I don't know how to load the lightning wallet in bitcoin-cli.
If you can help by indicating the commands that should be used.

[saubyk]

So, lets get one thing out of the way first. It's not a good idea at all to load your lightning wallet into Bitcoin-cli and attempt to bump up pending channel close transaction. It's not going to work.

Also, I don't understand what you mean by below:

How do I do a closing transaction? It's a collaborative transaction and I already have her TxId.

For now I am going to assume that you've not closed your channel with a force close and provide guidance based on that. But if you've done a force close, you can ignore the below part.

If you want to do this, you have to figure out how to do it via core lightning command line interface. That's the only possible way for it work, if it's going to work at all. And core lightning has all the pieces to make it work, you have to just execute the commands in order. I would highly recommend practicing with a testnet node first, before you attempt to do this with your mainnet node.

I will try to give you the sequence, but you have to refer to the command line documentation to learn exact usage:
step 1: figure out your unconfirmed UTXO (pending transaction for your local balance)
step 2: generate a new address for your core lightning wallet via command newaddr
step 3: use the withdraw command to send your unconfirmed utxo (from step 1) to the new address (from step 2) you've generated.

The withdraw command would take inputs of theutxos, minconf and satoshi to execute
In your case you have to specify minconf as 0 and satoshi as all

Below are the references for the documentation for the rpcs:
newaddr -> https://docs.corelightning.org/reference/lightning-newaddr
withdraw -> https://docs.corelightning.org/reference/lightning-withdraw

And for future reference, please pay attention to the prevailing mempool fee rates before doing onchain transactions and pay enough fee rate to avoid situations like this.

If any of the above looks too complicated, I would recommend getting in touch with a local expert you can guide you better. Hope this helps.

[frbitten]

The closing of the channel is collaborative and the closing transaction is this: https://mempool.space/pt/tx/03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326

So I imagine that the UTXO you are talking about is the destination address for the funds. In this case, bc1q5x5vy24y6nsppkph2wrtp7qfxg2s0r5gc2g0yv

Am I right?

[saubyk]

No, the UTXO will be:
03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326:0

[frbitten]

I have the following error when trying to withdraw
{ "code": -32602, "message": "Unknown UTXO 03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326:0" }

But apparently UTXO is correct. Because I find the transaction not confirmed in the list when using listtransactions.

{
"hash": "03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326",
"rawtx": "02000000000101ec3f9d511389e5d3cb8ba6a7d96c7afba35052e3cf2953f953958ebbf43dd2270000000000ffffffff019358150000000000160014a1a8c22aa4d4e010d8375386b0f8093215078e8804004730440220336ab7faaa59f599d3408bc26eae550cbf59b4eaca4d3ea64fb3f23c0ff14b4b02202ea8e8cb10c940a31f0c8fd119d5535c2e2a0a5a9eba4ddaa218466e4e143ecf014730440220387beead567306910c5bc146ca8c62068331df94c26cd44c4ced48c917ff55d9022063a979de5b1b901764f090ec17124e0e3a9d57c4efe8c44d76b9807fd21eaef90147522103e5a8747a3f682a6ab3f0ffe86cca5ac6a5b391e5f09b5c20111ac16d37326f842103f122ffb79ee96deadd3c2f52b8eb8b4586dcf26238a72e65ecfb60e17c66990552ae00000000",
"blockheight": 0,
"txindex": 0,
"locktime": 0,
"version": 2,
"inputs": [
{
"txid": "27d23df4bb8e9553f95329cfe35250a3fb7a6cd9a7a68bcbd3e58913519d3fec",
"index": 0,
"sequence": 4294967295
}
],
"outputs": [
{
"index": 0,
"amount_msat": 1398931000,
"scriptPubKey": "0014a1a8c22aa4d4e010d8375386b0f8093215078e88"
}
]
}

Am I doing something wrong?

[saubyk]

Your UTXO is correct, but it's likely that the transaction might have been dropped out of your node's mempool, depending on when it was created or the size of the mempool your Bitcoin node is currently configured with.

You can try two things:

• increase the size of your bitcoin node's mempool to 1 GB i.e. maxmempool=1000
• rebroadcast the transaction again from core lightning via the command sendrawtransaction

I can see that transaction is a week old and still there in mempool.info's mempool, so it's likely that just by trying the first item above, you may be able to fee bump the transaction again.

hope this helps.

[Ciugam]

Hi @saubyk,
A question about this method to create CPFP tx.
Let's suppose the channel gets a cooperative close.
Channel has 100k sats.
If the channel closure tx involves 2 outputs, one output mine (90k) and another to the counterpart (10k), do the steps remain the same?
So:

1. get the txid of the closure channel;
2. get a new address;
3. use widthraw with only commands you said, so satoshi to all and minconf to 0.
   Right?
   Thanks in advance

[frbitten]

I increased the mempool and did the sendrawtransaction. I'm still having the same problem. What caught my attention is that apparently my node's mempool doesn't increase above 300MB. Even though the maximum is set to 1000MB.
The output of the bitcoin-cli getmempoolinfo command:

{
"loaded": true,
"size": 137105,
"bytes": 56084952,
"usage": 299853264,
"total_fee": 7.44996934,
"maxmempool": 1000000000,
"mempoolminfee": 0.00001000,
"minrelaytxfee": 0.00001000,
"incrementalrelayfee": 0.00001000,
"unbroadcastcount": 0,
"fullrbf": true
}
Usage is always between 300M and 299M. But in mempool.space there are many more transactions than that in the mempool.

The output of the command bitcoin-cli getmempoolentry 03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326 for the transaction I want to bump

{
"vsize": 137,
"weight": 548,
"time": 1695127103,
"height": 808436,
"descendantcount": 1,
"descendantsize": 137,
"ancestorcount": 1,
"ancestorsize": 137,
"wtxid": "bc2d275f38fec4642ebc49b23e27644d4c23631b7e9138f856ffc9de34f050ee",
"fees": {
"base": 0.00001069,
"modified": 0.00001069,
"ancestor": 0.00001069,
"descendant": 0.00001069
},
"depends": [
],
"spentby": [
],
"bip125-replaceable": false,
"unbroadcast": false
}

Why does getmempoolentry return transaction information but lightning does not find the UTXO?

If I search for the UTXO it is found.
lightning-cli --lightning-dir=/hdd/cln/.lightning getutxout 03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326 0

{
"amount": "1398931sat",
"script": "0014a1a8c22aa4d4e010d8375386b0f8093215078e88"
}

With the command bitcoin-cli getrawmempool I see my transaction in the list.

[saubyk]

@frbitten can you paste the complete command you're trying to run here?

[frbitten]

lightning-cli --lightning-dir=/hdd/cln/.lightning withdraw bc1q872l2x6ydyqmnq5hslfeafx8wxsak39adxa30e all 20000perkb 0 ["03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326:0"]

[saubyk]

lightning-cli --lightning-dir=/hdd/cln/.lightning withdraw bc1q872l2x6ydyqmnq5hslfeafx8wxsak39adxa30e all 20000perkb 0 ["03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326:0"]

All looks good here AFAIU. It might be worth while to open an issue with core lightning to find out, why you're not able to bump up the transaction this way.

Also, it would be interesting to look at the listpeers <your peer's pubkey> output. It can provide us some insight into the state transition of the channel and what the state of subsequent onchain transaction is.

[saubyk]

Hi @saubyk, A question about this method to create CPFP tx. Let's suppose the channel gets a cooperative close. Channel has 100k sats. If the channel closure tx involves 2 outputs, one output mine (90k) and another to the counterpart (10k), do the steps remain the same? So:

1. get the txid of the closure channel;
2. get a new address;
3. use widthraw with only commands you said, so satoshi to all and minconf to 0.
   Right?
   Thanks in advance

@Ciugam yes theoretically you should be able to do it with these steps, but we have yet to see a successful outcome of following those steps as part of the investigation on this issue. 😅

[frbitten]

When running listpeers for the peer of my channel that was closed, it returns this result.

   "peers": [
      {
         "id": "0298f6074a454a1f5345cb2a7c6f9fce206cd0bf675d177cdbf0ca7508dd28852f",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "174.169.193.33:9735"
         ],
         "features": "08a0000a0269a2",
         "channels": [
            {
               "state": "CLOSINGD_COMPLETE",
               "scratch_txid": "03f08b5562f7d04c06cb3664ceeecd31e0dee22e208782a9798f5b51aefdb326",
               "last_tx_fee_msat": 1069000,
               "feerate": {
                  "perkw": 3762,
                  "perkb": 15048
               },
               "short_channel_id": "804988x378x0",
               "direction": 1,
               "channel_id": "ec3f9d511389e5d3cb8ba6a7d96c7afba35052e3cf2953f953958ebbf43dd227",
               "funding_txid": "27d23df4bb8e9553f95329cfe35250a3fb7a6cd9a7a68bcbd3e58913519d3fec",
               "funding_outnum": 0,
               "close_to_addr": "bc1q5x5vy24y6nsppkph2wrtp7qfxg2s0r5gc2g0yv",
               "close_to": "0014a1a8c22aa4d4e010d8375386b0f8093215078e88",
               "private": false,
               "opener": "local",
               "closer": "local",
               "alias": {
                  "local": "4950307x12751919x65373"
               },
               "features": [
                  "option_static_remotekey"
               ],
               "funding": {
                  "local_funds_msat": 1400000000,
                  "remote_funds_msat": 0,
                  "pushed_msat": 0
               },
               "to_us_msat": 1400000000,
               "min_to_us_msat": 1400000000,
               "max_to_us_msat": 1400000000,
               "total_msat": 1400000000,
               "fee_base_msat": 0,
               "fee_proportional_millionths": 500,
               "dust_limit_msat": 546000,
               "max_total_htlc_in_msat": 18446744073709551615,
               "their_reserve_msat": 14000000,
               "our_reserve_msat": 14000000,
               "spendable_msat": 1377965000,
               "receivable_msat": 0,
               "minimum_htlc_in_msat": 0,
               "minimum_htlc_out_msat": 0,
               "maximum_htlc_out_msat": 1386000000,
               "their_to_self_delay": 144,
               "our_to_self_delay": 432,
               "max_accepted_htlcs": 30,
               "state_changes": [
                  {
                     "timestamp": "2023-08-27T01:40:45.369Z",
                     "old_state": "CHANNELD_AWAITING_LOCKIN",
                     "new_state": "CHANNELD_NORMAL",
                     "cause": "user",
                     "message": "Lockin complete"
                  },
                  {
                     "timestamp": "2023-09-10T14:01:24.299Z",
                     "old_state": "CHANNELD_NORMAL",
                     "new_state": "CHANNELD_SHUTTING_DOWN",
                     "cause": "user",
                     "message": "User or plugin invoked close command"
                  },
                  {
                     "timestamp": "2023-09-10T14:01:24.795Z",
                     "old_state": "CHANNELD_SHUTTING_DOWN",
                     "new_state": "CLOSINGD_SIGEXCHANGE",
                     "cause": "user",
                     "message": "Start closingd"
                  },
                  {
                     "timestamp": "2023-09-10T14:01:28.370Z",
                     "old_state": "CLOSINGD_SIGEXCHANGE",
                     "new_state": "CLOSINGD_COMPLETE",
                     "cause": "user",
                     "message": "Closing complete"
                  }
               ],
               "status": [
                  "Loaded from database"
               ],
               "in_payments_offered": 0,
               "in_offered_msat": 0,
               "in_payments_fulfilled": 0,
               "in_fulfilled_msat": 0,
               "out_payments_offered": 0,
               "out_offered_msat": 0,
               "out_payments_fulfilled": 0,
               "out_fulfilled_msat": 0,
               "htlcs": []
            }
         ]
      }
   ]
}```

[saubyk]

Hi @frbitten Is it possible to uninstall c-lightning-rest service, reboot Btcpay, and reinstall the service?

[saubyk]

Hi @frbitten Is it possible to uninstall c-lightning-rest service, reboot Btcpay, and reinstall the service?

Ignore this please. Meant to post to a different issue.

[frbitten]

@saubyk Is there anyone I know who can help with my problem with core-lightning. I posted my problem on their github but I haven't heard back yet.

ElementsProject/lightning#6692

[ShahanaFarooqui]

Closing this issue as it is fixed by CLN PR ElementsProject/lightning#6734