Topic: Blockchain size proposal - Very Slow Voted Changes (Read 1935 times)

If segwit will successfully in the first time, it might be possible second time

They aren't a necessity, but they are a possibility under your proposal. Why do you want to allow something unnecessary yet scary?

Why?

No exponential growth can last forever. HDD capacity growth slowed down very significantly several years ago.

With second layer solutions like LN, even 900MB blocks aren't necessary to absorb all transactions of entire world population.

That would just work out to voting with money

I don't understand the dislike of miner voting systems.  It assumes that miners want substantially different things than users, but I don't see any real evidence that the differences are significant.  Maybe they are, but I have yet to see someone show that they are with data or game theory.


I've seen proposals like that before.  I mean, they're better than nothing.  But miners accidentally create higher-difficulty blocks all the time, so the size could continuously increase as well, just restrained by randomness.  Might as well just give it a time-bound scaling ratio then.

Yes, I calculated that.  You can check the spreadsheet to play with the numbers.  Firstly, 191 GB blocks aren't a possibility.  At 31 GB blocks we'd catch up to 100% of the worldwide non-bitcoin transaction volume even accounting for the growth of that number.  There's no way that many businesses/people are going to switch to Bitcoin in 30 years.  If we got 5% that'd be awesome, and that's 900mb blocks.  900mb blocks may sound terrifying, but even without major improvements to the protocol businesses and nonprofits like the EFF could run nodes for less than $2000 a month.  That's a rounding error in most business' IT budgets, and nodes would be running in every nearly every country on the planet by that point, massively geographically distributed.  Early adopters could easily run a node for the rest of their life without breaking a sweat.  That doesn't seem scary to me at all for 5% of the world's transaction volume.  Shit, if we had 5% of the world's transaction volume, the price would probably be upwards of $60,000 per BTC, or more.

Secondly, 50% growth year over year is offset by a 17% decline in bandwidth and hard drive prices, so ~33% increase per year in node operational costs.  Bitcoin prices have been increasing by 44% per year for the last 4 years, so for anyone who actually holds more than a few bitcoins, the node costs remain trivial.

Thirdly, 50% growth year over year for 10-30 years requires a continuous agreement of 60% of the miners for that full time period, with no miner waving.  Historically getting 60% of miners to agree to signal the same thing has been very difficult, much less getting them to continue supporting it for a year.  All it would take is one miner agreeing that node costs were becoming problematic and switching his vote and the growth would stall dramatically.

So yeah, those numbers look scary at first.  They did for me too.  But given the possible rewards for Bitcoin, it really isn't that scary.

Thanks for the feedback.  I joined a few days ago and am feeling it out.  I get the idea right now that there's too much resistance to nearly any blocksize increase except SW.  Unfortunate, really.

I don't like proposals which involve "voting" of any sort.

I think that the blocksize should be controlled by people who generate transactions

And the best way to achieve it would be like follows:

1. Set unlimited blocksize limit
2. Calculate average block size over past 20k blocks
3. If a miner wants to create a block larger than the average, he'll have to solve a puzzle with exponentially higher difficulty. Something like Exp[(new_block_size/average_block_size -1)]*difficulty


This setup increases probability that the miners will attempt to create larger blocks only if consumers (e.g. people who create transactions) actually need them and signal that the larger blocks are needed by posting transactions with larger fees

You propose to allow exponential growth. Exponent is a scary thing. Did you calculate how big blocks can become in 10, 20 years? Let's suppose moderate 50%/year size increase:
10 years: 57.66MB
20 years: 3325MB
30 years: 191751MB

I think this is a reasonable proposal.  But if you want serious discussion, the place to make it is on the bitcoin-dev email list.  A little bit of reworking into BIP language and you might win some support there.

Ok so from what I learned so far the block chain contains the transaction history. And without the history we can't validate the blocks. So even if you want to clear the transactions that are already spent you would have problems because without them the blocks are not valid. Also when I began with BTC the chain was only around 14-15GB so it wasn't that big but seeing that now it's like 100GB+... even if we did a hard fork to clear transactions from newer blocks we'd have problems because of the number of nodes. Also I think that the 4MB block size is absurd but we surely can't live with 1MB anymore. I think the community should have the right to control the size but then number of those who are not having the full chain is high.

Two days, 444 views, zero replies?

Anyone?

Intro

The 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 ideas

BIP100:
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 works

This 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/w52VTc

Of 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/CdLz41

Any 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 attacks

This 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 ideology

1. 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.