Are New Bitcoin Releases Going to Take Longer & Longer to Adopt by Majority?

[colinistheman]

Is there an increasing amount of time that each new version of bitcoin will take to saturate the network, as the number of nodes increases?

If so, will there be a point where it will take a very long time to gain majority adoption to the most up-to-date version, and we're stuck on an old version?

Example: In the year 2025 if 1 billion nodes have bitcoin software version 0.26, and version 0.27 comes out, the new version may take years (or never) reach 51+% adoption.

So does that mean there will be a point where it will not be realistic to release new versions because they will never go into effect?

And secondly, is there a solution or way to combat this increasing adoption time?

[1538088273]

1538088273

[1538088273]

1538088273

[1538088273]

1538088273

[Gavin Andresen]

I think it will depend on the release.

Adoption of 0.10.0 is looking really good: https://getaddr.bitnodes.io/dashboard/?days=90#user-agents
... going from about 3% of nodes to 12% in just the last three days.

Different versions existing on the network isn't a problem until there is some incompatible change in either the consensus code (a hard fork) or the p2p networking protocol (and even that doesn't have to be a problem if there are "bridge" nodes that speak both versions of the protocol and relay blocks/transactions across the incompatible networks).

[colinistheman]

I think it will depend on the release.

Adoption of 0.10.0 is looking really good: https://getaddr.bitnodes.io/dashboard/?days=90#user-agents
... going from about 3% of nodes to 12% in just the last three days.

Thanks for the reply, Gavin.

That chart is very useful. It does show a marked increase in adoption of this last version (0.10).

Different versions existing on the network isn't a problem until there is some incompatible change in either the consensus code (a hard fork) or the p2p networking protocol (and even that doesn't have to be a problem if there are "bridge" nodes that speak both versions of the protocol and relay blocks/transactions across the incompatible networks).

That's good that different versions isn't a problem in most cases.

But what about those cases where it is? For instance, increasing the block size limit is one example of a hard fork that is likely coming, and one that would necessitate a majority of nodes to adopt the latest version for the changes to go into effect. What if we need to change the block size limit again 5 years in the future? Will it be easy, or even possible, to get majority adoption then?

I'm looking more into the future when the number of nodes is not so small as it is today. Bitcoin nodes will eventually be on millions of devices around the world, such as routers, satellites and other machines, and not every device will get updated.

So, new versions of bitcoin would seem to be combating a greater and greater number of old versions in order to attempt to gain majority adoption, thus resulting in ever-increasing version adoption time-frames.

I'm glad this is only a concern for hard forks, but will it be a concern or problem that needs addressing, even if it's just for these rarer circumstances?

[CoinReggie]

Should the penetration of the latest version become a problem, it can be dramatically improved with (semi) automatic updates of desktop clients and availability of (semi) official binaries for various *nix flavors.

Current desktop user's are either not aware they can/should update, or they are not certain the upgrade will not mess with their wallet and they don't bother to spend time to verify that. The majority of desktop users are to lazy to upgrade, unless there is serious functionality upgrade, they are aware of.

The majority of server administrators like to yum / apt-get update daily/weekly/monthly, but when it comes to compiling the code, it takes effort to read through release/upgrade notes, backup wallet, etc, so they don't do it as frequently.

[cr1776]

Should the penetration of the latest version become a problem, it can be dramatically improved with (semi) automatic updates of desktop clients and availability of (semi) official binaries for various *nix flavors.

Current desktop user's are either not aware they can/should update, or they are not certain the upgrade will not mess with their wallet and they don't bother to spend time to verify that. The majority of desktop users are to lazy to upgrade, unless there is serious functionality upgrade, they are aware of.

The majority of server administrators like to yum / apt-get update daily/weekly/monthly, but when it comes to compiling the code, it takes effort to read through release/upgrade notes, backup wallet, etc, so they don't do it as frequently.

Automatic updates seem unlikely as a bad idea and has been discussed.  I think anything involved with Bitcoin core is covered.  But if Debian/Ubuntu/red hat package managers do their package updates quickly, that helps. :-)

Quote from: gmaxwell on September 13, 2013, 08:39:10 PM

If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

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

[CoinReggie]

Thanks for the highlight, it does make sense!

So the right answer to the original question would be: if in year 2015, after Bitcoin Core 0.27 comes out, network sticks with 0.26 for a longer period, core developers will need to scrap the changes done in 0.27 or "risk" someone taking over with a more reasonable fork.

[DeathAndTaxes]

Current desktop user's are either not aware they can/should update, or they are not certain the upgrade will not mess with their wallet and they don't bother to spend time to verify that. The majority of desktop users are to lazy to upgrade, unless there is serious functionality upgrade, they are aware of.

Outside of hardforks and critical security flaws non mining users don't necessarily need to upgrade with each version.  The declining min fee to relay is usually enough to make sure they eventually upgrade.  If it is critical that they upgrade (to avoid being forked off the main network for example) the alert messages system can be used to warn them of the danger.  Most users will at least investigate when receiving regular messages inside their client that they are in danger of losing funds.

[colinistheman]

The declining min fee to relay is usually enough to make sure they eventually upgrade.

Except there's already an automatic fee system in place, so even that won't be a motive for future users to upgrade.

If it is critical that they upgrade (to avoid being forked off the main network for example) the alert messages system can be used to warn them of the danger.  Most users will at least investigate when receiving regular messages inside their client that they are in danger of losing funds.

Yeah alert system I suppose is one way to help a major upgrade occur. Imagine hundreds of millions or billions of pieces of software all getting an alert

[cheako911]

Automatic updates seem unlikely as a bad idea and has been discussed.  I think anything involved with Bitcoin core is covered.  But if Debian/Ubuntu/red hat package managers do their package updates quickly, that helps. :-)

Debian stable will be a problem.

You'r going to have to build in a system where some config file can be altered to activate any future changes, or you can count on Debian Stable messing you up.  _,-*"Plan"*-,_ at least 3 years out!

A good goal should be to reduce or eliminate the need to replace the core code, that fits with the above constraints.


Would it be an issue to place the consensus code into a config file, some scripting language?

[DeathAndTaxes]

Yeah alert system I suppose is one way to help a major upgrade occur. Imagine hundreds of millions or billions of pieces of software all getting an alert

I am not sure what you mean by that.  Bitcoin is a gossip network.  A new alert message is no information shared node to node just like a new block, new peer, or new transaction is.