Quote from: o_e_l_e_o on February 04, 2023, 04:33:35 PM

They are not that rare ... a chain reorg is a fork.

Sure, the terms are fuzzy. In this case, I contrasted forks with local chain reorgs. YMMV, but I know of only 6 global and sustained forks (excluding XT, BTH, Gold etc): 2010 (overflow bug), 2013 (db migration fix), 2015 (DER encoding), 2017 (Segwit), 2018 (double spending fix), 2021 (Taproot). Few and big enough that I would advocate revalidation, pruned node or not.

The "other kind" of reorgs, where blocks get orphaned because two or more blocks are mined almost at the same time, has as far as I can tell not occurred since 2019. It used to be much more frequent and might increase again (if f.x. inter-miner latency went up again), but with reasonable pruning parameters, this shouldn't affect a pruned node specifically, as far as I can tell; as soon as a new block is mined (from either chain), the tie is broken (in all likelyhood).

Quote from: o_e_l_e_o on February 04, 2023, 04:33:35 PM

This changes if we adopt blocks which are gigabytes in size. The scam coin BSV, for example, experiences frequent chain splits, some over 100 blocks long.

I take it you don't share the Satoshi Vision Wink

I think BSV has a max block size of 128 MB, and if we change BCT rules to allow gigabyte blocks, my current viewpoints may indeed be invalidated. I still fail, however, to grasp why a larger block size would cause orphans more frequently, let alone in chains of more than a hundred blocks at a time - how could a larger block size stop nodes from receiving any and all blocks from a competing chain in more than a thousand minutes? Especially since the competing chain actually worked harder for 625+ coins (if not, no split and no issue)?

Quote from: o_e_l_e_o on February 04, 2023, 04:33:35 PM

And verifying from scratch every time when their blockchain is over 8 TB in size is no small task if your node is pruned and you have to redownload from scratch.

Precisely! That a gigantic blockchain is no small task is the point of this thread

I'm suggesting that maybe pruned nodes, in combination with cheap, slow, non-transactional storage of pruned-away data, might help alleviating part of the consequences.