IntroThe Bitcoin blocksize debate is giving altcoins their golden opportunity to break Bitcoin's dominance, primarily because several extreme ideological factions are completely unwilling to compromise with the opposing side, and now frequently promote drastic threats against the other side. The net result regardless of who is right and wrong is that all bitcoiners are losing, and all altcoins are winning by default.
Simplest summary: "Very slow voted changes." This proposal attempts to fairly and evenly balance the power and concerns of all of the competing ideologies.
Here's the idea: Miners vote on blocksize changes, up or down, in very small steps up to an 80% increase in blocksize per year. The voting caps on miners are as tight as possible, to handle a frequent objection to any miner voting proposals -
"Miners gaining dangerous levels of control" - or relatedly -
"miners' best interest diverging from users'". 80% is the best fit because it is sufficient to allow unanimous agreement match our very-high 2-year transaction growth(+81/80% YoY), whereas anything higher decreases the protection for those who favor small blocks.
As shown in the scenario analysis below, even a small amount of disagreement among miners restricts growth massively. I reference the discrepancies between signaling over the past 2 years(Classic, XT, BU, SegWit, No signal) that even if miner's disagreements are not equivalent to users', significant differences of opinion naturally occur among miners. Even without any divisions, the growth is slow enough that miners have ample time to learn(or be persuaded) from bad voting decisions and correct them.
Block validity is deterministic, and thus does not attempt to redefine "consensus" like BU does. Most important of all, the math is structured to allow a minority vote to provide a disproportionate slowdown mechanism on growth. The net result should change conflicts (incomplete compromises -> anger and zero progress) into cooperations (partial compromise -> partial progress).
So, how does this proposal accomplish those things? The proposal is closest to Garzik's BIP100 current version, but with some important changes.
This idea vs BIP100 and other related ideasBIP100:1. The original BIP100 allowed 20% increases per difficulty(Max: 1.2^26th% per year). The current BIP100 allows 5% per difficulty which compounds to ~270% per year, or 8mb blocks before 2018 ends. This proposal is 80%/year (2.3% per diff), or 8mb blocks by early 2021 if all miners vote unanimously.
2. BIP100 planned re-evaluation at 32MB. Re-evaluation is not needed under this proposal, as the slow pace encourages analysis and opinion adjustments, and the strong influence of the minority encourages mutual cooperation.
3. BIP100 allowed a cutoff minority(21% originally) to veto blocksize increases, and gave 100% of the decision power to the lowest moderate voters. This proposal includes all positions, without significantly favoring any.
4. The original BIP100 gave a non-veto minority
no influence on blocksize growth; This one gives them the ability to constrain growth by more than double their minority percentage.
After writing this up, I found two other proposals that were somewhat similar. The first, by "BTC Drak" (dev email list, Aug 2015), had the too-high-limits flaw (max ~1,200% per year) that he attempted to offset with a cost for voting for increases. The second, by "PondJohn" (bitcointalk.org dev section, Jan 2017) proposed a reasonable scaling limit(~100%/y, ~2.7% per difficulty), but it intentionally unbalanced increase votes against decrease votes by adding a cost to increase votes and changing the numbers. That unbalanced approach makes it difficult to estimate how the proposal might play out in reality. It also seemed to assume that size adjustments occurring naturally at every difficulty change is not desirable.
I originally attempted to design the math to favor the minority and/or small blocks, like all similar vote proposals, but I discovered by digging through almost 100 different split-vote scenarios that it simply wasn't necessary, and those approaches unintentionally broke other split-vote scenarios. I also considered a few approaches that penalized extreme votes, but found that the system worked quite well even when every vote is for an extreme.
How it worksThis proposal would allow (after activation) all miners to add a vote for blocksize to their blocks, with all numbers larger than 1MB being valid votes. At every difficulty change, the votes from that difficulty period are tallied, with missing votes counted as a vote for no change. Each vote is clamped between ~1.594x and ~0.419x times the current maximum blocksize, and then averaged together. The reason for the odd multipliers is that there are roughly 26.9 difficulty changes in a year, and 59.4% compounded on 26.9 intervals works out to 80% YoY growth (2.3% per diff). The minimum vote clamp is calculated such that one extreme-shrink blocksize vote is perfectly offset by a subsequent extreme-growth blocksize vote; Mathematically, this maximizes the slowing power of a small-block minority without allowing attacker(s) to shrink the blocksize faster than it could be regrown.
After the clamped vote average is calculated, the next difficulties' consensus maximum blocksize is defined as 1/26.9th of the voted increase or decrease. Since the votes are clamped to a minimum and maximum, averages give a minority significant influence over a majority without changing end results.
How does this play out? This image summarizes the numbers under different split-vote scenarios:
https://goo.gl/w52VTcOf note from this summary, only with a constant overwhelming majority favoring increases are 5mb+ blocks possible within 5 years. In the 3 cases where not all votes went towards the extremes, the growth quickly came close to a balanced compromise and then stopped.
There are two anomalies that slightly favor larger blocks, visible in the above situations. The first is that when the current blocksize is smaller than 2.4mb, the minimum vote is arbitrarily constrained(1.0mb) and the maximum is not(first situation small-block majority). The second is a side effect of allowing any possible unanimous decrease step to be offset by one subsequent unanimous increase step("perfect disagreement" situation). Both advantages have a very small impact on long-term results.
I've also made an excel spreadsheet to examine different split-vote scenarios that can be downloaded from here:
https://goo.gl/CdLz41Any miners that do not vote further decrease these growth numbers. Those miners can be approached by the community and convinced to vote for one side or the other.
Potential attacksThis has one potential vulnerability apparent to me thus far: A majority could easily collude to orphan all blocks they disagree with to accelerate growth(and punish dissent). A block-orphan attack like this is not new, and is already a possibility in our current situation.
For example, if all Chinese miners pooled together, they could orphan all blocks not mined to a cartel-whitelisted address, decreasing the difficulty, and thus take control of 100% of the mining. Even if the network took the drastic step of changing the PoW algorithm, the vulnerability would still exist due to natural inequalities in suitable mining locations and efficiencies of scale.
Ethereum(Or whoever originally generated the concept) has a workable solution: Uncle block rewards. Unlike Ethereum, our financial supply does not grow forever, so it requires some adjustment.
Simply put, recent orphan blocks may be referenced by other valid blocks(nephew includes uncle reference) to split the "lost" orphan reward for both miners(smaller fraction to nephew). Transactions that would have been valid if included in the nephew are counted towards the orphan block reward split and are considered confirmed by the nephew's inclusion. To prevent exploitation, referenced uncle blocks(but not unreferenced orphans) count for the purposes of votes and difficulty calculations. Further, time limits/uncle limits would be included.
Not including an orphan-attack fix would not be fatal to this proposal, but including it would have significant other benefits and encourage miner support in the face of alternatives currently preferred by miners. Given the massively increased complexity of uncle changes, after the rules are agreed upon it could be forcibly activated after a pre-determined 6-12 month delay (I.e. further static delay after activating this proposal), preventing the need for a second hardfork. This could give ample time for testing and third party code updates without delaying the much simpler blocksize voting changes.
Responses to each conflicting ideology1.
No Blocksize increases: Those favoring no blocksize increases at all are in the extreme minority. Refusing to compromise may result in even bigger blocks than would be possible by compromising, after significant damage from a contentious hardfork. Refusing to compromise hurts all Bitcoin holders, miners, users, and developers.
2.
Small blocksize increases only: This proposal will most likely exhibit the kind of growth these users can swallow. Under most scenarios even a moderate amount of dissent allows only slightly faster blocksize growth than technology's increases(8-18%/yr) and puts 4mb blocks more than 5 years away. Growth rates are predictable years in advance with narrow margins of error for any hardware/bandwidth planning, personal or otherwise.
3.
Big blockers: This proposal allows the possibility of growth rates that can achieve a main goal of big blockers - Preventing transaction demand from driving fees up. Big blockers would know which pools to talk to about changing their vote, and could attempt to resolve those miners' concerns. In addition, steady growth is nearly guaranteed given the popularity of bigger blocks.
4.
BU Proponents: This proposal could end the war between BU and core while accomplishing most of the goals BU set out to accomplish. Everyone's coins would increase in value.
5.
Segwit-solves-everything: Segwit only provides a limited, one-time blocksize increase. We will face this contentious issue again soon without more than segwit. Segwit activation could also be a prerequisite for this proposal's adoption as part of the compromise.
6.
Miners-must-never-control: The only practical alternatives either require multiple contentious hardforks or require developers to accurately predict the proper future limits many years in advance. This proposal has developers setting upper bounds as low as is reasonable and gives the minority tremendous slowing power without blocking the majority.
7.
Miners-must-have-control: This approach gives miners the main control lever, and strongly encourages cooperation between differing ideologies.
I welcome any rational feedback. Thanks.
