cln using floor/min_acceptable feerate to claim funds after fc timelock

[daywalker90]

I had 2 fc in the recent past where i noticed that the tx after the fc timelock had a very low feerate, don't know if this is intentional or not.

{
   "perkb": {
      "opening": 6460,
      "mutual_close": 6212,
      "unilateral_close": 12988,
      "unilateral_anchor_close": 6212,
      "penalty": 6460,
      "delayed_to_us": 6460,
      "htlc_resolution": 12988,
      "min_acceptable": 4744,
      "max_acceptable": 137640,
      "floor": 4744,
      "estimates": [
         {
            "blockcount": 2,
            "feerate": 13764,
            "smoothed_feerate": 13764
         },
         {
            "blockcount": 6,
            "feerate": 12988,
            "smoothed_feerate": 12988
         },
         {
            "blockcount": 12,
            "feerate": 6460,
            "smoothed_feerate": 6460
         },
         {
            "blockcount": 100,
            "feerate": 6212,
            "smoothed_feerate": 6212
         }
      ]
   },
   "onchain_fee_estimates": {
      "opening_channel_satoshis": 1133,
      "mutual_close_satoshis": 1045,
      "unilateral_close_satoshis": 1941,
      "unilateral_close_nonanchor_satoshis": 1941,
      "htlc_timeout_satoshis": 2152,
      "htlc_success_satoshis": 2282
   }
}

This is the feerates perkb 2 hours after the tx was submitted with 4620perkb.

Btw it would be nice to have documentation on all the RBF and CPFP possibilities available to cln node runners. For example in this case, cln pretends to not know the utxo if i try to use it in withdraw. Do i really have to use https://github.com/jb55/clightning-dumpkeys import them to bitcoin-cli, do a rescan and then do the tx there? It would be way cooler if cln stopped pretending to not know the utxo it just tried to spend with a low feerate and rather cln let me use withdraw or something to bump the fee or even better fundchannel with minconf=0 :)

[daywalker90]

It does get autobumped after some time but starting at the floor.

[rustyrussell]

Yes, if we're just returning funds to our wallet, with no specific timeout requirement, we aim for "300 blocks from close". Since our fee estimates only reach to 100 blocks, we use the following:

    /* Over 200 blocks, we *always* use min fee! */
    if (blocks > 200)
        return FEERATE_FLOOR;
    /* Over 100 blocks, use min fee bitcoind will accept */
    if (blocks > 100)
        return get_feerate_floor(topo);

It's... kinda dumb! We have internal logic to rbf, which we could expose?

[daywalker90]

I mean it could be a little smarter if theres a full mempool the odds to confirm at FEERATE_FLOOR are quite low.

It would be helpful to communicate to the user what cln can and cannot do with pending txs (E.g. in the listpeerchannels status.) : When it's autobumping and when it must wait for the feerate to confirm etc.

Alot of questions in the telegram group are "how do i bump fee" and in some cases cln does it automatically and some are impossible to bump.

As to exposing the logic itself, i don't know.

[daywalker90]

Right now i have a tx in the mempool that is not getting fee bumped by cln since 2 weeks: c4eae2c851b0c51adcbb002e80246828447591704a05c9be61cec75d78323e9d listpeerchannels state is still in "ONCHAIN:5 outputs unresolved: waiting confirmation that we spent OUR_HTLC (cd988a9d19377b97efd2c7a01ea4508eb4d56d41ebd47b81334172ca2c12d955:1) using OUR_HTLC_TIMEOUT_TX"

I tried to use jb55's tool https://github.com/jb55/clightning-dumpkeys to import the extended private key descriptor into bitcoind, but i only have like 12 utxos there, while cln's onchain wallet has 30+. And a bitcoin-cli gettransaction does not find the txs from link above.