Transactions and Fees

Block weight is Bitcoin's accounting system for limiting block size while distinguishing transaction data from segregated witness data. Under the SegWit rules, a block can contain at most four million weight units. Data outside the witness receives four weight units per byte, while witness data receives one. The equivalent formula is three times the stripped size plus the total serialized size. Transaction virtual size, commonly expressed in virtual bytes, is its weight divided by four and rounded upward. This lets wallets compare fee rates across transactions with different structures. Weight is not simply the number of transactions or the number of coins transferred. Two transactions sending the same value may consume different space because they use different inputs, outputs, or spending conditions. Understanding weight helps explain why batching payments and selecting suitable input types can change transaction costs.

Sources: github.com · bitcoincore.org

A confirmation indicates that a transaction has been included in the blockchain history a node currently accepts. In Bitcoin, inclusion in a block gives the transaction its first confirmation, and each additional block built above it increases the count. More depth usually makes replacement of that history more difficult under proof of work, but confirmations are not a mathematical guarantee that a reorganization is impossible. A transaction seen in the mempool has not yet received a confirmation, even when a wallet displays it as pending. Different recipients may require different confirmation depths depending on transaction value, risk tolerance, and operational circumstances. There is no single waiting count that makes every payment equally safe. Users should also distinguish on-chain confirmations from an exchange's internal deposit processing, which may involve additional checks before the platform credits an account.

Sources: developer.bitcoin.org

Dust refers to very small cryptocurrency amounts, with a specific transaction-policy meaning in Bitcoin. A Bitcoin output may be considered dust when its value is too low relative to the estimated cost of spending it under a node's configured dust-relay assumptions. The threshold depends on factors such as output type and policy settings; there is no single amount that describes every output under every configuration. Dust policy should not be confused with a universal consensus prohibition on small payments. Separately, a wallet can contain outputs that are technically spendable but uneconomical at prevailing fee rates. Unsolicited tiny payments can also be used in attempts to analyze wallet activity, although receiving dust alone does not reveal a private key. Combining such outputs with other funds may create public links, making coin selection and privacy considerations relevant before spending them.

Sources: github.com · github.com

Gas is the accounting unit Ethereum uses to measure the computational and storage-related work required by transactions. Sending ETH, calling a contract, and executing a complex application can consume different amounts of gas. The transaction fee depends on gas consumed and the effective price paid per unit, rather than on the asset's transferred market value alone. A gas limit caps the amount of work a transaction is permitted to use; it should not be confused with a quoted gas price. A transaction that reverts can still consume gas for work performed, even though its attempted application-state changes do not take effect. Fees are ordinarily paid in the network's native asset, although applications may arrange payment abstractions. Bitcoin transaction fees use a different model centered on transaction size and weight, so gas is not a universal name for every blockchain's fee calculation.

Sources: ethereum.org

A mempool is a node's local collection of transactions it has accepted for possible inclusion in future blocks. There is no single globally identical Bitcoin mempool: nodes can learn about transactions at different times and apply different relay, replacement, and memory-management policies. Transactions may enter through peers or local wallet broadcasts and leave when they are confirmed, replaced, expired, or removed under the node's rules. Being present in one mempool does not guarantee propagation across the network or inclusion by a miner. Fee rates influence selection, but miners can apply their own preferences and package considerations. A transaction may also depend on another unconfirmed transaction, making their relationship important. Mempool observations are useful for estimating congestion and fees, but they describe pending local information rather than a finalized ledger or a centrally managed queue with guaranteed ordering.

Sources: bitcoincore.org · github.com

OP_RETURN is a Bitcoin Script instruction that causes script execution to fail when it is executed. An output whose locking script begins with OP_RETURN is therefore provably unspendable and can be used to carry data without creating an output that nodes must retain as spendable. Applications use such outputs for commitments, metadata, and protocol-specific messages. Any bitcoin value assigned to that unspendable output cannot later be recovered through ordinary spending. The data still occupies transaction and block space, so creating the output is not free storage. Rules governing which data-carrying transactions a node relays are policy matters and can vary by configuration or software version; historical relay limits should not be mistaken for timeless consensus rules. Bitcoin's acceptance of the underlying transaction also does not mean it validates the meaning or accuracy of every application message embedded in the output.

Sources: github.com · github.com

Replace-by-fee is a transaction replacement mechanism that can let an unconfirmed Bitcoin transaction be superseded by a conflicting transaction offering sufficient additional fees under applicable node policies. Wallets use it to increase the incentive for miners to confirm a payment when the original fee is inadequate. BIP-125 describes an opt-in signaling approach, but replacement policies can differ across implementations and software versions, so signaling should not be treated as the only possible condition everywhere. A replacement is a new transaction and can have a different transaction identifier. It must still satisfy ordinary spending authorization and validity requirements. RBF does not edit an already confirmed transaction or guarantee that the replacement will arrive first or be mined. Recipients should therefore distinguish pending transaction observations from confirmed settlement, while senders should review whether their wallet preserves the intended payment outputs during a fee adjustment.

