From all of us newbies: Can you PLEASE dumb down this whole block size debate?

[Chris!]

Lately I've been seeing on Bitcointalk that blocks should be changed from 1mb to 2mb (or more) and people should be changing from some kind of node to another. It seems that some people have very strong opinions about one or another.

I'm not just arbitrarily choosing to post this now. I've been reading through websites and the forum work weeks now but it's mostly just people that know a hell of a lot more about bitcoin than I do! Someone needs to dumb it down for us newbies!

What's the difference between bitcoin core, bitcoin classic, bitcoin XT and what does it mean to have a block that is 1mb? What takes up the data, and why do they need to hold more data? Why would 1gb not be a logical choice? From what I understand, it would slow down transaction confirmations. Why/how? Explain the math behind it if you can.

I'm hoping to consolidate all of the information I learn into the first post so other newbies like me can have a one-stop-shop for finding out what this whole block size debate is about. Any insight is appreciated. Thank you!

[Iseecookies]

Think it would be easier understand if the fud was turned down a notch. Kind of the issue with anything that may alter bitcoin. Vested interests usually bark the loudest. Almost worth hunting it down on your own.

[achow101]

The current network consensus is to have a maximum block size of 1 Mb. This means that 1 Mb of transactions can be stored in one block. Transactions have a data size, usually between 200 and 500 bytes and this is what takes up space in a block.

The issue that some people have with 1 Mb blocks is that at some point, there will be so many transactions that all blocks will be reaching the maximum number of transactions that they can contain. The idea is that increasing the maximum block size will allow for more transactions to be included in a block. This would then allow more transactions to confirm in one block and, in theory, keep fees low as long as there is space in blocks for transactions.

Additionally, when blocks become full, there is an idea that this will create a fee market. This essentially means that fees will increase as people have "bidding wars" with their fees to have their transactions included in a block since there would not be enough block space for all of the unconfirmed transactions. This would drive up fees and thus earn more income for miners but could potentially drive away users as the fees become too high.

Larger blocks have their drawbacks, as do smaller blocks. Larger blocks require more data to be transferred, and as blocks grow larger, the bandwidth requirement increases. There is also a verification slowdown that is caused by large blocks. The time required to verify a block grows exponentially in relation to the block size. These factors can lead to slowdowns in the propagation of blocks and therefore increase the orphan rate of miners. This additional bandwidth requirement can also make it difficult for more full nodes and miners to come online.

Smaller blocks, on the other hand, can restrict the network capacity. They can prevent many transactions from being confirmed if there are too many transactions in the pool of unconfirmed transactions. This can cause delays for transaction confirmation.


Increasing the maximum block size is just one of the proposed solutions for increasing the number of transactions that the Bitcoin network can process. Alternatives include the lightning network, sidechains, and segregated witness among a variety of other proposals.


Bitcoin Core, Bitcoin Classic, and Bitcoin XT are various clients that implement slightly different consensus rules when it comes to the block size limit, which is also why some people consider Bitcoin Classic and Bitcoin XT as altcoins since Bitcoin Core is considered the reference implementation.

Bitcoin Core proposes to use segregated witness. Segregated witness is a solution to transaction malleability which has a side effect of decreasing the size of a transaction and thus increasing the number of transactions which can be put into a block. This also solves the exponential verification time problem and makes it linear.

Bitcoin Classic is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 2 Mb.

Bitcoin XT is a fork of Bitcoin Core which proposes to use a hard fork to increase the maximum block size to 8 Mb and to constantly increase at a rate which doubles the maximum every two years until a final size of 8 Gb is reached.


Please note that this post is supposed to be neutral and informational. If there is anything wrong about the information, please let me know and I will fix it.

Edit: typos

[Chris!]

Think it would be easier understand if the fud was turned down a notch. Kind of the issue with anything that may alter bitcoin. Vested interests usually bark the loudest. Almost worth hunting it down on your own.

I'm hoping to just make a post with no bias, only information. I see lots of passion from people but I'm not sure what the fuss is about as of yet.

Reserving this spot, this is going to be a long one.

Haha good. Here we go

[tobacco123]

Reserving this spot, this is going to be a long one.

Really looking forward to what you are going to type! This is an important topic for the bitcoin community so I guess newbies like myself are taking the opportunity to learn more about the fundamentals of bitcoin.

[The Sceptical Chymist]

I too look forward to the responses here, as I'm somewhat of a moron when it comes to cryptography and computers.  I never participate in any of the threads dedicated to the blocksize debate because it would be gibberish.  Cheers, hope to read good stuff.

[AgentofCoin]

...
Someone needs to dumb it down for us newbies!
...

The most simplistic.

