Topic: #Blocksize Survey - page 10. (Read 16117 times)

Let's Talk Bitcoin! #241 - The 'Big Blockist' Perspective
https://youtu.be/QGD6zouEzW8

with @aantonop

Personally, I can't see how going from the original 33.5MB and reducing down to 1MB was changed with no fuss at all, but an 8MB increase is suddenly controversial.  Also note that it doesn't have to increase every two years.  Preventing it only requires a soft fork, which is far less dramatic.

But that aside, there is a proposal here that seems to be gaining some momentum which seems to meet your criteria.  It just needs BIPing and coding sooner rather than later.  BIP101 is still my first choice, but if there's still no sign of an agreement by January, I'll settle for the as-yet-un-BIP'd "Proposal 1" as a compromise.


So it adjusts roughly every two weeks based on what traffic the network is actually dealing with at any given time.  Blocksize can increase or decrease as required, without handing over too much power to miners, like BIP100 does.

Below you can see results from the 15 biggest mining organisations and the 10 best-funded bitcoin service providers.

TL/DR:
-Miners like BIP100 (which lets miners decide blocksize)
-Service providers like BIP101 (which makes blocksize limit predictable).

Common ground: Most want larger maxblocksize.

BIP 100 isn't currently implemented. I guess we'd put together some more concrete thoughts if and when it is coded up.

My initial thoughts are that I prefer BIP 101 because:
The BIP 100 voting mechanism doesn't seem fully thought out. A majority of miners can always win any vote because they can just orphan blocks that contain votes for something they don't like. So the more complex approach doesn't seem really robust.

But that'd require special code. If most miners just adopt the defaults, then it's possible for a minority of hash power to drag the block size down to nearly nothing.

It's quite common for miners to just accept whatever the defaults are, regardless of whether they make sense. That's why we still see 750kb blocks sometimes when the network is actually backlogged (XT fixes this).

I think the reason is that miners, not unreasonable, assume the Bitcoin Core developers are selecting default behaviour in sensible ways. Alas it's not the case anymore, because they feel choosing opinionated defaults is "centralising". This is why the XT manifesto specifically states we will pick defaults as we think best.

The BIP100 default is 1 megabyte. Thus by default miners would be voting for no change. However what we need is change!

It gives miners additional power to modify the system for no obviously good reason beyond "some miners are saying they'd like more power". Miners are not the only stakeholders. Users, merchants, exchanges, etc matter too - if not more!

The upper limit is meant to be a kind of DoS limit, to stop troll miners generating giant mega-blocks. It's not meant to be a stick that miners can use to beat important but voteless economic players.

There's a risk that someone comes up with a business plan like this:   we will build a giant ASIC farm in the middle of a desert at the end of a piece of string and tin can (i.e. no bandwidth). This will be super cheap because of abundant land/solar/wind/whatever and the lack of bandwidth won't matter because we can just drag down the block size limit to ensure tiny blocks.

This would of course hurt the entire ecosystem for their own short term benefit, but BIP 100 would let them do that with just a small amount of the overall hash power.

Miners have just one job: order transactions by time. They shouldn't be doing anything else, and arguably, people already freak out about the concentration of power in the hands of big mining pools. BIP 100 would make this issue worse.

So these are my initial thoughts.

Just remember everyone, that everything is started because the limit of the actual block size.
So, if the community will make the wrong choice by still limiting too much the size, we will need to start again all of these mess to make another fork

I think 8MB every 2 years is random as hell and insane. The blocksize should be increased in relation to the real increments of network usage, not some 8ball prediction about it and then naming it the magic 8MB every 2 year solution.

If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
    Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
    Half MaxBlockSize
Else
    Keep the same MaxBlockSize

I think 8MB every 2 years is random as hell and insane. The blocksize should be increased in relation to the real increments of network usage, not some 8ball prediction about it and then naming it the magic 8MB every 2 year solution.

My question is why? Aside from the few companies that recently signed a document, there is currently 0% support for BIP101 from the miners. I don't really see the point in pushing a BIP for which there is no support.

There is more than 30% support for BIP100 though. Bitfury is now supporting it as well.

Bitcoin Backers Propose Solution to Split That Threatened Disruption
http://www.bloomberg.com/news/articles/2015-08-25/bitcoin-backers-propose-solution-to-split-that-threatened-disruption

Here's Hearn responding to a query from Bloomberg:

"It's great news. Bitcoin XT implements BIP 101 + other things. The letter doesn't say if they'll run XT or not, but that's OK: the other changes in it are useful but not as important in the same way as the block size limit is. If these companies take just the BIP 101 changes and apply them to Bitcoin Core, we're all good.