[PATCH] increase block size limit

[unamis76]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

So just because blocks will not jump overnight makes it not important to think about changing block size?

[samson]

I don't see what the big deal is with changing the maximum block size.

Why all the fuss ? It's not like blocks which are currently on average about half the current maximum size will suddenly and inexplicably jump in size overnight just because it's possible.

So just because blocks will not jump overnight makes it not important to think about changing block size?

No, you misread my post.

[slaveforanunnak1]

I wonder if Satoshi ever talk about payment-channels ?

[ammy009]

this patch is included in XT bitcoin wallet ... I guess

[coins101]

I've been sitting on the fence a bit trying to figure out what's what.

Having deployed a payment service intended for mass use inside one of the top 3 global retailers, you do need to plan ahead for optimistic outcomes and always keep the end users experience with your product in your sights.

I have come to the conclusion that while you don't need to update now, or possibly not for another year, the sooner you do it the less of an impact it will be for new adopters.

What is being discussed here is that we should wait until Bitcoin becomes more popular before making a hard fork. That's precisely the wrong time to do it.

Do it in anticipation of more transactions so that people coming to Bitcoin won't be reading news stories about a major upgrade that might cause problems.

We also have to consider that nearly $1bn in VC money is going in to development. That investment will soon see new services pouring out and those firms will all have promotional money. The last thing they would want is to start a promotional push, and then face the same situation of having to tell their users that a major update is needed and the update carries some risks.

I think that a hard fork should be made in line with BIP100. The hard fork should carry 1mb blocks as a starting point, but with some dynamic scaling options using just in time delivery to enable soft forking for increasing blocks sizes when capacity increases are required.

This should be part of a series of moves that seeks to take Bitcoin out of Beta.  Removing the limit means that the protocol can scale to Visa levels and beyond.

The introduction of Sidechains and Lightning networks means that capacity can be co-managed with micro-payment and off chain channels doing some of the heavy lifting. A dynamic model allows for these systems to work alongside Bitcoin block size planning.

Bitcoin is no longer a proof of concept project. The concept has been proven. Bitcoin Core 0.11 should be the last beta release cycle. Sidechains and Lightning type networks should be dovetailed to work with an eventual Bitcoin Core 1.0 production ready release.

edit

https://bitcoin.org/en/alert/2015-07-04-spv-mining

[puck2]

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

Prescient