We hold the limit (stay at 1mb), in the interest of protecting the original ideals of the white paper of decentralization and etc.
The benefit is that it prevents theoretical problems that can cause Bitcoin to stray from what protects it from regulations and destruction.
The downside is it causes a slow down in mass adoption, causes filled blocks, creates higher fees, forces users to use other systems.

or

We increase the limit (higher than 1mb), in the interest of protecting the original ideals of the white paper of currency and etc.
The benefit is that it continues and allows for mass adoption, prevents filled blocks, prevents higher fees, allows users to stay on Bitcoin blockchain.
The downside is it causes the theoretical problems that can cause Bitcoin to stray from what protects it from regulations and destruction.

[kn_b_y]

Increasing the maximum block size is just one of the proposed solutions for increasing the number of transactions that the Bitcoin network can process. Alternatives include the lightning network, sidechains, and segregated witness among a variety of other proposals.
....
Bitcoin Core proposes to use segregated witness. Segregated witness is a solution to transaction malleability which has a side effect of decreasing the size of a transaction and thus increasing the number of transactions which can be put into a block. This also solves the exponential verification time problem and makes it linear.

I might be wrong about this, so please correct me. I'd be interested to know the truth...

Doesn't the segregated witness transaction malleability fix pave the way for the lightning network? They are not competing solutions, rather one enables the other.

And also, from what I understand, the blocksize reduction achieved by culling unlock scripts from transactions that segregated wintess brings will be insignificant compared to effect of the lightning network.

[achow101]

Doesn't the segregated witness transaction malleability fix pave the way for the lightning network? They are not competing solutions, rather one enables the other.

Yes, part of what segwit does is make a part of the lightning network easier to do.

None of these solutions are competing with each other, they can all coexist. It is possible to have all of these solutions at the same time, and I think that that will happen at some point in the future.

And also, from what I understand, the blocksize reduction achieved by culling unlock scripts from transactions that segregated wintess brings will be insignificant compared to effect of the lightning network.

Probably. Segwit has an effective increase as a doubling of the maximum block size. AFAIK the lightning network, and sidechains as well, could in theory go infinitely.

[btcbug]

I too have spent some time recently trying to make sense of all the craziness. See my thread here https://bitcointalk.org/index.php?topic=1396236.msg14179560#msg14179560 where I have posted a couple good articles.

[vinaha]

Since I'm a noob (status), I'd just like to say I don't give one satoshi about this non-issue drama.

[Kakmakr]

Add to that the human factors involved with the different implementations, like personal interest <Greed> and people who wants to have the power and the control and you can see why there are such huge problems, getting anything done. Some people will do anything to be the Lead team in this project and others are butt hurt because they lost that position. This issue is much deeper than the technical merit of these implementations. The human factors are the main stumbling block now. ^hmmmm^

[louisLavery]

Thanks to knightdk for putting it clearly and without bias.
Seems to me the exponential time to verify blocks needs to be solved in the long run for bitcoin to be of any real use.

[watashi-kokoto]

Why should we be giving ideas to a false flag undercover shill

[franky1]

in short:

a historic scenario that shows there was no big doomsday then so there are no doomsdays now:
in 2013 miners finally got passed a bug that allowed them to start making blocks bigger than 500k. and guess what. they instantly didnt make 0.99mb blocks continuously that very same day.
it took 2 years to grow that large. slowly and naturally without asking anyone for expanding restraints. there was no power struggle acting out an oliver twist scene ("please sir can i have some more")

current situation:
we are starting to bottleneck again and its time to expand. remember increasing the capacity is about POTENTIAL growth. not a doomsday about instant doubling of bloat. let call this a "buffer" because people cant seem to grasp that capacity is about what is capable within a cap, (potential) .. rather than the bloat doomsday of what will happen when the code is activated.

so that denounces all fears of why we should wait 2 years just to get some code activated based on bloat doomsday

next there are 12 different implementations and only one of them is core. we should not feed into the core vs classic debate, nor let only core dictate and veto any/all features the community wants.. but instead think about 2mb AND segwit together harmoniously so that its not a endless debate every 2 years with a further 2 years of waiting and delays.

2mb+segwit offers upto 4x the POSSIBLE BUFFER CAPACITY. which should allow long enough time to not need to scream at the core overlords.

also by getting it added to the April release with a grace period allows more time for people to upgrade. rather then having everyone in a mad rush to upgrade in april for segwit and then having to do it again in july.

sticking only with 1mb+segwit forever is another bad idea because it forces people to seek out less secure and centralized offchain solutions. so extra capacity onchain helps everyone. and allows freedom of choice to stay onchain or utilize offchain possibilities. rather than forcing people offchain.

delaying the code and then extending the grace period helps no one.

do not be fooled by the us vs them. and instead think both together because thats essentially what bitcoin should be, everyone together with no one in power

[Lauda]

