Pages:
Author

Topic: Bootstrapping the pruned blockchain (Read 1991 times)

legendary
Activity: 1708
Merit: 1010
May 10, 2013, 01:33:22 AM
#25
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.

Non-colluding, so a light client is in some ways like a Ripple that actually works?

And it works, because that is not the only method available to it.  Ripple is a fine concept, but fails because it's dependent upon a viable web-of-trust; something that can, and often does, collapse in real life.
hero member
Activity: 784
Merit: 1000
May 10, 2013, 01:22:15 AM
#24
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.

Non-colluding, so a light client is in some ways like a Ripple that actually works?
legendary
Activity: 2142
Merit: 1010
Newbie
May 09, 2013, 06:37:06 PM
#23
Thank you.
legendary
Activity: 1204
Merit: 1015
May 09, 2013, 06:35:46 PM
#22
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.

Could u give the link to etotheipi's suggestion, plz? Can't google it.
Sorry about that:
https://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208
legendary
Activity: 2142
Merit: 1010
Newbie
May 09, 2013, 03:08:46 PM
#21
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.

Could u give the link to etotheipi's suggestion, plz? Can't google it.
legendary
Activity: 1708
Merit: 1010
May 09, 2013, 01:56:34 AM
#20
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.
sr. member
Activity: 430
Merit: 250
May 09, 2013, 01:40:00 AM
#19
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...
legendary
Activity: 1204
Merit: 1015
May 08, 2013, 06:07:53 PM
#18
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.
legendary
Activity: 1072
Merit: 1181
May 08, 2013, 06:07:32 PM
#17
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.
legendary
Activity: 1072
Merit: 1181
May 08, 2013, 06:00:59 PM
#16
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.
legendary
Activity: 2142
Merit: 1010
Newbie
May 08, 2013, 12:15:06 PM
#15
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
sr. member
Activity: 430
Merit: 250
May 08, 2013, 12:13:27 PM
#14
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.
legendary
Activity: 2142
Merit: 1010
Newbie
May 08, 2013, 12:13:25 PM
#13
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.
sr. member
Activity: 430
Merit: 250
May 08, 2013, 12:11:13 PM
#12
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).
legendary
Activity: 2142
Merit: 1010
Newbie
May 08, 2013, 12:11:00 PM
#11
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?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
May 08, 2013, 12:08:27 PM
#10
You believe your own *pruned* blockchain rather than anyone else's don't you (i.e. how can it contradict itself)?
legendary
Activity: 2142
Merit: 1010
Newbie
May 08, 2013, 12:05:51 PM
#9
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?
sr. member
Activity: 430
Merit: 250
May 08, 2013, 12:03:16 PM
#8
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.
legendary
Activity: 2142
Merit: 1010
Newbie
May 08, 2013, 11:51:39 AM
#7
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.
legendary
Activity: 1596
Merit: 1100
May 08, 2013, 11:45:10 AM
#6
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.

Pages:
Jump to: