Pruned nodes running knots 29.3 or core 31.0 could crash during the activation if there are enough miners on both sides (for and against BIP 110) and blocks are redownloaded in reorgs.
Chain splits where there is meaningful hash power on each side of the split pushing forward two separate tips do not sound like fun times.
In this instance, @1440000bytes demonstrates a case where pruned nodes can end up with undefined behavior when they are trying to find the most proof of work chain:
FindMostWorkChain()can insert duplicate entries intom_blocks_unlinkedon a pruned node during reorgs. When the pruned data is later redownloaded, the same block is processed twice and re-inserted intosetBlockIndexCandidateswith a mutated****nSequenceIdmutating the sort key of a livestd::setelement which is undefined behavior.
Floppy has opened PRs to fix this in both Knots and Core.
On nostr earlier today, Floppy also referenced a BitcoinTalk thread where it seems like a number of nodes crashed during BIP 16 activation.
Chaos seems like a bad outcome for Bitcoin. However, it's not like there is any way to stop people from running clients that intentionally lead to a split, so perhaps it is good that we are getting another chance to see how the network behaves in the case of a contentious chain split.
(also @1440000bytes is pretty awesome)
The Bitcoin Core PR was opened by Stratospher in April. The blog post and the Knots PR are from this month.
ah, thanks for the clarification! I didn't click through the link on floppy's blog.
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.
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).
It requires a reorg to a new chain tip whose last common ancestor block with the current chain tip was pruned away, yes.
More concretely, given that pruning nodes keep at least the last 288 blocks, it would require a reorg of over two days.
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.
I only skimmed the article, but I don’t think it made that point clearly before the recent amendment: #1514882
I wonder how much overhang on price there is due to this larp
A post bcash pump would be nice
None of the normies I know are even aware of a fork proposal.
only takes a middle eastern prince or two to move us 20k
I used to keep track of the number of times that I told myself, "My previous understanding of Bitcoin was incomplete, and now, thanks to this epiphany, I finally understand how it all fits together! Wow!"
I deliberately stopped counting at number seven, which occurred thanks to an excellent presentation that might well have gone forgotten by most conference participants who were only looking for excitement like the irresponsible disclosure that closed the festivities... the presentation memorable for me was by a physicist, about anti-fragility; and regretably I'm having trouble now finding the presenter's name.
wayback machine delivers!
the presentation was by Ricardo Perez Marco: "On Instabilities of the Bitcoin Protocol", and it was actually a sort of "How I Learned To Stop Worrying And Grok Taleb"