Bootstrapping the pruned blockchain

[Come-from-Beyond]

Imagine that the blockchain is pruned. How a lesser (non-full) node can validate unspent outputs in case when other nodes send contradictory data? Will the merkle root of these data be added into blockchain headers?

[1715332246]

1715332246

[Mike Hearn]

What do you mean by "non full". Pruning or not makes no difference to the fullness of a node. All the rules are still being checked. Pruning just means you throw away old data that other nodes would need to bootstrap themselves from zero.

In theory as long as someone somewhere is serving a non-pruned copy of the chain, there's no difference to the security of the system even if everyone else prunes. Of course that wouldn't be a very stable situation but I'm using the extreme case as an illustration.

[Come-from-Beyond]

Non-full = have no data about spent outputs.

Maybe I'm wrong and lesser nodes r supposed to load ALL transactions history? Otherwise I see no way to validate outputs.

[CIYAM]

Pruning is only for *spent* outputs is it not?

[Come-from-Beyond]

Pruning is only for *spent* outputs is it not?

Yes, but if u get rid of transactions of these spent outputs, then u can't check proof-of-work coz it contains ALL data.

[jgarzik]

Pruning is only for *spent* outputs is it not?

Yes, but if u get rid of transactions of these spent outputs, then u can't check proof-of-work coz it contains ALL data.

The proof-of-work is in the block header.  You can still check proof of work via the block header and merkle tree.

[Come-from-Beyond]

The proof-of-work is in the block header.  You can still check proof of work via the block header and merkle tree.

What exactly should I do if node A sent "XXX owns 10 BTC", but node B sent "XXX owns 5 BTC"?

EDIT: I can check proof-of-work of blockchain headers. Now I need to make sure how many coins XXX has.

[prezbo]

The proof-of-work is in the block header.  You can still check proof of work via the block header and merkle tree.

What exactly should I do if node A sent "XXX owns 10 BTC", but node B sent "XXX owns 5 BTC"?

EDIT: I can check proof-of-work of blockchain headers. Now I need to make sure how many coins XXX has.

You can always check the amount of btc XXX has by checking all unspent outputs. Those are still there after pruning. Spent outputs not being there won't affect the total amount of btc XXX has.

[Come-from-Beyond]

You can always check the amount of btc XXX has by checking all unspent outputs. Those are still there after pruning. Spent outputs not being there won't affect the total amount of btc XXX has.

Yes, I understand this, but...

Alice says that unspent output of XXX is 10 BTC.
Bob says that unspent output of XXX is 5 BTC.

Whom should I believe?

[CIYAM]

You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?

[Come-from-Beyond]

You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?

And what should I do if I've just launched bootstrapping? Pray that I get non-tampered data?

[prezbo]

You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?

This. If you wan't this information by not checking it yourself, there will always have to be some trust (unless something like etotheipi suggested is implemented).

[Come-from-Beyond]

You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?

This. If you wan't this information by not checking it yourself, there will always have to be some trust (unless something like etotheipi suggested is implemented).

There is no such thing as TRUST in Bitcoin.

[prezbo]

You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?

And what should I do if I've just launched bootstrapping? Pray that I get non-tampered data?

The validity of bootstrap can easily be checked by checking the hash (which has to be hardcoded into the software) - the way current (full) blockchain bootstrap works.

[Come-from-Beyond]

The validity of bootstrap can easily be checked by checking the hash (which has to be hardcoded into the software) - the way current (full) blockchain bootstrap works.

Ah, that makes sense. Thx.

/thread

[Pieter Wuille]

Bitcoin - at least as implemented by the reference client today - is a zero-trust system: every rule that can be validated is validated by your local node upon receiving data from other nodes. If you want to apply this principle to history, it means you have to see history. There is no way around it: bootstrapping a full node requires either feeding it the entire history, or trusting someone else to give you the current state that resulted from that history.

That does not mean everyone needs to keep the entire chain around, it just has to be available enough so that new nodes can get it (once).

There is an alternative, with almost as good security properties, namely if we could somehow encode a hash of the current state inside blocks (in the coinbase, for example). That would mean someone bringing up a new code could just download the historic headers, verify the proof-of-work in it, download the current state from somewhere, and verify it against the latest block. This would allow him to only require "SPV-level" trust in the past (maybe up to some point ago he considers safe), and then continue full validation from there.

[Pieter Wuille]

The validity of bootstrap can easily be checked by checking the hash (which has to be hardcoded into the software) - the way current (full) blockchain bootstrap works.

This is nonsense. The bootstrap isn't validated in any way - it's just a way to get blocks to your client, and the blocks are verified before accepting them.

[Maged]

The validity of bootstrap can easily be checked by checking the hash (which has to be hardcoded into the software) - the way current (full) blockchain bootstrap works.

Ah, that makes sense. Thx.

/thread

I wouldn't say that really is the end to the thread, since you are then trusting that the developers set the correct hash for the unspent transaction output tree at a given time. Admittedly, it is far better to trust them than random nodes, so it is better than nothing. However, a solution that implements something like etotheipi has suggested would be preferable assuming that it can be made practical.

[prezbo]

The validity of bootstrap can easily be checked by checking the hash (which has to be hardcoded into the software) - the way current (full) blockchain bootstrap works.

This is nonsense. The bootstrap isn't validated in any way - it's just a way to get blocks to your client, and the blocks are verified before accepting them.

Ok, then I apologize for spreading misinformation. I definitely saw this somewhere though...

[MoonShadow]

A light client has to trust other nodes to not collude to tell it lies, but doesn't have to trust a single node; it can request reports from several random nodes and compare notes.  If node A says XXX = 5 BTC and node B says XXX = 10 BTC, ask nodes C, D, E & F to see what they say (by default, the bitcoin client talks to at least 8 randomly chosen peers).  If all of the others agree with A, node B is lying to you, and you can safely ignore it forever.

As for bootstrapping a fresh full node, a full blockchain isn't actually required.  The reference client is built with both a zero trust methodology and a high degree of paranoia, both great places to start for such a project.  However, a full node can be altered to start it's own bootstrapping from 1) an internally hardwired & pre-pruned copy of the blockchain, which it trusts automaticly because it's part of it's own code, 2) from the most recent 'checkpoint' encoded into it's own code (search for the term on the forum) in much the same way that the genesis block is encoded into the clients' codebase now, or both.  It's neither necessary, nor particularly helpful, if every new client has to start from the genesis block; eventually clients that start with an internally checkpointed block number from within the past year or so will be much more common.  A client that uses both methods can entirely skip years of pruned transactions and hashwork, and still mine against the resulting pruned blockchain.