We hold the limit (stay at 1mb), in the interest of protecting the original ideals of the white paper of decentralization and etc.
or
The downside is it causes the theoretical problems that can cause Bitcoin to stray from what protects it from regulations and destruction.

Keep in mind that one could easily argue that Bitcoin's best aspect is decentralization. It is very important that this aspect does not get harmed. The Winklevoss twins agree with this as well.

Probably. Segwit has an effective increase as a doubling of the maximum block size. AFAIK the lightning network, and sidechains as well, could in theory go infinitely.

Segwit is around 180-190% (realistic usage) which comes pretty close. The Lightning Network does have a theoretical infinite capacity, not so sure about Sidechains.

Add to that the human factors involved with the different implementations, like personal interest <Greed> and people who wants to have the power and the control and you can see why there are such huge problems, getting anything done.

There's where the urgency to go mainstream is coming from, greed.

Why should we be giving ideas to a false flag undercover shill

They will come, it is just a matter of time.

[nuevo]

Here's what I don't understand about the blocksize debate, why is it that anyone in the community insists on being right over being happy? Why can't all sides come together for the greater good? Everyone involved in bitcoin regardless of the reason is a member of the bitcoin community and while we might all have different reasons for being here, we all want sustainable growth and continued adoption. I know that all sides might have conflicting viewpoints at times and that's ok, but to say that it's all or nothing is kinda like the kid who threatens to take his ball home if he doesn't like the rules.

Arguing about the blocksize debate is like telling people they should only eat one type of pizza. Everyone has a favorite and sometimes we can convince ourselves that our personal preference is what is best for everyone. Meanwhile, those outside the pizza joint want a slice but can't get in because we in the community are too busy arguing about what fucking pizza we want to bake, so everyone will go hungry.

We understand what we want and we're all bright enough to be here, lets work together towards the common goal and stop fighting.

Maybe those who have much more say in this than me can order some fucking pizza, hack it up, and solve this shit.

The "blocksize debate" won't be the worst thing the bitcoin community endures, it's just the problem du jour.

[Jet Cash]

The thing about blocksize is that it is simplistic and trivial, and people can grasp the concept instantly. The other simplistic solution is increasing the block creation frequency, but this would mean that mining rewards will need to be adjusted at the same time. imho, both of these solutions will have to be implemented at some stage in the future, but there is no immediate need for them. The better and more sophisticated solutions are harder to comprehend, but are equally important. SegWit, sidechains and other peripheral networks are beneficial and have also been mentioned.

I believe that the core team has the ability and the foresight to enable Bitcoin to expand and grow for the future.

[franky1]

We hold the limit (stay at 1mb), in the interest of protecting the original ideals of the white paper of decentralization and etc.
or
The downside is it causes the theoretical problems that can cause Bitcoin to stray from what protects it from regulations and destruction.

Keep in mind that one could easily argue that Bitcoin's best aspect is decentralization. It is very important that this aspect does not get harmed. The Winklevoss twins agree with this as well.

Probably. Segwit has an effective increase as a doubling of the maximum block size. AFAIK the lightning network, and sidechains as well, could in theory go infinitely.

Segwit is around 180-190% (realistic usage) which comes pretty close. The Lightning Network does have a theoretical infinite capacity, not so sure about Sidechains.

Add to that the human factors involved with the different implementations, like personal interest <Greed> and people who wants to have the power and the control and you can see why there are such huge problems, getting anything done.

There's where the urgency to go mainstream is coming from, greed.

Why should we be giving ideas to a false flag undercover shill

They will come, it is just a matter of time.

lol Lauda quotes the mindset of corporate finance(winklevoss) as a voice of decentralization. is this comedy night??
the winkles want people to hand them funds to lock into a trust and use their centralized server to trade "shares" off chain..

lol lauda thinks the need for more real ONCHAIN capacity is about greed. yet its greed that wants to keep it low to artificially inflate fee's for greed then greedily push people onto centralized networks by force using the same reason. again it must be comedy night

[franky1]

There are core, classic and xt supporters. So, they will give different information and sometimes give FUD which make many people confused.
All of them have their own agenda and each of them their idea is better than others, so there's been long debate about it.

I think there's no way to tell newbie about this problem well since there are many FUD or fanboys around.

thats why 2M+segwit solves everything.
no need for a 2x POSSIBLE capacity growth based on IF people use different types of transactions. and then another TRUE capacity increase a year later IF core doesnt veto it.

its better to just have 2mb+segwit in April. with a grace period and then allow EVERYONE to have more freedom and choice because EVERY implementation has the code.. the way it should be

[STT]

Lately I've been seeing on Bitcointalk that blocks should be changed from 1mb to 2mb (or more) and people should be changing from some kind of node to another. It seems that some people have very strong opinions about one or another.

Seems to me they cant just blanket cap the size without risking restricting the transactions and creating a log jam.  Is that correct ?    I think bitcoin is a little slow but its possible this is related to integrity also so maybe not negotiable hence the upset