Sources: github.com · github.com

Segregated Witness is a Bitcoin protocol upgrade that separates certain spending-authorization data into a witness structure while changing how transaction capacity is accounted for. Its design introduced block weight and new witness-program output types. For SegWit serialization, the ordinary transaction identifier excludes witness data, while a separate witness transaction identifier commits to it. This addresses important forms of transaction malleability and supports protocols that need more stable transaction references. SegWit does not remove signature checks: the witness still carries information that nodes must validate when the spending rules require it. It also does not make payments anonymous or guarantee lower fees in every situation. Costs depend on the complete transaction structure and prevailing fee rates. Native SegWit addresses use appropriate Bech32-family encodings, but compatibility depends on the witness version and the sender's software rather than on the general SegWit label alone.

Sources: github.com

Taproot is a Bitcoin upgrade that introduces a spending design combining a public-key path with optional script-based alternatives. When the key-path conditions are satisfied, an output can be spent using a Schnorr signature without revealing unused alternative scripts. When a script path is used, the spender reveals the relevant script and the proof needed to connect it to the output's commitment, rather than necessarily revealing every possible spending condition. This can improve efficiency and reduce unnecessary disclosure for suitable arrangements. Taproot does not make all Bitcoin transactions anonymous or automatically compress every complex policy into one ordinary signature; wallet and protocol design still matter. Taproot outputs use witness version one and Bech32m addresses. The upgrade should be distinguished from individual applications that use its capabilities, because a particular token protocol, wallet feature, or inscription convention can add assumptions beyond Taproot's consensus rules.

Sources: github.com · github.com

A timelock is a condition that restricts when a transaction or spending path can become valid. Bitcoin supports absolute constraints tied to a block height or time threshold and relative constraints measured from an earlier output's confirmation. These mechanisms support arrangements such as payment channels, delayed recovery paths, and refunds when another party does not complete an exchange. A timelock usually defines the earliest permitted spending point rather than automatically sending funds at a scheduled moment. Someone still needs to construct, authorize, and broadcast an appropriate transaction, and confirmation depends on mining. Blockchain time measurements also should not be treated as precise wall-clock appointments. A locked output may contain alternative spending paths with different conditions, so the full script or policy matters. Understanding which party can spend, after which trigger, and through which authorization path is essential to interpreting the protection a timelock provides.

Sources: github.com · github.com

A transaction fee is the amount paid to have a transaction processed under a blockchain's rules and fee market. For an ordinary Bitcoin transaction, it equals the total value of the inputs minus the total value assigned to outputs. Miners may claim those fees when the transaction is included in a valid block. Wallets commonly estimate an appropriate fee using transaction virtual size and a rate quoted in satoshis per virtual byte. The amount of BTC being transferred is not itself the main measure of required block space: input count, output structure, and spending conditions are important. A higher fee can improve a transaction's competitiveness but cannot promise an exact confirmation time. An exchange's withdrawal charge is also not necessarily identical to the on-chain fee it pays. Other blockchains use different mechanisms, including gas accounting, so fee terminology should be interpreted in network context.

Sources: developer.bitcoin.org · developer.bitcoin.org

A transaction identifier, commonly abbreviated TXID, is a hash-derived reference used to identify a cryptocurrency transaction. Bitcoin transactions can be looked up by TXID in a node or block explorer, and spending inputs refer to earlier outputs using the originating TXID together with an output index. A TXID is not a receiving address or a secret that authorizes spending. Its existence also does not prove confirmation, because a wallet can calculate an identifier before the transaction is mined or even broadcast. Bitcoin distinguishes the ordinary TXID from the witness transaction identifier for transactions using witness serialization. Changes to relevant transaction data can change the identifier, which matters when a wallet replaces an unconfirmed payment. When investigating a payment, verify the correct network, the actual recipient output, and its confirmation status rather than treating a pasted identifier or screenshot as complete evidence of settlement.

Sources: bitcoincore.org · github.com

An unspent transaction output is a previously created transaction output that remains available to be spent under its locking conditions. Bitcoin tracks spendable value through UTXOs rather than maintaining a conventional account balance for each address. Each output specifies an amount and spending requirements, while a later transaction consumes the complete output as an input and creates new outputs. A wallet's displayed balance generally summarizes the outputs it can identify and potentially spend, subject to confirmation, maturity, or other constraints. Selecting several small UTXOs can require more transaction data than selecting one larger output, affecting fees. Spending patterns can also reveal relationships between addresses. An output's presence in the UTXO set does not tell an observer who holds the necessary keys, and a wallet can watch an output without being able to spend it. UTXO management therefore connects accounting, transaction construction, cost, and privacy.

Sources: bitcoincore.org · developer.bitcoin.org