#Blocksize Survey

[HostFat]

Not working on paper? So Bitcoin, being vulnerable to a 51% attack as it is, does not work? The code for BIP101 solely exists because of its simplicity, and it has not been tested either. Have 8 MB blocks been tested? Not really,thus the same principles apply.

Gavin has made tests up to 200 MB.
Simpler the better

[Lauda]

Gavin has made tests up to 200 MB. Simpler the better

Technically no, simpler != better. If engineers had applied that saying long ago we would be stuck on old hardware forever (since smaller manufacturing processes are more complicated). Besides, you can't generalize anyways.
In a range from 8 MB to 8196 MB, 200MB is minor. He tested up to (your words) 2.44140625% of the maximum that his proposal will handle. That's really a great way to test something. I would not really want to go through the forking trouble again once something breaks.

[flix]

http://www.coindesk.com/support-grows-for-bip-100-bitcoin-block-size-proposal/
Support Grows for BIP 100 Bitcoin Block Size Proposal

Of all the proposed changes, an 8MB increase has the biggest share of bitcoin's hashrate (25.5%), with support from KnCMiner, Antpool, 21 Inc and BW Pool. Meanwhile, Gavin Andresen's XT fork – which has been branded "dangerous" by some core developers – lags behind with 1%, despite 14.6% of nodes showing support.

Additionally, Slush.io, the only mining pools having voted for XT so far, appears to have 'switched off' its vote in its most recent blocks.

[AtheistAKASaneBrain]

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.

[flix]

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.

[Lauda]

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.

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.

[bliss]

Right now, I would like to see us all work together to find what works for bitcoins future.

Keep in mind the current trend is bitcoin and litecoin both taking center stage in the future, with A. Bitcoin allowing larger purchases such as homes, vehicles and other larger purchases. B. Litecoin meeting every day needs with small sized purchases.

Bitcoin also is human technology, so the technology itself is humanities. There is no 2 humanity, 1, so when t comes to btc or ltc, group has to decide. This is why there are other crypto currencies. Again, we all need to work together to make it work and also to agree together.

Bitcoin being the first is also an experimentation, remember that.

Mining. Ok. With mining, I need to also consult The London Bitcoin Bank members and find out there view so they can chime in here.

My view with blockchain size, its big... time to verify is long but also gives room for services. Electrum? I think at LBTC Electrum is the future for personal btc client and also similar on smart phones, it could be sped up, but remember the twin bitcoin litecoin system. You can't have a coin to meet everyones needs all the time. We have silver coins and gold coins (or green notes!). Fee's must be left to increase if need be. Mining is in a dangerous place. Miners are not making money. If the price is becoming silly, have to move it back to the miners like it was at the beginning, because that is what made the changes in price to happen from $1 for 1300 btc to what we have today.

Good work people. Let's make this happen right for humanities future.


Create a great day,

Kozan

[Muhammed Zakir]

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.

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.

Why does Gavin and Mike only want to support BIP 101? A result based on a mysterious calculation, 8 MB increment and henceforth, doubling. If they really want to support bigger block size limit, like all pro-XTs say, why can't they accept any other BIP which has got more support?

[HostFat]

BIP100 is bad for the market, because it add unpredictability, by giving votes to the miners.
This will just push the market (services) and users to other networks.  

If BIP100 is chosen, you can be sure that will we need another earlier fork to take away the vote from the miners, if we want to get the Bitcoin to survive the competitors.

[bliss]

Note... going to put up several things as comes to me.

This is a page on the bitcoin wiki:
https://en.bitcoin.it/wiki/Block_size_limit_controversy

[Mickeyb]

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.

I don't know why but this seems insane to me too. To get to the 8GB in the next 20 years is possible, but why take that road today. I mean, who the he'll can predict a future. Well nobody, not even Gavin. And then what will happen if such a huge blocks won't be needed or they create more problems in few years.

Why not opt in for some more modest solution and then revise it again in few years, even if we would have a debate like this again.

[DooMAD]

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.

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.

Code:

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

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.

[HostFat]

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

[Mickeyb]

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

Well not necessarily, at least let's hope so. If the increase goes well, ends up justified, and community sees that we made to much of the fuss last time about is since it was really needed, the increase, maybe the next debate will be smoother.

Also, we don't need to put too much of a pressure not to get it right this time because of the possible future debate. Who knows what the future holds, we can't predict it. We might be sure that we have chosen right, and we end up wrong. We need to stay flexible.

[flix]

Potential dangers of BIP100
https://www.reddit.com/r/Bitcoin/comments/3ii1vt/potential_dangers_of_bip100/


21% attack possible against BIP100?
https://www.reddit.com/r/Bitcoin/comments/3id7f9/21_attack_possible_against_bip100/

[HostFat]

https://groups.google.com/d/msg/bitcoin-xt/oFmzqn46v74/B1CKY7bNBgAJ

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.

[flix]

This piece from Coindesk summarizes how different players are positioning themselves in the #blocksize debate:
http://www.coindesk.com/block-size-debate-whos-picking-sides/

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.

Support BIP100
KNC Miner            
21 Inc            
BitFury            
BTCChina            
Discus Fish/ F2Pool            
Kano CKPool            
BitClub Network

Support BIP101
Slush
BitGo            
BitPay            
Bitnet            
Blockchain            
Circle            
itBit            
Xapo

8MB
BW Pool            
AntPool

Undecided
Eliguis            
Telco 214            
GHash.IO            
BitMinter            
EclipseMC
Coinbase            
Vogogo            
BitReserve


....if could just know the position of the top 10 exchanges and the top 100 Bitcoin holders.... we would have a very good picture of where the community stands.

[uxgpf]

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.

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.

Code:

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

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.

I think that would keep blocksize limit too close to the actual blocksize and give an incentive for miners to spam the network with transactions. In order to make spamming unprofitable max blocksize should be atleast 50% higher than the average blocksize.

[flix]

This:
Miners, merchants, exchanges & wallet providers, let us know which block size you will support
http://blocksize.org/

[flix]

Excellent interview with @gavinandresen on #blocksize, Bitcoin governance and a lot more:


Gavin Andresen: On The Blocksize And Bitcoin's Governance
https://youtu.be/B8l11q9hsJM


He clarifies his plans to promote BIP101 (with or without Bitcoin XT), the problems with the current decision process in Bitcoin Core, the need for multiple implementations, etc....



...and here is a previous one with Mike Hearn:
Mike Hearn - Blocksize Debate At The Breaking Point
https://youtu.be/8JmvkyQyD8w