Bitcoin block 974961: 11,255 transactions, $180 fees

AntPool collected about $180 in fees from 11,255 transactions in Bitcoin block 974961, CoinDesk reports, citing mempool.space. It was the network’s second-busiest block by transaction count. Nearly all of the miner’s payout still came from the subsidy. Relay-policy floors do not determine which transactions are valid in a block.

A Bitcoin payment service cannot take this as a reason to promise exceptionally cheap transactions. Nor can a mining operator take the high transaction count as evidence of substantial fee income. Both readings run into the same block: it contained plenty of inexpensive transactions, while the miner’s payout remained heavily dependent on the subsidy.

What Bitcoin block 974961 reveals about fees

The near-record belongs to the transaction count, not the fee revenue. In its November 9 report, CoinDesk says AntPool mined the block on Saturday. It fell 984 transactions short of F2Pool’s record block 367,853, mined on August 1, 2015.

Here is how the two blocks compare, following BigGo’s block comparison. Its headline figures agree with CoinDesk’s reporting, but the bitcoin and dollar fee amounts need to be read separately.

The dollar figures depend on the price used. CoinDesk values the recent block’s fees at Sunday’s bitcoin price of nearly $75,800. By its calculation, the older block collected about 94 times as much bitcoin in fees, even though those fees were worth fewer dollars at the time. A satoshi is one hundred-millionth of a bitcoin, so the unit matters as much as the dollar conversion in this comparison.

CoinDesk puts AntPool’s total payout at about $237,000, almost all of it from the subsidy.

There was another densely populated, low-fee AntPool block that week. CoinDesk identifies block 974,557, mined on November 4, with 10,573 transactions and about $110 in fees. It does not, by itself, establish a longer-term trend.

Why could one-satoshi transactions enter this block?

CoinDesk’s sample contained very small, very cheap transactions. That is a narrower finding than saying every transaction in the block looked the same. In the middle of the block, its review found a run of 80-byte transactions, each paying a single satoshi and carrying a small data output.

Bitcoin users bid for block space with a fee rate per virtual byte. The virtual byte is the unit used to measure how much room a transaction takes, which is why total fee and fee rate are different measurements. A one-satoshi fee tells you how much was paid. To get the rate, that payment has to be related to the transaction’s virtual size.

For Bitcoin block 974961, mempool.space rounded the median fee rate to zero, according to CoinDesk. A rounded median of zero does not mean the block collected no fees. I think that distinction is easy to lose in the displayed number: the reported total was positive, and each of the sampled transactions paid a satoshi.

A PANews report carried by KuCoin, citing Bitcoin.com News, puts utilization at nearly 99.85% of the block-weight limit. So even a block close to that limit need not collect substantial fees. Transaction count tells us how many transactions were included; weight utilization and fee revenue describe different aspects of that same block. None of those measurements can simply replace the others.

Bitcoin Core’s relay floor is not a validity rule

According to CoinDesk, the sampled rate was below Bitcoin Core 29.1’s default relay floor. The block was not invalid as a result. That floor is node policy, not a network validity rule, and I think this is the detail to keep in view before treating the block as a contradiction.

The Bitcoin Core 29.1 release notes document a minimum block fee rate separately from the relay-related defaults. The table uses the project’s own units for those policy settings and their defaults; they are not all the same threshold.

As CoinDesk describes it, the default minimum relay rate works out to one-tenth of a satoshi per virtual byte. The minimum block fee rate is separate. That separation matters because this release does not apply one shared fee threshold to every part of transaction handling.

This has a direct consequence for an operator reading the block data. Your local relay-policy setting does not declare that every valid block must exclude cheaper transactions. The reverse does not follow either: seeing a cheap transaction in a valid block tells you nothing conclusive about whether your own node would relay it with its current settings.

Bitcoin Core says these defaults are still configurable. If you decide to change the minimum and incremental relay settings, the project recommends changing both together. Having the configuration options available is not, on its own, advice to lower them for every workload. That decision is separate from observing what AntPool included.

