Calculators and models
with explained assumptions.

Use a dot or comma as the decimal separator; separate thousands with a space.

DCA, or Dollar-cost averaging, means buying for a fixed amount of local currency at regular intervals instead of seeking a single ideal moment. It reduces the need to decide on timing and may curb emotional trading, but it guarantees no profit, prevents no loss and does not solve custody.

For each modeled purchase, divide the amount by the historical price. Adding these fractions gives the BTC total, valued at the last price in the series used. Contributions equal amount times purchase count; percentage change is (value / contributions − 1) × 100. This is not an annualized return.

A year here means 365 days. The first purchase uses the first available observation. The weekly model selects the next observation at least seven days after the previous purchase; the monthly model selects the first observation of each UTC month, including partial months at either end. The displayed count may therefore differ from 52 or 12 per year.

We use CoinGecko, with Yahoo Finance as a fallback. For non-USD currencies, the Yahoo model may combine BTC/USD with the latest USD exchange rate at or before the observation for that currency, up to seven days old. Data may be cached. The series must start and end within seven days of the requested boundaries and have no gaps longer than eight days; otherwise no result is issued. Actual endpoint dates and source are shown.

The model excludes spreads, fees, taxes and custody costs. It calculates mathematical BTC fractions; display is rounded and actual purchases in whole satoshis may differ. This is a historical calculation, not a forecast or instruction to buy.

DCA spreads purchases over time, but does not make bitcoin a risk-free investment or guarantee returns.

Use a dot or comma as the decimal separator; separate thousands with a space.

Enter an integer input count of 1–500 and rates of 0–1 000 000 sat/vB. Empty or invalid fields hide the result.

Net difference = fee without consolidation − the sum of both fees with consolidation. Positive means modeled savings; negative means higher costs. With one input, no inputs are being combined.

Both scenarios assume spending all selected UTXOs together in one later transaction. Consolidation joins them into one output today. Every modeled transaction has exactly one output of the same type as its inputs; no additional change output is included.

Virtual size is the whole transaction weight divided by 4, rounded up. CompactSize counters and the witness marker/flag are included. Each fee is vB size times the applicable rate, rounded up to a whole satoshi.

We assume compressed public keys and 72-byte ECDSA signatures including sighash. P2SH means only P2SH-P2WPKH here. Taproot uses key path, a 64-byte signature with default sighash and no annex; script path and multisig are outside the model.

You supply the rates; they are neither live estimates nor confirmation guarantees. Zero and the upper bound are model limits, not network rules. UTXO values are unknown: funds, dust and wallet acceptance are not checked. Actual signatures and construction can change the size.

Combining inputs may link their ownership for an observer and reduce privacy. A positive fee difference alone is not a recommendation to consolidate.

The calculation runs in your browser without requesting network data. This tool does not create or broadcast a transaction and needs no address or keys.

Use a dot or comma as the decimal separator; separate thousands with a space.

Enter an integer height of 0–6 930 000. Empty or invalid input hides the result.

Loading…

Source of loaded height: —

Network response assembly time (UTC): —

Last response (UTC): —

Bitcoin’s supply is limited because a valid block may create new units only according to a declining block subsidy schedule. Every fully validating node checks this rule independently. The familiar 21 million is the rounded result of this schedule, not a number stored in one company’s database.

A miner may include a coinbase transaction in a valid block. Its total outputs may not exceed the issuance subsidy allowed at that block height plus transaction fees. Fees transfer existing bitcoin; only the subsidy creates new units. A block with an excessive coinbase reward is invalid.

On mainnet the subsidy starts at 50 BTC and halves every 210 000 blocks, truncating to whole satoshis. The last nonzero block is at height 6 929 999; from 6 930 000 the subsidy is zero. Remaining issuance uses the exact theoretical total, not the rounded 21 million.

The sum includes every permitted subsidy from height 0 through the selected block. It is neither circulating nor spendable supply: it includes the genesis block’s unspendable 50 BTC and does not subtract unclaimed subsidies or lost coins. Fees are not new issuance.

We project a date only for the loaded height: response assembly time plus remaining blocks times 10 minutes. It is neither a block’s mining time nor a fixed deadline. Data from mempool.space or fallback Blockchain.com may be cached; actual block intervals vary.

Use a dot or comma as the decimal separator; separate thousands with a space.

Enter integer counts: inputs 1–500, outputs 1–50; rate 0–1 000 000 sat/vB. Empty or invalid fields hide results.

