user119822: Is it possible for 51% of the Bitcoin nodes to pool and vote to increase the money supply limit? Is that allowed in the protocol?

user5406: The reward schedule is a consensus rule in the Bitcoin network. Consensus rules are enforced by each full node independently. Node operators choose which consensus rules they enforce per the Bitcoin implementation they are running.
If a subset of the nodes were to increase the block subsidy, this would be a hardfork: a non-forward compatible consensus rule change.
Blocks following the new rules with a higher block subsidy would be in conflict with the original rules and invalid to any nodes that did not update to the new rule set. Depending on whether either one, the other, or both resulting p2p networks have sufficient hashrate, this would potentially split the network irreconcilably, as nodes allowing the new higher reward would get disconnected and banned for sending invalid data by nodes enforcing the original rules. Since the old rules remain a subset of the new rules, a majority of the hashrate siding with the old rules would wipe-out the chain with new rules as nodes with new rules would follow that chain. Every new block with new rules would interrupt the node topology again, though.
It is irrelevant how many nodes are participating in the rule change. Nodes enforcing the original rules would never follow the chain with new blocks, the only way to switch over to the new rules would be by switching to new client software that implements the new rules. The node count would also only indirectly affect the survival of the competing chains as that would chiefly depend on which ruleset garners the majority of the hashrate, which in itself would depend on the rules that are adopted by the economic majority and user population.

119822: <p>Is it possible for 51% of the Bitcoin nodes to pool and vote to increase the money supply limit? Is that allowed in the protocol?</p>
 5406: <p>The reward schedule is a consensus rule in the Bitcoin network. Consensus rules are enforced by each full node independently. Node operators choose which consensus rules they enforce per the Bitcoin implementation they are running.</p>
<p>If a subset of the nodes were to increase the block subsidy, this would be a hardfork: a non-forward compatible consensus rule change.<br />
Blocks following the new rules with a higher block subsidy would be in conflict with the original rules and invalid to any nodes that did not update to the new rule set. Depending on whether either one, the other, or both resulting p2p networks have sufficient hashrate, this would potentially split the network irreconcilably, as nodes allowing the new higher reward would get disconnected and banned for sending invalid data by nodes enforcing the original rules. Since the old rules remain a subset of the new rules, a majority of the hashrate siding with the old rules would wipe-out the chain with new rules as nodes with new rules would follow that chain. Every new block with new rules would interrupt the node topology again, though.</p>
<p>It is irrelevant how many nodes are participating in the rule change. Nodes enforcing the original rules would never follow the chain with new blocks, the only way to switch over to the new rules would be by switching to new client software that implements the new rules. The node count would also only indirectly affect the survival of the competing chains as that would chiefly depend on which ruleset garners the majority of the hashrate, which in itself would depend on the rules that are adopted by the economic majority and user population.</p>
