pull down to refresh

2 sats \ 4 replies \ @Scoresby OP 25 Jun \ parent \ on: Pruned node reorg UB in Core 31.0 / Knots 29.3 - how a BIP 110 split triggers it bitcoin bitdevs

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).

write
compose
146 sats \ 3 replies \ @sedited 25 Jun

It requires a reorg to a new chain tip whose last common ancestor block with the current chain tip was pruned away, yes.

reply
104 sats \ 2 replies \ @Murch 25 Jun

More concretely, given that pruning nodes keep at least the last 288 blocks, it would require a reorg of over two days.

reply
2 sats \ 1 reply \ @Scoresby OP 25 Jun

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.

reply
104 sats \ 0 replies \ @Murch 25 Jun

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

reply