[btcbug]

thats why 2M+segwit solves everything.
no need for a 2x POSSIBLE capacity growth based on IF people use different types of transactions. and then another TRUE capacity increase a year later IF core doesnt veto it.

its better to just have 2mb+segwit in April. with a grace period and then allow EVERYONE to have more freedom and choice because EVERY implementation has the code.. the way it should be

I think this is definitely the most reasonable solution. Let's get this debate behind us (for now) and focus on the positives!

Do you think it's at all plausible that they will go this route?

[franky1]

thats why 2M+segwit solves everything.
no need for a 2x POSSIBLE capacity growth based on IF people use different types of transactions. and then another TRUE capacity increase a year later IF core doesnt veto it.

its better to just have 2mb+segwit in April. with a grace period and then allow EVERYONE to have more freedom and choice because EVERY implementation has the code.. the way it should be

I think this is definitely the most reasonable solution. Let's get this debate behind us (for now) and focus on the positives!

Do you think it's at all plausible that they will go this route?

many people want 2mb+segwit code in by april and fully active by around christmas.

some meander the option by trying to say its a THis or that.. just to delay any decision

some say it will take longer. some say it doesnt need 12 months but 3 months.

some dont even believe blockstream will ever put the 2mb code in alongside segwit. and when they do it will only be to cover the bloat of their extra data, like confidential payment codes. and not to allow more capacity.
basically reduce capacity with features to keep users begging blockstream for more (to make blockstreams ego grow by feeling needed)

i hope that aprils release include the 2mb+segwit and its all ready and active (passed the grace period) by christmas. and i hope blockstream dont come up with more lame excuses to delay things further.

[TKeenan]

It is simple really.  Blockstream built a thing we don't need.  They want to charge you money to use this thing.  But you don't need it.  So, they want to cripple the blockchain - so that you do need it.  They got the core developers on salary.  Those guys won't listen to reason, they listen to their boss, who pays their salary.  

Get it?

The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process.  As such, they should no longer be allowed to be custodians of the code.  They should be replaced.

[Kprawn]

It is simple really.  Blockstream built a thing we don't need.  They want to charge you money to use this thing.  But you don't need it.  So, they want to cripple the blockchain - so that you do need it.  They got the core developers on salary.  Those guys won't listen to reason, they listen to their boss, who pays their salary.  

Get it?

The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process.  As such, they should no longer be allowed to be custodians of the code.  They should be replaced.

Replaced by whom? The Gavin crowd, who until recently supported a benevolent dictatorship for Bitcoin under the XT banner? Then I would rather sail on a slower boat with a better captain. The real

debate is not the Block size, it is who will be the captain of the ship. The victor will determine the rest of the voyage for the rest of us, and I do not want a benevolent dictator behind the wheel. The

Core roadmap is clearly defined and shows the full route, where the Classic submission only shows the route to the next harbour. 

[btcbug]

It is simple really.  Blockstream built a thing we don't need.  They want to charge you money to use this thing.  But you don't need it.  So, they want to cripple the blockchain - so that you do need it.  They got the core developers on salary.  Those guys won't listen to reason, they listen to their boss, who pays their salary.  

Get it?

The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process.  As such, they should no longer be allowed to be custodians of the code.  They should be replaced.

Lightning Network is open source. How does this fit with your conspiracy theory of "they want to cripple the blockchain"?

[ATguy]

Additionally, when blocks become full, there is an idea that this will create a fee market. This essentially means that fees will increase as people have "bidding wars" with their fees to have their transactions included in a block since there would not be enough block space for all of the unconfirmed transactions. This would drive up fees and thus earn more income for miners but could potentially drive away users as the fees become too high.

This fee maket has huge drawback, these bidding wars require replace by fee feature where people resubmit their transactions with higher fees. The huge drawback comes from more data to be transferred from re-relaying the transactions over node network and the bandwidth requirement increases. "This additional bandwidth requirement can also make it difficult for more full nodes and miners to come online." - the same sentence and reason you used for bigger blocks drawback here as well, so if you have choose between continued adoption (with bigger blocks) or crippled Bitcoin (small blocks and merchants/vendors removing Bitcoin payment option because there is no space for people transactions) with both having bandwidth requirement increase drawback thus reduced decentralization, which one would you pick?

[Lauda]

Lightning Network is open source. How does this fit with your conspiracy theory of "they want to cripple the blockchain"?

It doesn't They stand to earn money with Bitcoin suceeding as well. Additionally a lot of people that spread propaganda tend to say that LN is owned by Blockstream which is completely false. There are several independent groups developing it.

Replaced by whom? The Gavin crowd, who until recently supported a benevolent dictatorship for Bitcoin under the XT banner? Then I would rather sail on a slower boat with a better captain. The real
debate is not the Block size, it is who will be the captain of the ship.

