The block limit will be raised. There are just no ifs or buts...

[Sukrim]

Exponential growth in block size = impossibility for average users to run a full node

Exponential growth in block size = unhappy miners = small transactions will be preferred and miners will find a max. block size themselves based on their bandwidth + ability to announce blocks

Also in other news: A server in a data center with a good CPU and a few TB storage costs far less than 100 USD per month. This does not even take into consideration potential special bitcoind hosters.

While it might be expensive, it is nothing that an average person wouldn't be able to afford. Smoking cigarettes is probably still a more expensive hobby than running a full node in a bitcoin environment with 100 MB or even 1 GB max. size blocks.

[DannyHamilton]

Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.

Yes, but these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks.

Assuming the chain that accepts larger blocks has at least 49% of the hashing power, the blockchain would most likely split as soon as the first block larger than 1MB was mined (making it immediately the "longer" chain by one block).

As long as the "small Block" Chain has more than 50% of the hashing power, wouldn't it eventually end up to be the longer chain again?

As old Nodes wouldn't accept Blocks from "Big Block" Chain the split would occur as soon as this chain has the majority (>50%)?

I might have my math messed up a bit here (it's early and I'm not much good at logical thinking in the morning), but if the "big block" chain has >49% of the hashing power and adds a block before the "small block" chain than there is roughly a 1% chance that the "small block" chain will add a block before the "big block" chain adds a second.

At that point the chains will be equal length, but the "big block" chain will have already been working on its next block for the entire time that the "small block" chain was trying to catch up.  The chance that the "small block" chain will add two blocks before the "big block" chain adds one block is something like 0.01% right?  So yes, this means that "eventually" that 0.01% chance should add up over time and the "small block" chain would pass up the "big block" chain.

However, how long is that likely to take? Is my math right if I estimate 5,000 blocks for a 50% chance of passing up the "big block" chain? Isn't that 34 days?  If the "big block" chain stays longer for a month, how many people will "jump ship" from the "small block" chain to the "big block" chain during that time if the "big block" chain is starting to look like a permanent fork?  Enough to increase the hashing percentage from >49% to >50%?  If so then it becomes likely that the "small block" chain will not catch up.

Of course, I suppose it is possible if the split stayed anywhere near 50% that the "big block" chain could remain only a few blocks ahead of the "small block" chain.  Then 6 months later with a small run of luck the "small block" chain could suddenly overtake the "big block" chain and BAM 6 months of blocks orphaned on the "big block" chain.  Since some of those inputs will have been spent elsewhere on the "small block" chain you'd have transactions lost to double-spends all over the place.  What a mess.  Seems like as soon as a "big block" was mined, a release would be quickly offered with a checkpoint to prevent something so devastating from happening, right?

[DannyHamilton]

Smaller blocks = more difficult to get your transaction verified = higher fees to get your transaction on a block.

Smaller blocks = more difficult to get your transaction verified = frustrated users = lower adoption  =  possible failure of the currency

Exponential growth in block size = impossibility for average users to run a full node = bitcoin becomes a centralized system where mining supercompanies set their own rules, ala "central bank" = FAIL

If you want superfast, near free transaction you have credit cards, or paypal-like services. Or ripple, or systems built on top of Bitcoin.

Bitcoin's value is in its decentralized nature. That's what attracted most of us. It's a secure and decentralized p2p system, and because of this it's an extremely clever store of value.

Kill the decentralized nature and you will kill bitcoin.

I don't disagree with you.  Given your thoughts on the matter though, I do however wonder what you would consider to be the "correct" blocksize?

Is 1MB too big?  Should we limit it to 500kB to increase decentralization?  How about 5MB?  Would that be ok?  How do we determine the "correct" blocksize right now, and how do we adjust the "correct" blocksize for changes in technology in the future?

[justusranvier]

Exponential growth in block size = impossibility for average users to run a full node

Better algorithms will allow average users to process a much higher transaction rate on inexpensive hardware.

