Analyzing Mining Pool Behavior to Address Bitcoin Core's Double Coinbase Reservation Issue

  • The small increase in the weights of the blocks among these pools suggests minor additions of transactions by miners after building a block template.

I was surprised by this. I initially looked at SBI Crypto and noticed that their max block weight of 3,993,047 WU minus the max coinbase weight of 716 WU is 3,992,331 WU. That’s 331 WU more than the soft-maximum of 3,992,000 WU I was expecting. Looking at all pools, it seems it’s quite often around that 331 number, never more though.

Pool Name max block weight max coinbase weight weight above 3,992,000 notes
Foundry USA 3993523 1192 331
Binance Pool 3993768 1440 328
MARA Pool 3994944 904 2040 block with big inscription
Luxor 3993811 1480 331
AntPool 3993918 1612 306
ViaBTC 3993612 1284 328
Poolin 3993613 1336 277
Braiins Pool 3993416 1124 292
SBI Crypto 3993047 716 331
Ultimus Pool 3993768 1440 328
BTC-com 3993781 1472 309
SpiderPool 3993616 1288 328
WhitePool 3993631 1304 327
Ocean.xyz 3990301 9272 -10971 Ocean doesn’t use the default
EMCDPool 3993428 1304 124
Pega Pool 3993018 688 330
Titan 3993020 696 324
KuCoin Pool 3993504 1316 188
Terra Pool 3993172 844 328
CleanIncentive 3993038 728 310
1THash 3993412 1084 328
NiceHash 3993148 820 328
CKPool 3993181 856 325

I’d be surprised if this is really due to ALL pools adding extra transactions AFTER they got a template from Bitcoin Core. That seems risky (why not do it with prioritizetransaction?) and I haven’t noticed this in any of the blocks processed by my miningpool-observer project.

Is there possibly more to it?

1 Like