A lot of people have quickly forgotten about this. The very save people who were supporting a benevolent dictatorship in Bitcoin, are not supporting Classic with some additions. Let's not forget that Toomin said that changing the supply can/should be considered.

[franky1]

Replaced by whom? The Gavin crowd, who until recently supported a benevolent dictatorship for Bitcoin under the XT banner? Then I would rather sail on a slower boat with a better captain. The real

debate is not the Block size, it is who will be the captain of the ship. The victor will determine the rest of the voyage for the rest of us, and I do not want a benevolent dictator behind the wheel. The

Core roadmap is clearly defined and shows the full route, where the Classic submission only shows the route to the next harbour. 

there should be no captain!!!

[franky1]

Lightning Network is open source. How does this fit with your conspiracy theory of "they want to cripple the blockchain"?

the code is open source, but the most popular HUBS on the network will be controlled by corporations..

[malickie]

Everyone has their own reason why they want it one way or another.  In China's case they want the blockchain to stay at 1MB due to being behind the Great Firewall as it is called.  The issue with them would be the fact that it would take longer for them to hit a block than it currently does because it would add more data to get through their Firewall.  Although that isn't such a bad thing, it would cause Mining Power to shift a bit and would probably in all honesty make the Mining Powers more diverse than it currently is.

Raising the blockchain limit to 2MB also causes another issue with Hard Drive space.  Some people tend to think that it would create an issue for people running Nodes currently because the blockchain size would increase too much causing people to have to shut down nodes.

Either way you go about it, this whole blocksize debate is somewhat negligible.  Typical growing pains of a technology getting a lot of recognition and adoption.  Same thing happened with the internet when it first started.  There would be times people wanted to get online but couldn't due to network congestion at peak times.  More or less the same thing that is happening to the blockchain.  People want to make a transaction and can't because there are a bunch of other transactions being processed so there is a delay.  Of course now we have the internet as we know it without having to use phone lines etc.  My basic point here is that it will eventually sort itself out in the end just as the internet did, just takes some time to get things sorted out.

[franky1]

Everyone has their own reason why they want it one way or another.  In China's case they want the blockchain to stay at 1MB due to being behind the Great Firewall as it is called.  The issue with them would be the fact that it would take longer for them to hit a block than it currently does because it would add more data to get through their Firewall.  Although that isn't such a bad thing, it would cause Mining Power to shift a bit and would probably in all honesty make the Mining Powers more diverse than it currently is.

Raising the blockchain limit to 2MB also causes another issue with Hard Drive space.  Some people tend to think that it would create an issue for people running Nodes currently because the blockchain size would increase too much causing people to have to shut down nodes.

Either way you go about it, this whole blocksize debate is somewhat negligible.  Typical growing pains of a technology getting a lot of recognition and adoption.  Same thing happened with the internet when it first started.  Their would be times people wanted to get online but couldn't due to network congestion at peak times.  More or less the same thing that is happening to the blockchain.  People want to make a transaction and can't because there are a bunch of other transactions being processed so there is a delay.  Of course now we have the internet as we know it without having to use phone lines etc.  My basic point here is that it will eventually sort itself out in the end just as the internet did, just takes some time to get things sorted out.

wrong
the miners are not that worried. because all they need to do is SLOWLY take in transactions as they get relayed (not in one lump) through the great firewall (not a problem)
then inside their building the computer at the helm of the pool does the computing (handles it within the computer so doesnt care about the internet at this point)
then it sends out a short bit of code to the asics which, the asics then hash away at until they find a solution and the solution is a short bit of code too.

then the miner just needs to send out one block to the network.

secondly. although you may not realise this.. the main pool computer is not in china. just the ASICS.. so the amount of actual pools where the validation of txs are done before ASIC hashing.. is not really behind the great firewall.

so relax about that doomsday prophecy

[malickie]

Everyone has their own reason why they want it one way or another.  In China's case they want the blockchain to stay at 1MB due to being behind the Great Firewall as it is called.  The issue with them would be the fact that it would take longer for them to hit a block than it currently does because it would add more data to get through their Firewall.  Although that isn't such a bad thing, it would cause Mining Power to shift a bit and would probably in all honesty make the Mining Powers more diverse than it currently is.

Raising the blockchain limit to 2MB also causes another issue with Hard Drive space.  Some people tend to think that it would create an issue for people running Nodes currently because the blockchain size would increase too much causing people to have to shut down nodes.

Either way you go about it, this whole blocksize debate is somewhat negligible.  Typical growing pains of a technology getting a lot of recognition and adoption.  Same thing happened with the internet when it first started.  Their would be times people wanted to get online but couldn't due to network congestion at peak times.  More or less the same thing that is happening to the blockchain.  People want to make a transaction and can't because there are a bunch of other transactions being processed so there is a delay.  Of course now we have the internet as we know it without having to use phone lines etc.  My basic point here is that it will eventually sort itself out in the end just as the internet did, just takes some time to get things sorted out.

