Litecoin Core has no fee estimate. More blocks did not fix our test

A fresh Litecoin Core node had reached 301 blocks, had no peers or pending transactions, and was no longer in initial block download. It still could not give us a fee estimate. Mining another block was not the missing ingredient in this particular test.

We then changed the wallet's fallback and local minimum settings. Three signed candidates cost 282, 141 and 1,410 litoshis, while estimatesmartfee continued to return no price. A wallet being able to construct a payment and a node having learned a fee estimate are separate facts.

Original controlled experiment: Litecoin Core 0.21.5.8, fresh Windows regtest data and valueless test coins. The published run took place on 25 October 2026 at 23:32–23:33 UTC, already 26 October in Warsaw. No mainnet payment or live fee recommendation is involved.

What happened after 101 and 301 blocks

We asked for targets of two, six and twelve blocks in both ECONOMICAL and CONSERVATIVE mode. All six calls failed to supply a feerate at each checkpoint. The response for the requested six-block estimate included:

{
  "errors": ["Insufficient data or no feerate found"],
  "blocks": 0
}

That zero describes the estimator's returned target in this response. It is not a quotation of a zero-litoshi fee or a promise of immediate confirmation.

We checked every generated block, rather than inferring emptiness from the final mempool. Each contained exactly its coinbase transaction. Later checkpoints had recent tips and matching header heights. Their recorded inputs met the pinned source's currentness conditions; the fresh height-zero checkpoint did not.

A downloaded block is not the same as an observed wait

Core's estimator tracks selected transactions entering its mempool, then records how many blocks pass before they confirm. Knowing that an old transaction appears in a downloaded block does not reconstruct when this node first saw it waiting.

In the pinned implementation, processBlock sets the first recorded height only after it counts a tracked transaction. BlockSpan remains zero if no first height exists, and MaxUsableEstimate limits the target available to the smart estimator. That explains the observed blocks: 0 without inventing a free-payment signal. Versioned estimator implementation.

Not every mempool entry qualifies. The admission gate excludes replacements, transactions re-added while bypassing normal limits, and transactions with unconfirmed parents; it also checks whether the node is current. Initial download, an old tip or header lag can matter. Our later test checkpoints rule out those particular currentness inputs, not every cause of every missing estimate on another machine. Versioned observation gates.

The wallet can still have a fallback

At both 101 and 301 blocks, our first configuration had fallback disabled. fundrawtransaction failed with RPC code -4: fee estimation had failed and fallback was disabled. Its message suggested waiting for blocks or enabling a fallback. In this deliberately transaction-free history, waiting through the additional 200 blocks had not produced an estimate.

We restarted the same disposable node with three different explicit settings. Each successful construction used one transparent SegWit input, a 1 LTC recipient output and change. We signed the candidate and ran testmempoolaccept. All three passed that local dry run; none was broadcast.

The first candidate's 282 litoshis equal 141 × 2, or 0.00000282 LTC. The low fallback did not create a 0.01-litoshi/vB payment: the required minimum raised the rate to 1. In the last case, the stronger relay minimum raised it to 10.

We deliberately set the wallet minimum to 1 litoshi/vB in every case. Copying only a fallback number while leaving other settings different need not reproduce this table. Nor does a future signature have to produce exactly the same size.

The wallet's fee-selection code distinguishes an explicit rate, estimation and fallback, then applies relevant minimums. A successful construction therefore does not prove that the statistical estimator has recovered. It remained unavailable in every configuration above.

Keep the relay floor and a confirmation estimate separate

getmempoolinfo returned minrelaytxfee and mempoolminfee matching the configured floor at our quiet checkpoints. These describe local admission context. They do not reserve a place in a miner's block or establish a network-wide fee schedule.

A mempool under pressure can also have a rolling minimum. We did not fill this mempool, force evictions or measure that dynamic behavior. The stronger-floor row tests an explicit relay setting, not simulated congestion. The mempool guide explains the broader transaction states.

The estimatesmartfee feerate result and the minrelaytxfee and mempoolminfee fields discussed here use LTC per 1,000 virtual bytes in this tested version. Other RPC options can use different units; check help for the exact command and field. Our 0.00002000 LTC/kB setting converts to 0.00002000 × 100,000,000 ÷ 1,000 = 2 litoshis/vB. Keep units attached to copied values; the general fee guide covers the arithmetic and service charges.

A restart and a fresh data directory are different cases

A normal restart need not discard useful fee history. The pinned startup code attempts to read fee_estimates.dat from the node's data directory, and shutdown writes estimator state there. A first startup can legitimately have no such file. Our fallback comparisons reused the disposable data directory; we did not delete that file between configurations. They do not show that restarting a healthy production node destroys its estimates. Startup and shutdown implementation.

Similarly, recovering a wallet on a different node and recovering that node's previous fee observations are separate tasks. Keys, a transaction history and a current chain tip do not by themselves identify the source of a displayed price. When comparing two applications, record which node or service supplied each estimate, its time, target and units. A quote from another service can be useful context without becoming this Core instance's own statistical result.

A useful diagnostic sequence on your own node

Use the CLI and configuration belonging to the intended node and network. These examples inspect information; they do not send a payment or change fees:

litecoin-cli getnetworkinfo
litecoin-cli getblockchaininfo
litecoin-cli help estimatesmartfee
litecoin-cli estimatesmartfee 6 "CONSERVATIVE"
litecoin-cli getmempoolinfo

First record the software version, network, active and header heights, initial-download flag and recent tip time. Then retain the complete estimate response, requested target and mode. A screenshot of only a blank price hides the error that explains why a wallet made a different choice.

Next identify the wallet's actual pricing path: estimate, explicit rate or fallback. Review the final recipient amount, change and total fee before authorizing anything. An exchange's withdrawal charge is a separate provider quote; a Core error does not tell you what that provider will charge.

The blank diagnostic checklist keeps these checks together. Do not include a seed, private key, wallet file or RPC cookie in a support request. If a payment was already submitted, diagnose that transaction rather than creating a second payment to test a new setting.

What an application should do with a missing quote

Treat an absent feerate as a missing value. A conversion routine that silently substitutes zero can turn a clear estimator failure into a misleading fee preview. Checking that the RPC request returned JSON is insufficient; the application must inspect the result fields.

If a product uses a configured fallback, label that origin and retain its units and observation context. Do not describe it as the current network estimate. A minimum relay rate is likewise a policy boundary, not evidence that a chosen confirmation target will be met.

For an operator, allowing the node to gather useful current observations may be the right response. Changing a wallet fallback is a separate policy decision. This article supplies no production rate to paste into a configuration and makes no claim that opening RPC access would improve the estimate.

Inspect or reproduce the evidence

The public package contains checkpoints, candidates and 55 experiment assertions, the RPC transcript, 301 block records and a compact configuration-and-fee CSV. An earlier fresh-chain repeat matched the block count and three fees; that is an internal repetition, not an external review.

The reproduction script creates its own empty regtest directory and wallet, disables peer connections and stops only its own process. It accepts binary paths, never an existing wallet or data directory. No candidate leaves the isolated node.

A separate verifier reconstructs ordinary transaction IDs, virtual sizes and input-minus-output fees from exported bytes. It checks arithmetic and consistency, not signatures or an independent execution attestation. See the method and limits, pinned source record and package checksums. Research, scripting and drafting used AI assistance.