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

Yes :man_facepalming:, there is more to it. Especially to a serialized block…

  • the header is 80 bytes, accounting for 320 WU
  • usually, a 3 byte var_int for the number of transactions accounting for 12 WU (if a 1 byte var_int is enough, this is 4 WU)

This leaves us with 332 WU. As we check that the package weight is NOT >= 3,992,000 (i.e. we check that < 3,992,000), we actually have a soft-maximum of 3,991,999 WU.

This allows looking at how close the pools came to actually fill the block: Seems like Foundry, SBI Crypto, Braiins, and Luxor had 0 WU left in their blocks. This also indicates that all listed pools are currently using the default -blockmaxweight=3999000.

Pool Name max block weight max coinbase weight min WU left to fill
Foundry USA 3993523 1192 0
Binance Pool 3993768 1440 3
Luxor 3993811 1480 0
AntPool 3993918 1612 25
ViaBTC 3993612 1284 3
Poolin 3993613 1336 54
Braiins Pool 3993416 1124 39
SBI Crypto 3993047 716 0
Ultimus Pool 3993768 1440 3
BTC-com 3993781 1472 22
SpiderPool 3993616 1288 3
WhitePool 3993631 1304 4
EMCDPool 3993428 1304 207
Pega Pool 3993018 688 1
Titan 3993020 696 7
KuCoin Pool 3993504 1316 143
Terra Pool 3993172 844 3
CleanIncentive 3993038 728 21
1THash 3993412 1084 3
NiceHash 3993148 820 3
CKPool 3993181 856 6

This is probably incorrect then.

3 Likes