Posted by ismaelsadeeq
Mar 13, 2025/10:58 UTC
The process of managing transaction fees in a blockchain network involves a linear fee function that starts with a minimal fee and escalates to allocate the entire budget for fees as the deadline for confirmation approaches. Initially, a batched transaction is sent out, followed by continuous monitoring through a "fee bumper" which increases the fee with each unconfirmed block based on the predetermined fee function. This mechanism aims to adjust the transaction fee dynamically to ensure timely confirmation.
A common issue arises when nodes use the long-term fee estimator designed for transactions expected to confirm after more than two blocks (conf_target > 2
) but require the transaction to be confirmed as soon as possible. The estimateSmartFee
function, when used with a target of n
blocks, is designed to estimate fees for a confirmation within n
blocks rather than immediate confirmation in the next block. For transactions needing urgent confirmation before n
blocks are processed, setting this parameter to 1 could lead to faster confirmation if the subsequent blocks do not confirm the transaction, allowing for an adjustment in the fee rate according to the budget and urgency reflected in the fee curve.
Furthermore, there's an ongoing discussion about improving Bitcoin Core's fee estimation through an API proposal that provides historical mempool data, giving clients insight into past states of the mempool and miner behavior. This enhancement could enable more strategic decisions regarding fee rates and confirmation timelines. The proposal, detailed in a GitHub issue (see here), suggests how such data might improve the accuracy and reliability of fee estimations, potentially benefiting users with time-sensitive transactions.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback