Making bitcoin scalable enough to handle visa's transaction volume

[Robert Paulson]

What if we split the block chain into 1000 mini block chains each responsible for storing 1/1000 of the total transactions.
each node upon installation of the client would randomly choose one of the chains, download it, store it, and process this chain's transactions the way bitcoin-qt does today.
each node would also connect to nodes in other chains.

if a transaction comes for which the inputs belong to a different chain than the one the node is processing,
it would ask X amount of randomly selected nodes from the relevant chain for those inputs and verify them.

by using this system it is possible to process 7000tps without increasing the block size to more than the current limit of 1MB (which allows 7tps).
the 7000 transactions would be split among the 1000 chains and each chain would only need to process 7tps.

[1714730539]

1714730539

[1714730539]

1714730539

[1714730539]

1714730539

[spin]

But your client would have to trust X random nodes.  At the moment little trust is required.  That's the trade-off you're suggesting. 

[Evil-Knievel]

This message was too old and has been purged

[d'aniel]

Are miners choosing individual chains to mine on, or are they merged mined?  If the former, you just made any single chain 1000 times easier to attack.  This could in turn lead to fungibility issues.  If the latter, then you haven't made Bitcoin any more scalable for (full node running) miners, which is what's most important.

Also, in order to be able to accept coins from parallel chains, you'd at least need to keep track of all of their block headers.  With 1000 chains, that's about 350MB per month - too much for smart phone clients to have to deal with.