wrong
the miners are not that worried. because all they need to do is SLOWLY take in transactions as they get relayed (not in one lump) through the great firewall (not a problem)
then inside their building the computer at the helm of the pool does the computing (handles it within the computer so doesnt care about the internet at this point)
then it sends out a short bit of code to the asics which, the asics then hash away at until they find a solution and the solution is a short bit of code too.

then the miner just needs to send out one block to the network.

secondly. although you may not realise this.. the main pool computer is not in china. just the ASICS.. so the amount of actual pools where the validation of txs are done before ASIC hashing.. is not really behind the great firewall.

so relax about that doomsday prophecy

That's interesting, good insight.  Didn't know that.  Last I heard it would slow down their ability to process blocks with an increase in blocksize, although that is what I read in a semi main stream media outlet so there is that to contend with.  Knowing the actual Technicals helps, which you seem to know so at least that is helpful information.  I do appreciate your input though and it is helpful at least.

All I will say at this point is people need to research more.  The inherent problem of course is finding a reputable source or sources to take your information from.  Although honestly that is a larger problem than just Bitcoin issues.  Too many media outlets and every one of them seem to think they know exactly what they are talking about.

[gentlemand]

I think part of the problem is that 'they' don't want the debate dumbed down. Explaining what's what is somehow beneath them. The biggest issue is lack of communication.

[rizzlarolla]

I think part of the problem is that 'they' don't want the debate dumbed down. Explaining what's what is somehow beneath them. The biggest issue is lack of communication.

I'm dummin it down. stay tuned

[achow101]

a historic scenario that shows there was no big doomsday then so there are no doomsdays now:
in 2013 miners finally got passed a bug that allowed them to start making blocks bigger than 500k. and guess what. they instantly didnt make 0.99mb blocks continuously that very same day.
it took 2 years to grow that large. slowly and naturally without asking anyone for expanding restraints. there was no power struggle acting out an oliver twist scene ("please sir can i have some more")

It wasn't a bug. Rather there was a soft limit that many mining clients had from the beginning. Originally it was 250 Kb, then it was bumped to 500 Kb, then to 750 Kb, and then removed entirely. I believe this was an antispam measure that did not require forks to raise. It was just a choice of the miners to use that limit, it wasn't consensus enforced.

current situation:
we are starting to bottleneck again and its time to expand. remember increasing the capacity is about POTENTIAL growth. not a doomsday about instant doubling of bloat. let call this a "buffer" because people cant seem to grasp that capacity is about what is capable within a cap, (potential) .. rather than the bloat doomsday of what will happen when the code is activated.

Although we may be seeing a little bottleneck today, it isn't as severe as some people make it seem (except when there are spam attacks happening) and there is in fact a fairly simple solution that solves that right now: get the pools who mine empty blocks (blocks that contain no transactions except the coinbase), especially antpool in particular, to stop mining empty blocks. Or at least leave those pools for ones that do not mine empty blocks. There was an analysis done during the last spam attack that found that if just antpool had mined blocks with 1500 transactions instead of empty blocks, the entirety of the backlog would have been cleared.

It is simple really.  Blockstream built a thing we don't need.  They want to charge you money to use this thing.  But you don't need it.  So, they want to cripple the blockchain - so that you do need it.  They got the core developers on salary.  Those guys won't listen to reason, they listen to their boss, who pays their salary.  

Get it?

The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process.  As such, they should no longer be allowed to be custodians of the code.  They should be replaced.

This is the kind of FUD that is trying to be avoided.

Blockstream does not control Bitcoin Core development. Of the people who have commit access to Bitcoin Core, only one of them works at blockstream, sipa (Pieter Wuille). 1 out of 7 people who can push commits to the project works at Blockstream, I wouldn't call that control, especially since the others with commit access can revoke sipa's if they find that he does something that hurts the project. Now many of the people who work on Bitcoin Core do work at blockstream but they can only create pull requests so their changes can only be merged if one of the 7 committers commit it. This is certainly not control of the project; they can't get their changes through unless someone else commits it for them, and those others do not work at blockstream.

Another thing you need to remember is that Bitcoin Core came before blockstream was founded. Developing Bitcoin Core doesn't pay the bills, it doesn't put food on the table. The people who founded blockstream are those who worked on Bitcoin Core and needed income so that they could still be alive. The people who founded blockstream are some of Bitcoin Core's primary code writers, and they don't have a boss since they are the founders. They are the bosses, so there is no one higher up saying that they must do something to Bitcoin Core.

[madjules007]

