bitcoin-dev

Scaling Bitcoin with Subchains

Scaling Bitcoin with Subchains

Original Postby Andrew

Posted on: June 15, 2015 17:05 UTC

The discussion involves the opposition of coins that are coming from chains that aren't directly validated.

Splitting up transactions into multiple chains doesn't stop someone from validating all chains, which results in the same validation workload as a full node with one chain and big blocks that store the same number of transactions per second. The idea of extension blocks is proposed as synchronised chains, and some people think that CPU speed and memory size are the only limitations to running a full node, so they run heavily pruned nodes. Pruned nodes are bad for the network as they pose real security risks. There are reasons why long-term history of transactions on a hard drive is necessary, including the risk of denial of service attack from "archival" nodes, and the fact that there's less of an inequality between big data centers and regular people. If most people can only run pruned nodes, then analyzing old Mt Gox transactions using the blockchain will no longer be possible. Without the full history of blocks, people cannot really give a proof to others that what they noticed with their pruned nodes is actually what happened if they spot something interesting. Centralisation is a security risk; thus, decentralisation means you can run a full node (or an almost full node on the chains you are interested in) in a shack in the middle of nowhere and monitor it remotely with cameras or whatever. 10 MB blocks are too much to enable this definition of decentralisation. The development process of proposed scaling methods using bitcoin-core and possibly the sidechains code from Blockstream as a base will be started, but progress will likely be slow. Finally, the discussion also involves the idea of side chains equipped with the right cost incentives for cross-chain transactions leading to a scalable and efficiently self-organizing network of side chains. Communities with many internal transactions would create their side chain with low fees, and geographic as well as virtual communities would form. To save fees, a typical user would maintain a wallet in each of their communities which are loaded and drained with rare expensive transactions, whereas daily business with many transactions is done cheaply within each community chain.