My node presently studies:
$ bitcoin-cli getblockchaininfo
{
"chain": "important",
"blocks": 873668,
"headers": 873668,
"bestblockhash": "00000000000000000001b0251f80ba44e47217f661a06628f48eb71d659ce0eb",
"problem": 103919634711492.2,
"time": 1733586184,
"mediantime": 1733584532,
"verificationprogress": 0.9999971534840028,
"initialblockdownload": false,
"chainwork": "00000000000000000000000000000000000000009ef4d8bff5438c3689882eee",
"size_on_disk": 706175424632,
"pruned": false
}
size_on_disk “accounts for block information and undo knowledge, and never for chainstate or any indexes you’ll have enabled on the block knowledge” (H/T Pieter Wuille in feedback). This consists of stale blocks and invalid blocks the node might have downloaded and validated. 706,175,424,632 bytes translate to about 657.68 GiB. Solely the block knowledge of one of the best chain ought to even be a bit of smaller, so 620 GiB may match that.
I don’t know the way bitinfocharts.com will get solely 490 GiB. They have to be utilizing a unique methodology. Maybe they’re offering a sum of the overall serialized block knowledge as an alternative of the dimensions of a node’s block information, however that’s only a guess.
Out of your supply at Statista.com:
Bitcoin’s blockchain dimension was near reaching 5450 gigabytes in 2024, because the database noticed exponential development by practically one gigabyte each few days.
I do not know how Statista arrived at “5450 gigabytes”, and the blockchain doesn’t develop exponentially, it’s rising linearly at not more than 4 GiB per week. It may briefly develop quicker if the hashrate instantly will increase, however the problem adjustment would rapidly appropriate that.