https://bitcointalk.org/index.php?topic=88208.0

[markm]

Exponential growth in block size = impossibility for average users to run a full node

Exponential growth in block size = unhappy miners = small transactions will be preferred and miners will find a max. block size themselves based on their bandwidth + ability to announce blocks

Exponential growth in block size = happy megaminers = large/many transactions will be preferred and megaminers with find a minimum block size themselves based on the small fry's bandwidth and how long the small fry are willing to struggle to keep up with larger blocks before being successfully ousted from the business.

-MarkM-

[Akka]

Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.

Yes, but these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks.

Assuming the chain that accepts larger blocks has at least 49% of the hashing power, the blockchain would most likely split as soon as the first block larger than 1MB was mined (making it immediately the "longer" chain by one block).

As long as the "small Block" Chain has more than 50% of the hashing power, wouldn't it eventually end up to be the longer chain again?

As old Nodes wouldn't accept Blocks from "Big Block" Chain the split would occur as soon as this chain has the majority (>50%)?

I might have my math messed up a bit here (it's early and I'm not much good at logical thinking in the morning), but if the "big block" chain has >49% of the hashing power and adds a block before the "small block" chain than there is roughly a 1% chance that the "small block" chain will add a block before the "big block" chain adds a second.

At that point the chains will be equal length, but the "big block" chain will have already been working on its next block for the entire time that the "small block" chain was trying to catch up.  The chance that the "small block" chain will add two blocks before the "big block" chain adds one block is something like 0.01% right?  So yes, this means that "eventually" that 0.01% chance should add up over time and the "small block" chain would pass up the "big block" chain.

However, how long is that likely to take? Is my math right if I estimate 5,000 blocks for a 50% chance of passing up the "big block" chain? Isn't that 34 days?  If the "big block" chain stays longer for a month, how many people will "jump ship" from the "small block" chain to the "big block" chain during that time if the "big block" chain is starting to look like a permanent fork?  Enough to increase the hashing percentage from >49% to >50%?  If so then it becomes likely that the "small block" chain will not catch up.

Of course, I suppose it is possible if the split stayed anywhere near 50% that the "big block" chain could remain only a few blocks ahead of the "small block" chain.  Then 6 months later with a small run of luck the "small block" chain could suddenly overtake the "big block" chain and BAM 6 months of blocks orphaned on the "big block" chain.  Since some of those inputs will have been spent elsewhere on the "small block" chain you'd have transactions lost to double-spends all over the place.  What a mess.  Seems like as soon as a "big block" was mined, a release would be quickly offered with a checkpoint to prevent something so devastating from happening, right?

Well, there is a more or less simple solution for that.

As "Big block" Nodes can also accept "small block" Blocks, I would include something that somehow "markes" a Block found by a "big Block" miner. Then as soon as at least say 80% of the last 2000 Blocks are "marked", the change activates and bigger blocks are allowed. It could also start a countdown of another 2000 Blocks to give the remaining 20% time to change their mind.

[Rampion]

Smaller blocks = more difficult to get your transaction verified = higher fees to get your transaction on a block.

Smaller blocks = more difficult to get your transaction verified = frustrated users = lower adoption  =  possible failure of the currency

Exponential growth in block size = impossibility for average users to run a full node = bitcoin becomes a centralized system where mining supercompanies set their own rules, ala "central bank" = FAIL

If you want superfast, near free transaction you have credit cards, or paypal-like services. Or ripple, or systems built on top of Bitcoin.

Bitcoin's value is in its decentralized nature. That's what attracted most of us. It's a secure and decentralized p2p system, and because of this it's an extremely clever store of value.

Kill the decentralized nature and you will kill bitcoin.

I don't disagree with you.  Given your thoughts on the matter though, I do however wonder what you would consider to be the "correct" blocksize?

Is 1MB too big?  Should we limit it to 500kB to increase decentralization?  How about 5MB?  Would that be ok?  How do we determine the "correct" blocksize right now, and how do we adjust the "correct" blocksize for changes in technology in the future?

