Block size

[readerbtc]

How easy is, for a miner, to find the place in the source code where it says "1 Mb" and remove the line?

I mean, if most miners, like 80% hashpower, decide to raise the limit of the block size, they can, right? Core developers are neither necessary for this nor can't do anything.

Or am I missing something? #sincerequestions

[1714815146]

1714815146

[1714815146]

1714815146

[1714815146]

1714815146

[1714815146]

1714815146

[1714815146]

1714815146

[piotr_n]

How easy is, for a miner, to find the place in the source code where it says "1 Mb" and remove the line?

Very easy.

I mean, if most miners, like 80% hashpower, decide to raise the limit of the block size, they can, right? Core developers are neither necessary for this nor can't do anything.

Yes - a majority of the miners can do whatever it wants with the protocol.

Or saying otherwise, which is much more important from the economical point of view:
"Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it.

[Pieter Wuille]

"Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it.

This is true for a softfork (a change where new blocks are acceptable to old software, like BIP16, BIP30 and BIP34 were).

For a hardfork (like increasing the block size limit), which is changing the rules that all full nodes already validate, you need to get those full node to agree with the upgrade, or they will not accept the change. Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway.

One way of looking at it is saying that it's the network deciding which rules they believe the system should enforce (by choosing to run software that implements those rules). Miners are just clients to the network, who create blocks satisfying the rules the network wants, and are paid for that. Miners can choose to enforce stricter rules than what is demanded by the network, however.

[DeathAndTaxes]

How hard is it to jump out of a plane?  Not hard at all.  Just open the door and jump.  Surviving the jump is the hard part.

With Bitcoin the absolute worst case scenario would be large portion of the network supports both versions after the fork.  It would be catastrophic for everyone involved.  Also miners alone can't do anything.   They need to support from users, merchants, exchanges, and developers.    Imagine for a second if 80% of miners upgraded their software so that they gave themselves 500 BTC per block instead of 25 BTC.  What would happen?  Well the network would fork.  80% of miners would be mining inflata-bitcoin and 20% would be mining standard-bitcoin.  There would be two simultaneous mutually incompatible networks.  Now the reality is 99.9% of non miners will reject the idea of boosting the block reward so they will never upgrade and the miners who switched just ended up mining some worthless altcoins.

The same thing applies to raising the block limit.  Everyone (or technically just a super majority but more is better) needs to switch. Until that happens there would be two simultaneous mutually incompatible networks.    The hard part isn't the technical code change.  The hard part is to build consensus so that when the switch occurs it will be painless.   Based on the outcome of the last hard fork (P2SH) it is a 6 month process.  This is done to ensure that when the switch occurs everyone is already "pre-upgraded".  Miners can indicate support by marking blocks with a tag.  Clients can be created which support larger blocks after some future bockheight.  Alert messages will be used to continually warn non-compliant users that they risk being forked off the majority of the network.

So like jumping out of a plane the switch itself is both easy and quick.  The hard part is the prep to ensure nobody gets hurt in the process.  If done right when the first >1MB is created almost all of the network has long since upgraded and it is anti climactic.

[readerbtc]

Thanks everybody for the answers.

[jl2012]

"Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it.

This is true for a softfork (a change where new blocks are acceptable to old software, like BIP16, BIP30 and BIP34 were).

For a hardfork (like increasing the block size limit), which is changing the rules that all full nodes already validate, you need to get those full node to agree with the upgrade, or they will not accept the change. Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway.

One way of looking at it is saying that it's the network deciding which rules they believe the system should enforce (by choosing to run software that implements those rules). Miners are just clients to the network, who create blocks satisfying the rules the network wants, and are paid for that. Miners can choose to enforce stricter rules than what is demanded by the network, however.

You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead

[hhanh00]

You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead

Well, if they do I'm sure someone will jump on the original fork and get coins at low cost when the difficulty readjusts.

[jl2012]

You are technically correct. But imagine this: now over 95% of hashing power decide to support the mega-block fork. People sticking to the original fork will have a block every 200 minutes and next adjustment will be in 280 days. So the original fork is essentially dead

Well, if they do I'm sure someone will jump on the original fork and get coins at low cost when the difficulty readjusts.

The original fork is already worthless after 280 days of stall. At the same time the remaining 5% miners will keep leaving and an adjustment may never happen. All major exchange and merchants will only accept the mega-block fork.

[hhanh00]

I don't think your scenario is plausible but you are entitled to your opinions.

[piotr_n]

For a hardfork (like increasing the block size limit), which is changing the rules that all full nodes already validate, you need to get those full node to agree with the upgrade, or they will not accept the change. Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway.

Yeah, but the value of the money and the control over the protocol is in the scarce hash values of the blocks - not in the version of a software run on full nodes.

Whether miners agree with that is not specifically relevant: the network will ignore the old miners anyway.

One way of looking at it is saying that it's the network deciding which rules they believe the system should enforce (by choosing to run software that implements those rules). Miners are just clients to the network, who create blocks satisfying the rules the network wants, and are paid for that. Miners can choose to enforce stricter rules than what is demanded by the network, however.

OK - then please define "the network".
One could get an impression that what you mean by "the network" is just nothing - some network of peers, connected by a TCP protocol, that have no economical means of existence whatsoever. The thing is that the economical part, the blockchain, the currency itself - this is run by the miners, not by some network of peers.

The TCP network is just an interface to and from the miners, so people could do the transactions by the rules set and guarded by the miners.
That's the whole point: we (the users of the currency) are just the clients to the miners.
In reality, "the network" is simply the majority of the miners - at least for me.

