Bitcoin full node and query server
Oct 27, 2024
View in context in the libbitcoin Slack #general mirror.
A
Antoine Poinsot02:01
So confirmability of a block is performed by querying each transaction's previous transaction(s), making sure they are confirmed (this is not printing an output out of thin air), then for each previous output making sure no spender is marked as confirmed (this is not a double spend) and marking the spend corresponding to the transaction being checked for confirmability as confirmed.
This means you can technically support pruning, but cannot reorganize past the height at which you've pruned, or i'm missing something? This would be performed by dropping all the outputs which have a spend entry which corresponds to a transaction which is marked as confirmed.
2 replies · evoskuil · last Oct 27, 2024
evoskuil02:35
We don’t perform marking. We only associate the txs of a confirmed block to their header, and the header to its height. Everything else is inferable. And yes, all of the necessary confirmable checks are performed. There is also maturity and bip30 cecks.
evoskuil04:02
As for pruning, we can definitely do it structurally, but the store is append only, so this implies a local rewrite of the store to reduce it's size (i.e. compression). I documented the queries to make sure it was possible. Inclusive of purging unconfirmed. But it's probably faster to just resync for that, and not worth it because it's so small. But really I don't see pruning as important. It's bad for the network, the storage cost for the full chain is currently like $5 and dropping (even with growth considered), it adds complexity and limits functionality, it will eventually be totally inconsequential.
Yes, no pruned node can reorg past its pruning point.