Reference rate per 1 BTC: Loading…

Source not provided · Last response: —

All inputs and outputs use the selected type. Include recipient and change outputs in the output count; the tool adds no extra output automatically. Mixed types and other scripts are outside this model.

Virtual size is the whole transaction weight divided by 4, rounded up. CompactSize counters and the witness marker/flag are included. Each fee is vB size times the applicable rate, rounded up to a whole satoshi.

We assume compressed public keys and 72-byte ECDSA signatures including sighash. P2SH means only P2SH-P2WPKH here. Taproot uses key path, a 64-byte signature with default sighash and no annex; script path and multisig are outside the model.

You supply the rates; they are neither live estimates nor confirmation guarantees. Zero and the upper bound are model limits, not network rules. UTXO values are unknown: funds, dust and wallet acceptance are not checked. Actual signatures and construction can change the size.

Fee value in currency = fee in satoshis / 100 000 000 × reference price per BTC. The market price changes neither your entered sat/vB rate nor the satoshi fee.

Currency conversion is indicative: the rate may be cached and excludes spreads, fees and actual trade execution prices. Results use the currency’s decimal places; rounded display does not replace precise settlement accounting. Use the button to reload the rate. The time means receipt of the response, not the price measurement time.

Use a dot or comma as the decimal separator; separate thousands with a space.

Enter finite nonnegative numbers; pool fee 0–100%. Device hashrate must not exceed the loaded network hashrate. Invalid values hide the result; a blank electricity price does not mean zero cost.

The default electricity price is only a model input. We retain it in the currency of its last manual edit and convert it to other currencies using available reference rates. Without rates the field stays blank until you enter a price. This is not a supplier quote.

Loading…

Estimated network hashrate: —

Loaded block height: —

Block subsidy used: —

Reference rate per 1 BTC: — · Source not provided

Last response: —

1 TH/s = 10¹² H/s. Device share of network hashrate is multiplied by 144 blocks per day, the loaded subsidy and (1 − pool fee / 100). Energy = W / 1 000 × 24 hours. Difference = expected BTC value − electricity; 30 days is thirty times that same day.

We assume continuous operation, a 10-minute average block interval and unchanged inputs. Transaction-fee income, hardware, depreciation, extra cooling, taxes and downtime are excluded. Payouts and variance depend on the pool; a mathematical expectation is neither a payout promise nor full net profit. Displays are rounded and expectations may contain fractional satoshis.

Network hashrate is inferred from blocks, not directly measured across every device. It may come from mempool.space or Blockchain.com with different windows; the height source is shown separately. Data and prices may be cached. Response time is not the measurement time of every metric.

Currency conversion is indicative: the rate may be cached and excludes spreads, fees and actual trade execution prices. Results use the currency’s decimal places; rounded display does not replace precise settlement accounting. Use the button to reload the rate. The time means receipt of the response, not the price measurement time.

A miner seeks a header hash that does not exceed the target. Valid proof of work is insufficient if the rest of the block breaks the rules. The template creator selects transactions. In a pool the operator often performs this role; the owner of hashing equipment may not control selection. Mining consumes electricity and hardware. Rewards include new issuance and fees; revenue is not profit, and pool payouts depend on the pool's terms.

Sliders: n from 2 to 7, m from 1 to n and L from 0 to n. Reducing n also reduces m and L to n if needed. These are simulator bounds, not a general Bitcoin limit; m = 1 shows a single-signature threshold.

Available keys A = n − L. The threshold is met when A ≥ m; further margin is max(0, A − m) and the shortfall is max(0, m − A). Keys are assumed distinct and all available holders willing and able to sign. Another backup copy of the same key does not add an independent signature.

Example 2 of 3: with no loss the margin is 1 key; with 1 unavailable key the threshold is still met but the margin is 0; with 2 unavailable keys, 1 signature is missing. Unavailability may be temporary; it does not automatically mean permanent loss of funds.

Recovery also needs the correct wallet configuration: threshold, every participant’s public keys, their order or sorting rule, script type and any derivation paths. An Output Descriptor can capture this information. Enough private keys alone may not restore addresses; public configuration does not replace signatures.

The model excludes stolen keys, shared points of failure, additional script conditions and wallet compatibility. Signature availability does not mean protection from theft. No real keys are entered; the simulator creates no wallet, signs or broadcasts no transactions and needs no live data.