I think part of the problem is that 'they' don't want the debate dumbed down. Explaining what's what is somehow beneath them. The biggest issue is lack of communication.

I disagree. The debate cannot be dumbed down. People are largely oversimplifying the issues to make it appear as if the answer should be obvious to everyone. It's very obvious from reading this forum and reddit that most people are ignoring the technical issues in favor of talking points. That's what happens when you "dumb down" the debate. If you want real answers, the mailing lists and IRC are a much better place to be. Sad as it is, leveling baseless insults at the other side and mischaracterizing everything they say is much more effective than engaging in honest debate here.

The answer to capacity vs. decentralization is never obvious. We basically need to use very limited data to make judgments that lack any causal proof re a system about which very little is known (no historical models). And we need to do so with regard to the system's stated principles -- i.e. to be a trustless p2p network for value exchange -- introducing all the more opaqueness as people bring their subjective philosophies to the table. The same data may mean very different things to people with wildly different opinions on the importance of decentralization.

[franky1]

It wasn't a bug. Rather there was a soft limit that many mining clients had from the beginning. Originally it was 250 Kb, then it was bumped to 500 Kb, then to 750 Kb, and then removed entirely. I believe this was an antispam measure that did not require forks to raise. It was just a choice of the miners to use that limit, it wasn't consensus enforced.

it was a bug actually. in relation to the way the database was programmed.

Although we may be seeing a little bottleneck today, it isn't as severe as some people make it seem (except when there are spam attacks happening) and there is in fact a fairly simple solution that solves that right now: get the pools who mine empty blocks (blocks that contain no transactions except the coinbase), especially antpool in particular, to stop mining empty blocks. Or at least leave those pools for ones that do not mine empty blocks. There was an analysis done during the last spam attack that found that if just antpool had mined blocks with 1500 transactions instead of empty blocks, the entirety of the backlog would have been cleared.

the "empty blocks" are not standard 10 minute average blocks, nor is it the intention to leave them empty. but luck gets in the way... let me explain..

instead what they are, are initial blocks yet to be filled because the pool is verifying a competitors solution. due to not knowing if a previous block is valid there is no point putting in data that might be in the previous block supposing its invalid. or to just put different txs in supposing its  valid..

so instead of wasting 1 minute validating a solution. they send out an empty block, and when the block is validated they start filling that empty block with new unconfirmed data. if the block fails validation they fill it with the old data

the only thing that stops then starting to fill the new block with appropriate data... is that occassionally in that 1-2 minute period of validating the previous block.. they luckily get a new solutionfor the current block(currently empty)
go check it out. look at the empty block and look at the time since the previous block. it wont be 8-12 minutes it will be 0-2 minutes..

It is simple really.  Blockstream built a thing we don't need.  They want to charge you money to use this thing.  But you don't need it.  So, they want to cripple the blockchain - so that you do need it.  They got the core developers on salary.  Those guys won't listen to reason, they listen to their boss, who pays their salary.  

Get it?

The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process.  As such, they should no longer be allowed to be custodians of the code.  They should be replaced.

This is the kind of FUD that is trying to be avoided.

Blockstream does not control Bitcoin Core development. Of the people who have commit access to Bitcoin Core, only one of them works at blockstream, sipa (Pieter Wuille). 1 out of 7 people who can push commits to the project works at Blockstream, I wouldn't call that control, especially since the others with commit access can revoke sipa's if they find that he does something that hurts the project. Now many of the people who work on Bitcoin Core do work at blockstream but they can only create pull requests so their changes can only be merged if one of the 7 committers commit it. This is certainly not control of the project; they can't get their changes through unless someone else commits it for them, and those others do not work at blockstream.

lol so adam back puts in some code. and sipa allows it.. thats basically explaining rigged elections.
its kind of funny how you say blockstream has no control. yet blockstream have pushed away bitcoinJ, pushed away alot of other implementations and want everyone to follow the blockstream roadmap..
also to point out
you think that the $55million only goes to Sipa

Another thing you need to remember is that Bitcoin Core came before blockstream was founded. Developing Bitcoin Core doesn't pay the bills, it doesn't put food on the table. The people who founded blockstream are those who worked on Bitcoin Core and needed income so that they could still be alive. The people who founded blockstream are some of Bitcoin Core's primary code writers, and they don't have a boss since they are the founders. They are the bosses, so there is no one higher up saying that they must do something to Bitcoin Core.

ok now your counteracting yourself by saying that bitcoin-core devs are paid by blockstream, you also using plurals which means deep down you know there is more then one blockstreamer in bitcoin-core..

so have a nice day and thank you for correcting youself, it made my job easy

[achow101]

it was a bug actually. in relation to the way the database was programmed.

I'm not sure about that, but since I don't feel like digging through historical code, I'll let this drop.

the "empty blocks" are not standard 10 minute average blocks, nor is it the intention to leave them empty. but luck gets in the way... let me explain..

