Published on: 2015-08-07T00:37:16+00:00
The proposed solution to the debate over block size in Bitcoin is to increase it by 8MB and 40% annually, with the option for miners to cap their blocks at a lower amount if necessary. This proposal aims to maintain comity and humility by acknowledging the inability to predict future trends accurately. Miners benefit from higher bitcoin prices and will limit excessive growth of blk*.dat size to avoid centralization and capture by powerful interests. The scheme is predicated on the price going higher over the extended term. Full nodes do not need to be used for propagation, and anyone can vote by coding. The proposal is seen as a reasonable compromise that can be adjusted if necessary down the road.On August 7, 2015, a question was raised on the bitcoin-dev forum regarding whether miners can unilaterally decide to change Bitcoin's protocol rules. Pieter Wuille responded stating that miners don't need to use full nodes for propagation, and they only care about whether their blocks are ultimately accepted. Additionally, full nodes have the ability to change what blocks they accept, which is known as a hard fork.The Bitcoin community is proposing a voting system to determine the future of the cryptocurrency. The proposal outlines several voter groups, including bitcoin miners, bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. Blockchain-based voting would be conducted using a single transferable vote system, with voters ranking their preferences and eliminating candidates until one remains as the most popular. However, there are concerns about the criteria for eligibility in certain voter groups, and how many bitcoins equate to one vote. Technical issues also need to be addressed, such as verifying identities, collecting votes, and ensuring no double voting occurs.The email thread discusses various voting systems to be implemented in the Bitcoin development process. The Single Transferable Vote system is proposed where voters rank their preference with “1”, “2”, “3”, etc. The candidate with fewest votes is eliminated and those votes are transferred according to their second choice until only one candidate is left. Approval and Range voting are suggested as better systems for achieving a consensus. Miners can also choose what the size is subject to limits which they could do unilaterally. The outcome of voting may not necessarily be a binding decision but voters need to recognize that failing to find a middle ground could mean they get their way but they split the community. In addition, since the point is to determine parameters, there is no need to select from discrete candidates like initial new size, rate of increase, and maximum size. They are just numbers and votes could indicate what they want, and then use the median as the consensus option.The bitcoin-development mailing list has been discussing proposals for scaling the network, and a recent post suggests that it is not scientific or sensible to go straight from proposal stage to voting and implementation. The post argues that the proposals need to undergo testing and scenario simulation with published results in order for objective evaluation to be possible. Additionally, the lack of provision for scaling down in the current proposals is noted, and the potential implications of global credit contraction or natural disaster on usage, scale, decentralization, and security are discussed.In August 2015, a debate began on the Bitcoin-dev mailing list about how to make changes to Bitcoin's consensus rules. Pieter Wuille argued that Bitcoin's consensus rules are a consensus system, not a democracy, and suggested that if people want a majority to decide on a currency's economic policy, they should use fiat currencies. A proposal to wrap up the debate with voting by different stakeholder groups was presented, including miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full node operators. The proposal outlined the requirements for each group to be eligible to vote, as well as the voting system, which used a single transferable vote and required voters to rank their preference. Technical issues such as double voting and multiple identities were also addressed.In a recent post on the Bitcoin-dev mailing list, Venzen suggests that it is not scientific or sensible to go from the proposal stage straight to voting and then implementation stage. Instead, proposals should be tested and scenario simulated with published results in order for objective evaluation to be made possible. Venzen argues that there is a lack of provision for scaling down in the current proposals as well. In response to this post, jl2012 proposes candidate proposals and a voting system for different stakeholder groups. The voter groups include miners, Bitcoin holders, developers, exchanges, merchants and service providers, and full nodes operators. The votes will be counted independently, and each group has its own eligibility criteria. Single transferable vote is applied, and voters are required to rank their preference with “1”, “2”, “3”, etc, or use “N” to indicate rejection of a candidate. Technical issues with the voting system are also discussed, including the need for a trusted person to verify voters' identity by email, website, or digital signature.
Updated on: 2023-08-01T14:56:05.274804+00:00