<blockquote>
<p>Well, the title is the only question, how can we trust supply wont be increased by just a few lines of code?</p>
</blockquote>
<p>Just don't make any such changes to your code and you will never see an increased supply. You control the code running on your computer. If you never want to see an increased supply, never change your code in that way.</p>
<p>You can, of course, only interoperate with people who also don't want to see an increased supply. So the real issue has nothing to do with changes in code, it has to do with wanting a guarantee that there will still be people who don't want changes in the supply for you to interoperate with.</p>
<p>But you cannot ever force anyone to interoperate with you if they don't want to.</p>

CC BY-SA 4.0
2021-06-08T20:37:09.837Z
Watching Bitcoin desync because half the world wants to increase supply and half doesn't would be fun.
Joshua
CC BY-SA 4.0
2021-06-09T15:58:39.130Z
Great answer that explains in laymans terms the underlying technical details.  I especially liked the way the second paragraph is worded and the fact that it doesn't use "fork" or other technical terms.
Matthew Ludwig
CC BY-SA 4.0
2021-06-08T00:10:02.410Z
2021-06-08T00:10:02.410Z
David Schwartz
<blockquote>
<p>The bitcoin network is composed of 'bitcoin full nodes'... to change this 'coin issuance schedule', you would have to change the code running on all of those computers</p>
</blockquote>
<p>Regardless of how many times this statement is repeated (and upvoted on SE!), it is obviously wrong to anyone willing to spend even a few minutes thinking about it.</p>
<p>Except for a few special ones (like ones that happened to be running at Coinbase and other influential places like that), full nodes have no influence on the block chain whatsoever.  Nodes do not create blocks, miners do. It is the code that is running on the miners' machines that matters. And, at some point, incentives will align for the miners to do something to replace revenue from the waning block rewards, and the politics will incentivize the few influential nodes to follow this new chain since it will have the hashpower behind it (continuing to follow an underpowered chain could have disastrous results).</p>
<p>If you still believe that full nodes matter at all, consider this: there are generally <a href="https://bitnodes.io/" rel="nofollow noreferrer">10's of thousands of full nodes</a> on the network at any given moment. I could, sitting here at my desk, easily spin up 100,000 full nodes and get them integrated into the network within the next 24 hours without even maxing out my credit cards. I would then control the vast majority of full nodes. So why don't I do this? (Or more importantly, why doesn't anyone else with more resources than me do it?) Because there is no benefit to controlling any number of non-influential nodes. None. There are only a few dozen nodes on earth that matter, and they are the <em>only</em> ones that matter, and they are controlled by a small number of people who may someday have incentives to allow the increase the supply of bitcoins.</p>
<p>See longer answer here...
<a href="https://bitcoin.stackexchange.com/a/108202/113175">https://bitcoin.stackexchange.com/a/108202/113175</a></p>
<p><em>Note that it is very likely that this answer will be heavily downvoted and will attract comments vehemently scolding me for being an idiot- while never offering any actual rebuttal to my argument. This too is a signal!</em></p>

CC BY-SA 4.0
2021-10-15T21:35:21.640Z
2021-10-15T21:35:21.640Z
bigjosh
<p>The bitcoin network is composed of 'bitcoin full nodes', which are computers located all around the world, each one running independently to verify the state of the network.</p>
<p>Part of that verification includes making sure that the right number of coins are being created with each passing block, such that the total number of coins in existence is known, and predictable.</p>
<p>To change this 'coin issuance schedule', you would have to change the code running on all of those computers, so that they would all independently agree on some new issuance schedule, and could all continue to verify which blocks are valid (or not), in independent consensus. If you could only change the code on some of those computers, then those computers would start to follow blocks which the remaining bitcoin network nodes would consider invalid, effectively creating an altcoin-fork of the network (similar to what happened with 'bitcoin cash').</p>
<p>Anybody, at any point in time, could create some software that changes the issuance schedule. Thats easy. The hard part is convincing everyone that is running a bitcoin full node to switch to this new code, which creates more coins. Nobody has the authority to push such a change onto the network (top-down governance), rather it is the independent choices of all of the network's nodes (bottom-up governance) that defines the network.</p>
<p>So the answer is that you <em>don't have to trust someone</em> to not increase the supply. You just have to run some code that will <em>verify that they haven't</em>.</p>

CC BY-SA 4.0
2021-06-07T21:12:31.880Z
Small point, but wouldn't you have to change the code on just a majority of the computers?
Jiminion
CC BY-SA 4.0
2021-06-07T21:19:47.130Z
@Jiminion doing so would simply cause those computers to fork off (creating an altcoin network), & any computers running the original code would just ignore them, and continue on as normal. There is some nuance (ie, how much hashpower each network would have pointed at it), but importantly: even if a majority of nodes try to change the rules, that would not force the remaining nodes to follow suit. You may be confusing this with a majority attack, in which the attacker controls >50% of the *hashpower* (but such an attacker would not be able to arbitrarily change the network rules either).
chytrik
CC BY-SA 4.0
2021-06-08T12:03:49.520Z
The thing is that if majority ofplayers are convinced to follow the fork, then the remaining ones in the old network will be screwed. That's another thing though.
akostadinov
CC BY-SA 4.0
2021-06-09T00:31:45.517Z
_"you would have to change the code running on all of those computers"_ doesn't this happen each time the core codebase is updated for non-backward-compatible changes such as some performance, most bug fixes, the proposed switch to proof-of-stake or other reasons anyway?
Moo
CC BY-SA 4.0
2021-06-09T01:02:31.613Z
There has never (that I'm aware of) been a credible proposal to switch bitcoin to proof of stake. And no, generally speaking new releases of Bitcoin Core do _not_ contain backward-incompatible changes. (That's one of the key differences between Bitcoin and, say, Ethereum.)
Glenn Willen
CC BY-SA 4.0
2021-06-09T11:35:10.537Z
@GlennWillen Did not know this. So early bitcoin client of 2011 or before will still be valid node for all other peers and allowed to host a valid wallet? I think taproot is probably going to be change this.
thevikas
CC BY-SA 4.0
2021-06-09T15:29:54.517Z
I don't think this addresses OPs question. It's not about a "hacker" changing the code. It's about the actual code changing, for real. And I don't think there's a way around it other than hoping the demand will remain high enough to accomodate 2x the amount of coins. Pretty much like a stock split.
maaw
CC BY-SA 4.0
2021-06-09T15:56:41.367Z
I think you're missing the point of the answer, the code technically can't change for real.  The Bitcoin blockchain is made up of the network of nodes, users, businesses, etc... that operate on it.  Bitcoin could be forked, but which of the two chains is considered "Bitcoin" all comes down to what the miners and the community choose to support. The answer here is stating that the code can't change on the current network, and whatever happens with forks is probably for the best.  For examples you can look at Bitcoin and Bitcoin Cash or Ethereum and Ethereum Classic.
Matthew Ludwig
CC BY-SA 4.0
2021-06-09T17:11:33.323Z
@thevikas yes, old clients can still sync to the network (with the nuanced exception of the consensus split when bitcoin-core upgraded to levelDB in v0.8.0, iirc software older than that needs a small tweak to the database memory lock limits in order to properly sync to the network). Taproot does not change this, the taproot code is still backwards compatible. Centralized altcoins can (and do) hardfork ad infinitum, but imo it would be almost impossible to convince users to hardfork the bitcoin network without encountering some absolutely critical bug that warranted such a thing.
chytrik
CC BY-SA 4.0
2021-06-10T08:09:53.093Z
There are some technicalities -- old clients can sync the network past major changes like segwit/taproot, but they will not understand or validate scripts from the "new world" -- they will treat them as automatically true. However, they will also never generate addresses of their own which use such scripts, so this does not threaten their own security. Depending on their age, and the address format used, they may or may not be able to send to newer scripts they don't understand.
Glenn Willen
CC BY-SA 4.0
2021-06-07T04:51:05.833Z
2021-06-07T04:51:05.833Z
chytrik
<p>How can we trust supply won't be increased by just a few lines of code?</p>

CC BY-SA 4.0
2021-06-07T21:55:46.527Z
I'd say a bigger worry in 2140 would be the size of the block chain ledger and whether or not there is enough bandwidth to efficiently pass it around the internet. It's already up to 350 GB...
stix
CC BY-SA 4.0
2021-06-09T11:47:10.633Z
There are several arguments that would help quelm this. For starters, not every user on the network has to have a copy of the entire blockchain. They may only require the last $n$ blocks to sync with the network. Not every user must be a full node. The full nodes would store the entire blockchain. Additionally, Moores law states that size should not be an issue in 2140.
Hamish Gibson
CC BY-SA 4.0
2021-06-09T15:47:27.610Z
Relying on Moore's Law to solve the issue with large chain size is unrealistic, especially given that Moore's Law has slowed significantly in recent years.  I like the argument of having lighter nodes for the average user, and have seen plenty of blockchains take this approach.
Matthew Ludwig
CC BY-SA 4.0
2021-06-09T16:25:32.830Z
@HamishGibson Moore's law has both been shown to be incorrect in recent years and has nothing to do with internet transfer speeds or the cost of storage space
Bitsplease
<consensus><supply>
How can we trust supply won't be increased in 2140 by just a few lines of code?
thevikas
# How can we trust supply won't be increased in 2140 by just a few lines of code?

(Asked by: username_0 on 2021-06-07)

How can we trust supply won't be increased by just a few lines of code?

**Tags:** consensus, supply

> **Comments:**
> **username_1**: I'd say a bigger worry in 2140 would be the size of the block chain ledger and whether or not there is enough bandwidth to efficiently pass it around the internet. It's already up to 350 GB...  
> **username_2**: There are several arguments that would help quelm this. For starters, not every user on the network has to have a copy of the entire blockchain. They may only require the last $n$ blocks to sync with the network. Not every user must be a full node. The full nodes would store the entire blockchain. Additionally, Moores law states that size should not be an issue in 2140.  
> **username_3**: Relying on Moore's Law to solve the issue with large chain size is unrealistic, especially given that Moore's Law has slowed significantly in recent years.  I like the argument of having lighter nodes for the average user, and have seen plenty of blockchains take this approach.  
> **username_4**: @username_2 Moore's law has both been shown to be incorrect in recent years and has nothing to do with internet transfer speeds or the cost of storage space  

---

## 3 answers

### Answer by username_8 on 2021-06-07. Score: 24 | Accepted answer

The bitcoin network is composed of 'bitcoin full nodes', which are computers located all around the world, each one running independently to verify the state of the network.

Part of that verification includes making sure that the right number of coins are being created with each passing block, such that the total number of coins in existence is known, and predictable.

To change this 'coin issuance schedule', you would have to change the code running on all of those computers, so that they would all independently agree on some new issuance schedule, and could all continue to verify which blocks are valid (or not), in independent consensus. If you could only change the code on some of those computers, then those computers would start to follow blocks which the remaining bitcoin network nodes would consider invalid, effectively creating an altcoin-fork of the network (similar to what happened with 'bitcoin cash').

Anybody, at any point in time, could create some software that changes the issuance schedule. Thats easy. The hard part is convincing everyone that is running a bitcoin full node to switch to this new code, which creates more coins. Nobody has the authority to push such a change onto the network (top-down governance), rather it is the independent choices of all of the network's nodes (bottom-up governance) that defines the network.

So the answer is that you *don't have to trust someone* to not increase the supply. You just have to run some code that will *verify that they haven't*.

> **Comments:**
> **username_9**: Small point, but wouldn't you have to change the code on just a majority of the computers?  
> **username_8**: @username_9 doing so would simply cause those computers to fork off (creating an altcoin network), & any computers running the original code would just ignore them, and continue on as normal. There is some nuance (ie, how much hashpower each network would have pointed at it), but importantly: even if a majority of nodes try to change the rules, that would not force the remaining nodes to follow suit. You may be confusing this with a majority attack, in which the attacker controls >50% of the *hashpower* (but such an attacker would not be able to arbitrarily change the network rules either).  
> **username_10**: The thing is that if majority ofplayers are convinced to follow the fork, then the remaining ones in the old network will be screwed. That's another thing though.  
> **username_11**: _"you would have to change the code running on all of those computers"_ doesn't this happen each time the core codebase is updated for non-backward-compatible changes such as some performance, most bug fixes, the proposed switch to proof-of-stake or other reasons anyway?  
> **username_12**: There has never (that I'm aware of) been a credible proposal to switch bitcoin to proof of stake. And no, generally speaking new releases of Bitcoin Core do _not_ contain backward-incompatible changes. (That's one of the key differences between Bitcoin and, say, Ethereum.)  
> **username_0**: @username_12 Did not know this. So early bitcoin client of 2011 or before will still be valid node for all other peers and allowed to host a valid wallet? I think taproot is probably going to be change this.  
> **username_13**: I don't think this addresses OPs question. It's not about a "hacker" changing the code. It's about the actual code changing, for real. And I don't think there's a way around it other than hoping the demand will remain high enough to accomodate 2x the amount of coins. Pretty much like a stock split.  
> **username_3**: I think you're missing the point of the answer, the code technically can't change for real.  The Bitcoin blockchain is made up of the network of nodes, users, businesses, etc... that operate on it.  Bitcoin could be forked, but which of the two chains is considered "Bitcoin" all comes down to what the miners and the community choose to support. The answer here is stating that the code can't change on the current network, and whatever happens with forks is probably for the best.  For examples you can look at Bitcoin and Bitcoin Cash or Ethereum and Ethereum Classic.  
> **username_8**: @username_0 yes, old clients can still sync to the network (with the nuanced exception of the consensus split when bitcoin-core upgraded to levelDB in v0.8.0, iirc software older than that needs a small tweak to the database memory lock limits in order to properly sync to the network). Taproot does not change this, the taproot code is still backwards compatible. Centralized altcoins can (and do) hardfork ad infinitum, but imo it would be almost impossible to convince users to hardfork the bitcoin network without encountering some absolutely critical bug that warranted such a thing.  
> **username_12**: There are some technicalities -- old clients can sync the network past major changes like segwit/taproot, but they will not understand or validate scripts from the "new world" -- they will treat them as automatically true. However, they will also never generate addresses of their own which use such scripts, so this does not threaten their own security. Depending on their age, and the address format used, they may or may not be able to send to newer scripts they don't understand.  

---

### Answer by username_5 on 2021-06-08. Score: 9

> Well, the title is the only question, how can we trust supply wont be increased by just a few lines of code?

Just don't make any such changes to your code and you will never see an increased supply. You control the code running on your computer. If you never want to see an increased supply, never change your code in that way.

You can, of course, only interoperate with people who also don't want to see an increased supply. So the real issue has nothing to do with changes in code, it has to do with wanting a guarantee that there will still be people who don't want changes in the supply for you to interoperate with.

But you cannot ever force anyone to interoperate with you if they don't want to.

> **Comments:**
> **username_6**: Watching Bitcoin desync because half the world wants to increase supply and half doesn't would be fun.  
> **username_3**: Great answer that explains in laymans terms the underlying technical details.  I especially liked the way the second paragraph is worded and the fact that it doesn't use "fork" or other technical terms.  

---

### Answer by username_7 on 2021-10-15. Score: 0

> The bitcoin network is composed of 'bitcoin full nodes'... to change this 'coin issuance schedule', you would have to change the code running on all of those computers

Regardless of how many times this statement is repeated (and upvoted on SE!), it is obviously wrong to anyone willing to spend even a few minutes thinking about it.

Except for a few special ones (like ones that happened to be running at Coinbase and other influential places like that), full nodes have no influence on the block chain whatsoever. Nodes do not create blocks, miners do. It is the code that is running on the miners' machines that matters. And, at some point, incentives will align for the miners to do something to replace revenue from the waning block rewards, and the politics will incentivize the few influential nodes to follow this new chain since it will have the hashpower behind it (continuing to follow an underpowered chain could have disastrous results).

If you still believe that full nodes matter at all, consider this: there are generally [10's of thousands of full nodes](https://bitnodes.io/) on the network at any given moment. I could, sitting here at my desk, easily spin up 100,000 full nodes and get them integrated into the network within the next 24 hours without even maxing out my credit cards. I would then control the vast majority of full nodes. So why don't I do this? (Or more importantly, why doesn't anyone else with more resources than me do it?) Because there is no benefit to controlling any number of non-influential nodes. None. There are only a few dozen nodes on earth that matter, and they are the *only* ones that matter, and they are controlled by a small number of people who may someday have incentives to allow the increase the supply of bitcoins.

See longer answer here...
<https://bitcoin.stackexchange.com/a/108202/113175>

*Note that it is very likely that this answer will be heavily downvoted and will attract comments vehemently scolding me for being an idiot- while never offering any actual rebuttal to my argument. This too is a signal!*


---