I understand how empty blocks work and how spv mining works. I advise that you take a look through this thread: https://bitcointalk.org/index.php?topic=1085800.0 and this one: https://bitcointalk.org/index.php?topic=1389977.0 more recently.

the only thing that stops then starting to fill the new block with appropriate data... is that occassionally in that 1-2 minute period of validating the previous block.. they luckily get a new solutionfor the current block(currently empty)
go check it out. look at the empty block and look at the time since the previous block. it wont be 8-12 minutes it will be 0-2 minutes..

I have seen several blocks that are empty that are found on the normal ten minute interval. There have also been several blocks that were not empty that were found within the first two minutes.

lol so adam back puts in some code. and sipa allows it.. thats basically explaining rigged elections.
its kind of funny how you say blockstream has no control. yet blockstream have pushed away bitcoinJ, pushed away alot of other implementations and want everyone to follow the blockstream roadmap..
also to point out
you think that the $55million only goes to Sipa

And then the other core committers (and a lot of other people who follow Core development, me included) see that sipa committed some code that goes against what the Bitcoin Core plan for scaling is or it bypassed the standard procedures for committing a change. Then sipa loses his commit privilege and that commit is reverted.

ok now your counteracting yourself by saying that bitcoin-core devs are paid by blockstream, you also using plurals which means deep down you know there is more then one blockstreamer in bitcoin-core..

Not the one's with commit access. Yes, there are developers who work on Bitcoin Core and contribute heavily to it that also work at blockstream. Those people are also the ones who founded the company. Their changes must go through the peer review process and and then must be committed by one of the other committers, which is usually Wladimir (mostly him) or Jonas Schnelli (for wallet and gui stuff sometimes) who does it and those two aren't paid by Blockstream (nor are the other committers, Cory Fields, Luke-Jr, Gavin Andresen, or Jeff Garzik). If one of the blockstream developers created a PR which hurt Bitcoin and only benefited blockstream and that somehow got committed (it was NACK'd or was not ACK'd or was not reviewed by others), then obviously something is up and with the nature of git, we know exactly who did what and can act accordingly.

Fun fact, Gavin Andresen and Jeff Garzik have commit access yet they support Bitcoin Classic. Also, the debate among the technical developer community is much much less toxic, more reasonable, and the consequences (both positive and negative) of the solutions are understood by the developers.

[steeev]

such a fake thread - just total bollocks

it's like groundhog day on this forum

only solution - stick with core, as gavin and co. are, seemingly daily now, revealed in an increasingly stark light


https://bitcoinmagazine.com/articles/btcc-s-sampson-mow-on-block-size-the-bitcoin-community-must-see-through-manipulation-keep-calm-and-write-code-1458061357

oh look, it's brian coinbase ...



and gavin... err, oh dear...

http://imgur.com/a/jQEZ6

[franky1]

such a fake thread - just total bollocks

it's like groundhog day on this forum

only solution - stick with core, as gavin and co. are, seemingly daily now, revealed in an increasingly stark light

oh look, it's brian coinbase ...

and gavin... err, oh dear...

and blockstream are just as guilty

only solution. have code that does both 2mb AND segwit, then you are ready, covered and prepared for anything.
do not go blindly into that dark blockstream.
do not go blindly into that dark classic

have both code to give you buffer for any eventuality.
that way you are not being force fed by any corporation agenda

[STT]

So is it feasible to make the empty blocks not proceed until enough transactions exist, or is this too compromising to the chain standard to average out the flow of data over 24 hrs.    Theres a variation in time beyond 10 minutes before it autocorrects difficulty anyway so isnt this fairly ok to go with as a fix instead of altering size limits

[jbreher]

Please note that this post is supposed to be neutral and informational. If there is anything wrong about the information, please let me know and I will fix it.

All right, let's do this. Mostly balanced response. Just a couple issues. First mistake:

There is also a verification slowdown that is caused by large blocks. The time required to verify a block grows exponentially in relation to the block size.

The time required to verify a block does NOT grow exponentially in relation to the block size. The time required to verify a transaction does -- with current implementation -- grow exponentially in relation to the block size. One can indeed create a block consisting of a single transaction large enough to fill the block to max size, and this would be much worse in a double-sized block. But don't mistake a transaction size issue with a block size issue. There are also other ways of mitigating this problem.

Segregated witness is a solution to transaction malleability which has a side effect of decreasing the size of a transaction and thus increasing the number of transactions which can be put into a block.

No, segregated witness does nothing to decrease the size of a transaction. Instead, it actually increases transaction size by a few bytes. There is, however, accounting legerdemain involved that simply does not count part of the transaction as included in the transaction. But make no mistake - the entire transaction must still flow across the network, and the entire transaction's bytes are necessary for any validation of the transaction.