pull down to refresh
I added this in the end. Let me know if I missed something or looks incorrect.
Ah, so the reorg would have to extend beyond the pruning point of a pruned node. So for instance, if I have it set to 2GB, for this to be an issue, there would have to be a reorg that extends beyond 2 GB of block data?
I did not quite understand that from his piece.
(I did add a tone of attribution to floppy in my post about it, but his original newsletter article is not clear that this is not his own original research).
I wonder how many users run pruned nodes at the absolute minimum. I checked the default suggested pruning size again
I believe floppy's article (and my summary of it) could have benefited from a clear statement that this requires a reorg of depth greater than pruning. Likely though this is mostly caused by my misunderstanding of his article.
Right, it would likely need to be even deeper to affect nodes, but the reorg would need to be at least 288 blocks.
Likely though this is mostly caused by my misunderstanding of his article.
I only skimmed the article, but I don’t think it made that point clearly before the recent amendment: #1514882
He really could have properly cited that work. A reorg that deep is unlikely even in a deep chain split scenario. The default buffer of non-pruned data offers good protection. Section 11 of the whitepaper explains chain splits and why it is very difficult to catch up comprehensively and is a good antidote to people fudding this topic over the past half year.