[WHITE PAPER] Bitcoin Distrubuted Chain

[masterluc]

I am really tired of this heavy chain. Did you? Discuss?

https://dianna-project.org/BitcoinDistributedChainStorage.pdf

Anyone interested and can implement? Unfortunately I don't code on CPP, but I have desire to help Bitcoin with my brain.

[1713947984]

1713947984

[gmaxwell]

This page needlessly invokes "DHT"s for a problem far simpler and more reliably solved otherwise (though its good that it recognizes the importance of locality, sad that it doesn't recognize the importance of the most recent blocks or that it thinks that nodes have persistent addresses), falsely claims that we claim the someone will have to store the full chain, and incorrecly claims that no discussion has proposed solutions.

In other words. ::yawn::

A major focus of Bitcoin 0.8 was restructuring things so that nodes wouldn't need to store most of the historical data. There is some way to go before we're ready to enable the option— some p2p changes to signal which data is stored where, and improvements to local database reliability so that nodes don't need to recover from start often... but this is already in progress.

[masterluc]

Splitting data for historical/new is a way for this:

This may lead to some vip set of people who have enough resources to manage full block chain,
limiting overall number of nodes running full chain and making full chain not widely shared,
concentrated in few hands and ultimately become not really viable.

[gmaxwell]

Splitting data for historical/new is a way for this:

The a blocks from the last day are accessed on the order of hundreds of times more frequently than the blocks from months ago. Any system which ignores this request pattern would be crushed under traffic and would fail immediately. Making sure that there is adequate capacity for a small span of the most recent blocks is not in significant competition with providing good coverage of the historical data, as a node can provide both.

Keeping reliable and fast access to the most recent blocks is require to safely handle reorganizations in any case: if you end up on a minority chain you may not be able to find the blocks from it anymore in order to undo the chain to switch the the majority one.

Any a result any system will need a historical/new split, but that doesn't prevent the historical from being distributed. There is no need for single "VIP" nodes that have everything.

[masterluc]

We are talking about different things. Yes, caching data may (and will) help with local load. But there is another problem:

Someone will always need to store and share full chain as the ultimate and required ground of trust to Bitcoin as electronic cash system.
So in this point we have two important questions
● Who will be that "someone"?
● And in which way he will store, manage and share full chain?

[masterluc]

And another problem

Third party software access to Bitcoin block chain problem
As a reference timestamp server, Bitcoin block chain may (and should) be used in alternative chains or other 3rd party software.
As best examples of using block chain outside network are Bitcoin Contracts [4]. Trading across chains will require verification of transactions which can't be done without some interface to bitcoin chain.
Third party software should have some way to easily access Bitcoin block chain likely without keeping original one locally.

[gmaxwell]

We are talking about different things. Yes, caching data may (and will) help with local load. But there is another problem:

Someone will always need to store and share full chain as the ultimate and required ground of trust to Bitcoin as electronic cash system.
So in this point we have two important questions
● Who will be that "someone"?
● And in which way he will store, manage and share full chain?

You are ignoring what I'm telling you.

These are non-issues predicated on a misunderstanding.

"Someone will always need to store and share full chain" this is not true. It is merely necessary that all the data be available, no single person needs to store all of it, it can be offered in part by each node, and in totality only by all the nodes together. This doesn't require any special mechanism beyond the existing design of the protocol, though at the moment all full verifying nodes have all the blocks.

[masterluc]

Okay, you tell me that local load and chain distribution aren't problems.

Actually I open this question because of last problem: How can I retrieve particular transaction by hash from Bitcoin network not running full client?

[gmaxwell]

Okay, you tell me that local load and chain distribution aren't problems.
Actually I open this question because of last problem: How can I retrieve particular transaction by hash from Bitcoin network not running full client?

You don't, thats not something a node ever needs to do when operating, even if it doesn't have the historic chain, as it's not an operation needed for validating the blockchain.  If you'd like such a service feel free to build one... but no need to saddle the Bitcoin network with it, especially activity which is mostly useful for parasitic non-currency uses.

[masterluc]

Yeah, from your point such operations are parasitic. But from my, secondary chains need to be built on Bitcoin ground. As SHA256 chain is one.

[gmaxwell]

Best of luck to you.