Timeline for How can we trust supply won't be increased in 2140 by just a few lines of code?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2021 at 8:09 | comment | added | Glenn Willen | 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. | |
| Jun 9, 2021 at 17:11 | comment | added | chytrik | @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. | |
| Jun 9, 2021 at 15:56 | comment | added | Matthew Ludwig | 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. | |
| Jun 9, 2021 at 15:29 | comment | added | maaw | 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. | |
| Jun 9, 2021 at 11:35 | comment | added | thevikas | @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. | |
| Jun 9, 2021 at 1:02 | comment | added | Glenn Willen | 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.) | |
| Jun 9, 2021 at 0:31 | comment | added | Moo | "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? | |
| Jun 8, 2021 at 12:03 | comment | added | akostadinov | 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. | |
| Jun 8, 2021 at 6:45 | vote | accept | thevikas | ||
| Jun 7, 2021 at 21:19 | comment | added | chytrik | @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). | |
| Jun 7, 2021 at 21:12 | comment | added | Jiminion | Small point, but wouldn't you have to change the code on just a majority of the computers? | |
| Jun 7, 2021 at 4:51 | history | answered | chytrik | CC BY-SA 4.0 |