Review Bitcoin Core fee settings before lowering wallet fees

For a production payment service, I’d review the settings governing its own workflow before copying the exceptional fees in this block. Asking whether a cheap transaction has ever confirmed is not enough. The useful question is which policy applies at each stage of the service’s transaction handling, including the wallet that creates the transaction.

1. Separate wallet fees from relay defaults. Bitcoin Core says the wallet’s fee rates remained unchanged in 29.1. The release notes specifically say that -mintxfee must be changed before attempting to create lower-fee transactions using the wallet. A lower relay default does not automatically change the wallet’s transaction fees, so do not treat those two settings as interchangeable.

2. Review -minrelaytxfee and -incrementalrelayfee as a pair. Where your deployment overrides either setting, compare the actual overrides with the documented defaults and with the project’s recommendation to change them together.

3. If you operate block-building infrastructure, give -blockmintxfee its own review. Bitcoin Core documents this as the minimum block fee rate, separate from the relay-related settings. Keep that separation explicit in configuration reviews. Referring only to an unspecified minimum fee leaves out which part of transaction handling the setting governs.

4. Check the assumptions behind any lower-fee rollout. Bitcoin Core warns that transactions using lower fee rates are not guaranteed to propagate or confirm unless the lower defaults are widely adopted across the network. That warning constrains what the service can offer. This block does not provide an assurance that those transactions will propagate or confirm.

Other minimum fee rates remained unchanged, according to the release notes, including the dust fee rate and the minimum returned by the fee estimator. The mempool minimum fee rate also still responds to high volume. A review limited to the newly lowered defaults would miss policies that the project explicitly says continue to apply to transaction handling.

AntPool’s transaction intake remains unexplained

CoinDesk says the public data does not show how these transactions reached AntPool. That leaves an operational question unanswered. We can see that the miner included them, but the reporting does not establish a delivery route that another operator could reproduce for similarly priced transactions.

The proposed explanation for the transaction mix needs attribution too. BigGo, citing market reports, connects the high transaction count to small data payloads associated with Runes, a protocol for issuing and transferring fungible assets on Bitcoin. CoinDesk directly describes something narrower: it observed small data outputs in a sample of transactions, not a characterization of every transaction in the block.

I’d keep the Runes explanation provisional instead of labelling every transaction in the block a Runes transfer. The measured fees support a firmer conclusion without needing that attribution: in this instance, a high transaction count did not produce high fee revenue.

Bitcoin block 974961 shows what a miner included. It does not provide a general recipe for getting similarly priced transactions delivered to a miner. If you neither operate Bitcoin infrastructure nor make wallet fee-policy decisions, there is no configuration change for you to make on the strength of this report.

The projected 2028 subsidy cut is the harder comparison

Put the fee total beside the subsidy miners are projected to lose, and the comparison gets harder. CoinDesk reports that the subsidy will halve to 1.5625 BTC at block 1,050,000, projected for around April 2028. The timing is still a projection; this is not a subsidy change that has already happened.

In CoinDesk’s comparison, the fees from this block would replace less than two-tenths of 1% of the subsidy removed at that halving. The transaction count was close to a record, but the fee income did not come close to filling that prospective revenue gap.

The reported mining environment is tight as well. Citing Hashrate Index, CoinDesk puts earnings at about $32 per petahash per day. That number describes the mining backdrop in the report. It does not make this individual block a forecast of future mining profitability, any more than its transaction count supplies a fee-revenue forecast.

Use this block to improve fee-and-subsidy reporting rather than promise one-satoshi payments. Keep the measurements separate in that work: node operators need to review the distinct policy settings, while mining operators need to assess fee income directly instead of letting a near-record transaction count stand in for revenue. For a node configuration review, start with the wallet fee setting, the paired relay settings and the separate minimum block fee rate—not the explorer’s rounded median.