You disconnect your mining-minority network from the miners - they will create their own. And you know it - in fact, no better person to know it than you.
You even know that they don't need to create any new network, as they would just keep going with their own fork, using just the same network...

Or to better highlight the "problem" (it's actually a security feature, rather than a problem), let me ask you a question:
Would you accept a bitcoin payment from me, that appeared only on a branch supported by a minority of the miners, as there had been a fork, because "your network" (the one that got my transaction) refused to adapt its software the the miners' other rules?

[gmaxwell]

How easy is, for a miner, to find the place in the source code where it says "1 Mb" and remove the line?

I eagerly recommend all miners that aren't me run this patch ASAP:

Code:

diff --git a/src/main.h b/src/main.h
index 2b260a6..076d2fd 100644
--- a/src/main.h
+++ b/src/main.h
@@ -49,7 +49,7 @@ struct CBlockTemplate;
 struct CNodeStateStats;
 
 /** Default for -blockmaxsize and -blockminsize, which control the range of sizes the mining code will create **/
-static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 750000;
+static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 2000000;
 static const unsigned int DEFAULT_BLOCK_MIN_SIZE = 0;
 /** Default for -blockprioritysize, maximum space for zero/low-fee transactions **/
 static const unsigned int DEFAULT_BLOCK_PRIORITY_SIZE = 50000;
diff --git a/src/primitives/block.h b/src/primitives/block.h
index d77ab16..ef715fb 100644
--- a/src/primitives/block.h
+++ b/src/primitives/block.h
@@ -11,7 +11,7 @@
 #include "uint256.h"
 
 /** The maximum allowed size for a serialized block, in bytes (network rule) */
-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int MAX_BLOCK_SIZE = 20000000;
 
 /** Nodes collect new transactions into a block, hash them into a hash tree,
  * and scan through nonce values to make the block's hash satisfy proof-of-work

Or am I missing something? #sincerequestions

Hard forking rules aren't something that miners decide.


As far as the difficulty stranding; thats a separable problem. If the system is stuck difficulty wise then politically a hardfork to step it down shouldn't be controversial.

[piotr_n]

In fact it is some kind of monster, that we have created ourselves, that is going to decide on any further blockchain protocol changes.

You may be arguing whether is it miners, developers, users or god, that has the power to further changing the blockchain protocol.
But IMHO the most honest answer is: none of the above.
Building the extremely huge and decentralized mining infrastructure, we have essentially created a monster that has its own consciousness - and that consciousness is going to make the decisions, from now on.

And none of us, not even god himself, can do anything about it - so just deal with it.

[grau]

I eagerly recommend all miners that aren't me run this patch ASAP:

Let me guess, they said: Fork off!

[JeromeL]

Interesting thread.

If I understand correctly regarding the 1MB hardfork, if the hardfork didn't succeed, that is to say if let's say 50% of the network accepted the new fork and 50% refused to upgrade, nothing would really change until a first block is mined over 1MB. Is that correct?

[Gumbork]

Interesting thread.

If I understand correctly regarding the 1MB hardfork, if the hardfork didn't succeed, that is to say if let's say 50% of the network accepted the new fork and 50% refused to upgrade, nothing would really change until a first block is mined over 1MB. Is that correct?

really interesting, the hardfork is most likely to happen since the btc foundation is pretty close to most of those node owners, i still dont see why they wouldn't accept the new version.

[piotr_n]

really interesting, the hardfork is most likely to happen since the btc foundation is pretty close to most of those node owners,

sorry, the btc foundation is pretty close to what??
wasn't it one of its members that once proudly stated that he didn't care about mining?
well, I guess that had to have put him very close to the most of those node owners...

i still dont see why they wouldn't accept the new version.

money. the miners mine the blocks for money and they are going to do everything to keep getting the most money out of their business.
it's like with every corporation, except that the vp board of this one is totally decentralized and spread all over the world.

[johoe]

Interesting thread.

If I understand correctly regarding the 1MB hardfork, if the hardfork didn't succeed, that is to say if let's say 50% of the network accepted the new fork and 50% refused to upgrade, nothing would really change until a first block is mined over 1MB. Is that correct?

If only 50% accepted the fork, the upgraded miners would stick with small blocks and wait.  They would even reject megablocks built by miners that didn't wait. A hard fork usually is only activated if a super-majority (e.g. 80%; don't know what number the developers will choose) indicates that they would support the fork.  Only then they will start accepting and building megablocks.

[Stephen Gornick]

that consciousness is going to make the decisions, from now on.

Well, more specifically, it is the "economic majority" that decides.  This is the merchants and invest that buy the mined coins from the miners.   If they are willing to pay equal value for the coins generated in blocks mined using the changed protocol (with the larger block size) then the change happens.     If they aren't willing to buy those coins, then miners find a better deal (higher price) by sticking with protocol as it existed prior to the change.

When this happens (and I believe it probably will) it's going to be a nailbiter.  Will miners who had been running the code with the protocol changes (proven by including a new version number in the block header) get skittish if there is nobody will to pay full price for their mined coins (i.e., coins mined once the hard fork occurs)?  Since it is a possibility, they likely will be prepared to revert to the old code on-demand.

I wrote more on this possibility here:
 - http://bitcointalk.org/index.php?topic=919629.msg10118626#msg10118626

[funkenstein]

Not much need to speculate as to what happens here, seeing as we already had a network fork over exactly this issue.