Bitcoin Forum

A vague idea to improve scalability.

Instead of a block chain, how about a block tree.

You start with the root or genesis block and all branches must be filled breadth first from left to right. So all blocks have order and could be viewed as a chain.

Nodes have a position in the tree, so a full node has a depth of 0 and no path. A half node would be at depth 1 and a binary path of either 'left' or 'right' etc. Nodes can be at any depth and must have a path to a branch in the tree.

A node only has to deal with blocks relevant to its position, that is the path blocks to its location in the tree and the sub-tree blocks that come after.

This would allow people running the client to select how much of their resource they want to donate to the network. A quarter node for example would only use a quarter of the resources.

Please criticise.

lolwut?

^ This

This suggestion, as presented, makes no sense to me.  The blockchain isn't the network, so it doesn't parse to put the blockchain into a tree with each 'node' at each block position.  Are you talking about the network topology?  If so, a tree would be a terrible idea, because it would create nodes of special significance within the network.  Thus potentially permitting some kind of presently unknown attack due to the predictable nature of a static network topology.  If you are talking about the blockchain itself being a merkle tree so that not every node must keep all of the data to verify the validity of the blocks, it already is so; but the merkle trees are internal to the blocks and permit future clients to 'prune' the blockchain by deleting transactions that are not relevent to it's own needs without compromising the testable structure of each block.  The only part of the blockchain that must be kept in order to verify the strongest/longest/correct chain is the block headers themselves, which are only 80 bytes per block or about 4 megabytes per year.

Sorry for my description being so vague.

I am talking about the structure of the block chain and not the network topology.

The client can be set as root so that it stores the whole tree,
or set to a depth of 1 with path 'left' stores the left side of tree,
or set to a depth of 1 with path 'right' stores the right side of tree.
or set to a depth of 2 with path 'left,left' stores left left quarter of tree
...
...
...

A transaction's inputs can reference outputs from different blocks (and therefore, more than likely, different parts of your block tree that are not all tracked by a single partial node), therefore a single non-full node can't know if those transactions actually exist or not.  How do you propose handling transaction forwarding in a way that the network doesn't have a bunch of spammy invalid transactions being forwarded around while valid transactions actually make it through the network to the miners and the recipients?

Validating transactions.

Nodes would support 'getInputPath' and 'getOutputPath' messages.

Called node will return a 'not found' message if block is not in its tree, or if it finds the block it will return a 'block chain'.

The returned block chain is the path from the nodes position in the tree to the found block. Like Bitcoin we accept the longest block chain, or in this case deepest rightest most.

Sounds like a lot of work for not much gain.  Also, it reduces security unless nodes make more connections.  That means it costs us something that is already scarce (sockets) for something that isn't even remotely scarce yet (disk space to store the 875 MB block chain).

When bitcoin gets really big, I can see entities using something like this for their own internal clusters, maybe.

Again, the internal block structure can be pruned to whatever level the client's owner feels is appropriate, all the way to nearly nothing.  Most 'thin' clients won't need to even receive more than the block headers to start with, and thus won't need to 'prune' at all, but instead collect the data that is directly relevant to it's own addresses on the fly.  Your idea has merit, but offer little advantage to the current system, but huge risk of creating an unintended attack vector.

Thanks all for comments, exactly what I was after.

Will rethink the problem of scalable alternative.