I would like a blocksize that allows the average user, with an average connection and an average computer (let's say 5 years old "personal computer") to run a full node.

I know this a non-technical, vague statement. But I think that we should work out a technical solution to achieve that.

[markm]

I don't disagree with you.  Given your thoughts on the matter though, I do however wonder what you would consider to be the "correct" blocksize?

Is 1MB too big?  Should we limit it to 500kB to increase decentralization?  How about 5MB?  Would that be ok?  How do we determine the "correct" blocksize right now, and how do we adjust the "correct" blocksize for changes in technology in the future?

2011 block size sufficed for $32 exchange rates, we have not exceeded that $32 rate in all the time since, so obviously we have plenty of space still.

In fact, we don't even use the space we have, not even half of it maybe, so if using it all cannot get us up to $64 maybe we are throwing too much money into hardware and not enough into the actual currency itself?

Up at $64 or so maybe talking about possibly doubling the size might start to make sense, then again maybe it'll be a few more years yet before we have $64-bitcoin level of actual usage?

-MarkM-

[DannyHamilton]

I don't disagree with you.  Given your thoughts on the matter though, I do however wonder what you would consider to be the "correct" blocksize?

Is 1MB too big?  Should we limit it to 500kB to increase decentralization?  How about 5MB?  Would that be ok?  How do we determine the "correct" blocksize right now, and how do we adjust the "correct" blocksize for changes in technology in the future?

2011 block size sufficed for $32 exchange rates, we have not exceeded that $32 rate in all the time since, so obviously we have plenty of space still.

In fact, we don't even use the space we have, not even half of it maybe, so if using it all cannot get us up to $64 maybe we are throwing too much money into hardware and not enough into the actual currency itself?

Up at $64 or so maybe talking about possibly doubling the size might start to make sense, then again maybe it'll be a few more years yet before we have $64-bitcoin level of actual usage?

-MarkM-

What does exchange rate have to do with any of this?  There variables here are numbers of transactions and fees per transaction.  Exchange rate shouldn't matter.  Note that the number of transactions and fees per transaction are both higher now than they were in 2011.

Due to the necessary delay involved in programming, testing, and adoption waiting until there is a problem before trying to fix it could be disastrous.

[DannyHamilton]

Well, there is a more or less simple solution for that.

As "Big block" Nodes can also accept "small block" Blocks, I would include something that somehow "markes" a Block found by a "big Block" miner. Then as soon as at least say 80% of the last 2000 Blocks are "marked", the change activates and bigger blocks are allowed. It could also start a countdown of another 2000 Blocks to give the remaining 20% time to change their mind.

Which takes me right back to the fact that the blockchain will most likely split immediately as soon as the first "big block" is mined.  There isn't likely to be a "small block" chain overtaking the "big block" chain once the first "big block" is mined if the change is implemented properly.

Chances are most of the network would upgrade to it with no questions ask. All the naysayers would be left in the dust and with a fork that wouldn't even be worth a nickel per coin.

Yes, but these new nodes would still accept the smaller blocks as well. It will only work, when the longer chain created consist of larger blocks.

[Akka]

Well, there is a more or less simple solution for that.

As "Big block" Nodes can also accept "small block" Blocks, I would include something that somehow "markes" a Block found by a "big Block" miner. Then as soon as at least say 80% of the last 2000 Blocks are "marked", the change activates and bigger blocks are allowed. It could also start a countdown of another 2000 Blocks to give the remaining 20% time to change their mind.

Which takes me right back to the fact that the blockchain will most likely split immediately as soon as the first "big block" is mined.  There isn't likely to be a "small block" chain overtaking the "big block" chain once the first "big block" is mined if the change is implemented properly.

OK, I agree here. But it wouldn't happen from one moment to the next like OP described due to

No in order to raise the Block limit, pools would need to change their version, too.

They tend to not upgrade until a new version is considered save.

[DannyHamilton]

OK, I agree here. But it wouldn't happen from one moment to the next like OP described due to

No in order to raise the Block limit, pools would need to change their version, too.

They tend to not upgrade until a new version is considered save.

And I agree here.  This is part of the reason that Satoshi suggested that the increase in blocksize be scheduled far in advance of necessity.  Schedule a blocksize increase in the next release of the reference client that takes effect with block 420,000 (the next halving four years from now).  By the time the increase is triggered, almost everybody is running software that was created in the past four years.

I don't think anybody who understands the issue is suggesting pushing out a protocol that immediately allows larger blocks.

[RodeoX]

The only people here who are confident in their opinions are those with little knowledge of the subject they are certain about.

[kokojie]

OK, I agree here. But it wouldn't happen from one moment to the next like OP described due to

No in order to raise the Block limit, pools would need to change their version, too.

They tend to not upgrade until a new version is considered save.

And I agree here.  This is part of the reason that Satoshi suggested that the increase in blocksize be scheduled far in advance of necessity.  Schedule a blocksize increase in the next release of the reference client that takes effect with block 420,000 (the next halving four years from now).  By the time the increase is triggered, almost everybody is running software that was created in the past four years.

I don't think anybody who understands the issue is suggesting pushing out a protocol that immediately allows larger blocks.

I think 420,000 is too late, we already have 500KB+ blocks from time to time. I'll bet in 6 months, every block will be 500KB+, and in 1 year all blocks will hit 1MB limit.

[molecular]

The only people here who are confident in their opinions are those with little knowledge of the subject they are certain about.

You could be correct. After reading a bit on the subject I'm not confident with my opinion any more.

[DannyHamilton]

OK, I agree here. But it wouldn't happen from one moment to the next like OP described due to

No in order to raise the Block limit, pools would need to change their version, too.

They tend to not upgrade until a new version is considered save.

And I agree here.  This is part of the reason that Satoshi suggested that the increase in blocksize be scheduled far in advance of necessity.  Schedule a blocksize increase in the next release of the reference client that takes effect with block 420,000 (the next halving four years from now).  By the time the increase is triggered, almost everybody is running software that was created in the past four years.

I don't think anybody who understands the issue is suggesting pushing out a protocol that immediately allows larger blocks.

I think 420,000 is too late, we already have 500KB+ blocks from time to time. I'll bet in 6 months, every block will be 500KB+, and in 1 year all blocks will hit 1MB limit.

Way to miss the point and focus on a completely arbitrary number.  

[johnyj]

You know what, on some of my virtual machines, I have full nodes still running bitcoin 0.3.24, if the fork day arrives, I will hope all the people run to the new chain so that I can quietly and quickly mine the rest of the coins on the original chain

[Piper67]

You know what, on some of my virtual machines, I have full nodes still running bitcoin 0.3.24, if the fork day arrives, I will hope all the people run to the new chain so that I can quietly and quickly mine the rest of the coins on the original chain

If ALL the people run to the new chain, your quickly mined coins won't be worth much.

[johnyj]

You know what, on some of my virtual machines, I have full nodes still running bitcoin 0.3.24, if the fork day arrives, I will hope all the people run to the new chain so that I can quietly and quickly mine the rest of the coins on the original chain

If ALL the people run to the new chain, your quickly mined coins won't be worth much.

It does not matter, I'm a true believer of original bitcoin, I want those coins deadly no matter what they cost 

[markm]

If the new chain is so huge that Big Brother can easily find its nodes, and/or so big that grassroots activists cannot use it without putting their machines into Big Brother's deep-disk-inspected datacentres, maybe on Big Brother's back-doors-built-into-firmware machines, then the whole point of a grass roots, alternative currency is undermined, possibly Silk Road might somehow manage to run it without being taken down but oppressed groups in terrorist/dictaroship regimes that don't have drug money to finance them might be dead in or out of the water. Moving to the new chain might be literal suicide, the cause of torture and execution of friends and loved ones ("co-conspirators", "fellow enemies of the state", etc).

-MarkM-