3

Is there a research, BIP proposal or simple discussion about possible improvement on the size required to run a full node and a way to shrink/prune the history of bitcoin and have fast sync?

Let me try to narrow a bit the topic: would be interesting to have a way to have fast node sync, with few memory required to store an updated "fullnode".

I was thinking if may be useful to have a kind of UTXO snapshot periodically (let say every 2016 blocks) where a node would generate a UTXO snapshot and put the hash (a merkle tree hash or whatever struct fits well) in the block header

having this, nodes may do a lot of different kind of sync based on their needs, e.g. they may validate "header first" by using these "snapshot headers", require a specific snapshot using something similar to "assumevalid" without the need to validate all prior transactions nor having to download blocks, because the utxo set is all what they need to validate next blocks on top of the snapshot height. Of course such nodes can't serve old blocks, similar to how pruned node ares, but they can validate and sync fast.

Of course my thought isn't indeep this is why I'm wondering what's current state about this topic because I'm quite sure it's something that periodically pops out.

Beside this, I've a more broader question, that may sound a bit rhetorical but still legit: is bitcoin history that important? Having snapshots (as consensus, every node has to generate it at the same height, its hash has to be stored on block header, etc...) could theoretically cause the block containing the snapshot act as a new genesis that move bitcoin ahead An utxo that's spent, isn't useful anymore like a transaction that have all its utxo spent, so removing them shouldn't cause any harm except probably transactions using OP_RETURN but they may be stored in another kind of "DATA Snapshot".

I can't think about a valid reason (except of course for initial sync) that makes the full history of bitcoin needed to be stored and served, did I miss something?

this kind of "dynamic genesis" still would allow a node that chose to store the whole chain compatible with a node that want to start from last snapshot, everyone can validate and serve blocks (of course the latter could serve only from snapshot genesis). It's kind of similar to what we have with checkpoint with the difference that's set in consensus and not hardcoded in code (that's one of the reason why checkpoint failed)

Open to criticisms that add something to the discussion.

3
  • Search for the assumeutxo project. You don't want to trust a UTXO snapshot just because a miner included it in a block (miners behave honestly because nodes verify their blocks - trusting a claimed UTXO would invert that relation), but with sufficient eyes - similar to those already needed for full node software review - it's a completely reasonable thing to not let everyone completely validate all of history. – Pieter Wuille Jul 12 '20 at 23:54
  • Besides that, this seems more of a discussion topic than a topic suitable for a Q&A site. – Pieter Wuille Jul 12 '20 at 23:56
  • do you mean this could be posted on bitcoin ML? anyway if these snapshots are generated every XX blocks (in my example the difficult retarget window) every miner will have to include the utxo snapshot hash in the block and whoever want to generate a fake one, has to generate it with an higher chainwork that in any case can be rolled back if another chain prove to have more work. So it should be safe to sync starting from second last utxo snapshot (so from TIP height - (snapshot timeframe + 1, 2017 in this example) Will take a look at your referenced project, thanks – Not Important Jul 13 '20 at 20:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.