Author: Adam Back 2015-12-14 12:32:01
Published on: 2015-12-14T12:32:01+00:00
There are varying opinions on what sequence of scaling solutions should be deployed for Bitcoin. Some suggest deploying versionBits first so that subsequent features can be deployed in parallel, while others believe seg-witness should come first as scalability is more important. There is also debate on whether to do seg-witness as a hard-fork or soft-fork, with some advocating for the former despite it potentially taking longer to deploy and activate, and others preferring the latter due to its lower risk and previous experience with it. Some have suggested implementing BIP 102 first (a straight move to 2MB) before seg-witness and other scaling work. The author personally believes in deploying seg-witness via soft-fork first due to its safety and speed, as well as its need for a robust malleability fix which is important for smart-contracts and scalability features like faster transactions. The complexity risk associated with this approach is minor and any knock on code changes needed will be necessary for future improvements and scaling of Bitcoin. The timeline for deployment is estimated by some to be March 2016, but a BIP and testing are needed before implementation. In addition to protocol improvements, companies can help improve decentralisation by configuring better setups, using self-hosted nodes, and decentralising policy control over hashrate. This might include buying a nominal amount of mining equipment. Some developers are already doing mining and Blockstream and its employees have a small amount of hashrate. If best practices are defined and improvements measured, then miners' concerns about centralisation risk may be reduced and a bigger block implemented faster.Jonathan Toomim suggests limiting the sum of the block and witness data to nBlockMaxSize*7/4 per block, for a maximum of 1.75 MB total, to allay concerns about hardware capabilities in adversarial conditions. He also believes that seg-witness is a substantial change to how Bitcoin works and that developers of other Bitcoin software need time to implement code that supports the new transaction/witness formats. The author of the original post lists two priority areas for scalability: increasing witness size limit and deployment time frame, with the latter being their main priority due to the community's long wait for a scaling solution. Ultimately, there is still much debate on which sequence of solutions will be most effective for scaling Bitcoin.
Updated on: 2023-06-11T02:00:58.994276+00:00