bitcoin-dev

Scaling Bitcoin with Subchains

Scaling Bitcoin with Subchains

Original Postby Andrew

Posted on: June 16, 2015 15:23 UTC

The subchain method proposed by Pieter can constrain all the addresses in a wallet to a path of subchains and prove the state of the UTXO database corresponding to the wallet with O(log n) proof.

Although some may argue that it is not really a proof as transactions involving sibling chains outside the path of chains are not verified, the protocol is "parent chain always decides in case of conflict". The parent chains have an incentive to be careful with what child blocks they commit to as they will be merge mining the direct child chains. Recursive incentives ensure that the system takes care of itself, reducing the likelihood of errors. Pieter disagrees with the idea of downloading all headers and merely verifying transactions filtered out using their corresponding merkle trees, stating that it would not scale as well as with the tree structure he proposes. In a typical non-mining situation, only headers or full blocks in one path going down the tree starting from the root chain are required, which means O(log n) needs to be stored (headers or blocks). With big blocks, O(n) headers are still needed. Storing full blocks on the chains ensures that the headers of those blocks are validated and all transactions on those blocks are visible, including certain addresses that must stay on those blocks. Filtering out based on addresses or other criteria may result in missing transactions, which could be problematic. The advantages of this system for mining decentralization have also been explained in previous posts.Mike Hearn argues that either one cares about validation and must validate everything or does not care about validation and does not validate anything. However, the point remains that side chains are not a way to scale up.