Re: [bitcoin-dev] Planned Obsolescence
I agree that finding the right line is difficult and purposefully crippling (too strong a term?) the software is not necessarily the best way to encourage long term adoption. For example, I ran version 0.3.x from July/August 2010 for several years on a miner without upgrading to anything higher than the 0.3.24 release since the usage pattern on that machine didn't require it. It might have been to the ~0.7.0 release, I am not sure when I finally upgraded it. On a machine that had my wallet, I kept it updated, but forcing upgrades may not be the best plan given that hard forks should be few and far between. Security updates, are important, but leaving it up to the operator of the node to determine when to upgrade is an important feature. Chris On Sun, Dec 18, 2016 at 5:34 AM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > One thing which hasn't been addressed yet in this thread is developer > centralization. Unlike other applications we want to ensure that it's not > only possible for users to refuse an upgrade, but easy. While this by no > means lessens the retirement that users run up to date software for > security reasons, finding the right line to draw is difficult. > > Matt > > On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >I assume this has been well discussed in at some point in the Bitcoin > >community, so I apologize if I'm repeating old ideas. > > > >Problem exploitable nodes: > >It is plausible that people running these versions of bitcoind may not > >be applying patches. Thus, these nodes may be vulnerable to known > >exploits. I would hope none of these nodes are gateway nodes for > >miners, web wallets or exchanges. How difficult would it be to crawl > >the network to find vulnerable nodes and exploit them? What percentage > >of the network is running vulnerable versions of bitcoind? > > > >Problem eclipsable nodes: > >Currently a bitcoind node disconnects from any node with a version > >below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse > >attack because they are partitioned from the newer nodes, especially > >when they are "freshly obsolete". I have not examined how protocol > >versioning works in detail so I could be missing something. > > > >One option could be that after a grace period: > >1. to still connect to obsolete nodes and even to transmit > >blockheaders, > >2. but to stop sending the full-blocks and transactions to these > >nodes, thereby alerting the operator that something is wrong and > >causing them to upgrade. > >It may make sense to create this as a rule, if your longest chain > >consists of only blockheaders and no one will tell you the > >transactions for over 1000 blocks you are obsolete, spit out an error > >message and shutdown. > > > >This would not address the issue of alt-coins which are forked from > >old vulnerable versions of bitcoind, but that is probably out of > >scope. > > > >On Thu, Dec 15, 2016 at 1:48 PM, Jorge Timón via bitcoin-dev > >wrote: > >> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev > >> wrote: > >>> Older node versions may generate issues because some upgrades will > >make > >>> several of the nodes running older protocol versions obsolete and or > >>> incompatible. There may be other hard to predict behaviors on older > >versions > >>> of the client. > >> > >> Hard to predict or not, you can't force people to run newer software. > >> > >>> In order to avoid such wide fragmentation of "Bitcoin Core” node > >versions > >>> and to help there be a more predictable protocol improvement > >process, I > >>> consider it worth it to analyze introducing some planned > >obsolescence in > >>> each new version. In the last year we had 4 new versions so if each > >version > >>> is valid for about 1 year (52560 blocks) this may be a reasonable > >time frame > >>> for node operators to upgrade. If a node does not upgrade it will > >stop > >>> working instead of participating in the network with an outdated > >protocol > >>> version. > >> > >> When you introduce anti-features like this in free software they can > >> be trivially removed and they likely will. > >> > >>> These changes may also simplify the developer's jobs in some cases > >by > >>> avoiding them having to deal with ancient versions of the client. > >> > >> There's a simpler solution for this which is what is being done now: > >> stop maintaining and giving support for older versions. > >> There's limited resources and developers are rarely interested in > >> fixing bugs for very old versions. Users shouldn't expect things to > >be > >> backported to old versions (if developers do it and there's enough > >> testing, there's no reason not to do more releases of old versions, > >it > >> is just rarely the case). > >> ___ > >>
Re: [bitcoin-dev] Planned Obsolescence
On 12/14/2016 07:38 PM, Juan Garavaglia via bitcoin-dev wrote: For reasons I am unable to determine a significant number of node operators do not upgrade their clients. I almost did not update to 0.13.0 because the test suite was failing due to python errors. How to fix them was posted on bitcointalk. 0.13.1 came with new python errors in the test suite. So I just said fuck it. When the test suite actually works in my fairly standard environment (CentOS) in the distributed release, I will upgrade. Until then, I'm not jumping through hoops to make the test suite work and I'm not running clients that haven't passed the test suite so that's why I almost didn't update to 0.13.0 and haven't updated since. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Planned Obsolescence
One thing which hasn't been addressed yet in this thread is developer centralization. Unlike other applications we want to ensure that it's not only possible for users to refuse an upgrade, but easy. While this by no means lessens the retirement that users run up to date software for security reasons, finding the right line to draw is difficult. Matt On December 15, 2016 2:44:55 PM PST, Ethan Heilman via bitcoin-devwrote: >I assume this has been well discussed in at some point in the Bitcoin >community, so I apologize if I'm repeating old ideas. > >Problem exploitable nodes: >It is plausible that people running these versions of bitcoind may not >be applying patches. Thus, these nodes may be vulnerable to known >exploits. I would hope none of these nodes are gateway nodes for >miners, web wallets or exchanges. How difficult would it be to crawl >the network to find vulnerable nodes and exploit them? What percentage >of the network is running vulnerable versions of bitcoind? > >Problem eclipsable nodes: >Currently a bitcoind node disconnects from any node with a version >below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse >attack because they are partitioned from the newer nodes, especially >when they are "freshly obsolete". I have not examined how protocol >versioning works in detail so I could be missing something. > >One option could be that after a grace period: >1. to still connect to obsolete nodes and even to transmit >blockheaders, >2. but to stop sending the full-blocks and transactions to these >nodes, thereby alerting the operator that something is wrong and >causing them to upgrade. >It may make sense to create this as a rule, if your longest chain >consists of only blockheaders and no one will tell you the >transactions for over 1000 blocks you are obsolete, spit out an error >message and shutdown. > >This would not address the issue of alt-coins which are forked from >old vulnerable versions of bitcoind, but that is probably out of >scope. > >On Thu, Dec 15, 2016 at 1:48 PM, Jorge Timón via bitcoin-dev > wrote: >> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev >> wrote: >>> Older node versions may generate issues because some upgrades will >make >>> several of the nodes running older protocol versions obsolete and or >>> incompatible. There may be other hard to predict behaviors on older >versions >>> of the client. >> >> Hard to predict or not, you can't force people to run newer software. >> >>> In order to avoid such wide fragmentation of "Bitcoin Core” node >versions >>> and to help there be a more predictable protocol improvement >process, I >>> consider it worth it to analyze introducing some planned >obsolescence in >>> each new version. In the last year we had 4 new versions so if each >version >>> is valid for about 1 year (52560 blocks) this may be a reasonable >time frame >>> for node operators to upgrade. If a node does not upgrade it will >stop >>> working instead of participating in the network with an outdated >protocol >>> version. >> >> When you introduce anti-features like this in free software they can >> be trivially removed and they likely will. >> >>> These changes may also simplify the developer's jobs in some cases >by >>> avoiding them having to deal with ancient versions of the client. >> >> There's a simpler solution for this which is what is being done now: >> stop maintaining and giving support for older versions. >> There's limited resources and developers are rarely interested in >> fixing bugs for very old versions. Users shouldn't expect things to >be >> backported to old versions (if developers do it and there's enough >> testing, there's no reason not to do more releases of old versions, >it >> is just rarely the case). >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >___ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Planned Obsolescence
I assume this has been well discussed in at some point in the Bitcoin community, so I apologize if I'm repeating old ideas. Problem exploitable nodes: It is plausible that people running these versions of bitcoind may not be applying patches. Thus, these nodes may be vulnerable to known exploits. I would hope none of these nodes are gateway nodes for miners, web wallets or exchanges. How difficult would it be to crawl the network to find vulnerable nodes and exploit them? What percentage of the network is running vulnerable versions of bitcoind? Problem eclipsable nodes: Currently a bitcoind node disconnects from any node with a version below MIN_PEER_PROTO_VERSION. Such nodes become be ripe for an eclipse attack because they are partitioned from the newer nodes, especially when they are "freshly obsolete". I have not examined how protocol versioning works in detail so I could be missing something. One option could be that after a grace period: 1. to still connect to obsolete nodes and even to transmit blockheaders, 2. but to stop sending the full-blocks and transactions to these nodes, thereby alerting the operator that something is wrong and causing them to upgrade. It may make sense to create this as a rule, if your longest chain consists of only blockheaders and no one will tell you the transactions for over 1000 blocks you are obsolete, spit out an error message and shutdown. This would not address the issue of alt-coins which are forked from old vulnerable versions of bitcoind, but that is probably out of scope. On Thu, Dec 15, 2016 at 1:48 PM, Jorge Timón via bitcoin-devwrote: > On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev > wrote: >> Older node versions may generate issues because some upgrades will make >> several of the nodes running older protocol versions obsolete and or >> incompatible. There may be other hard to predict behaviors on older versions >> of the client. > > Hard to predict or not, you can't force people to run newer software. > >> In order to avoid such wide fragmentation of "Bitcoin Core” node versions >> and to help there be a more predictable protocol improvement process, I >> consider it worth it to analyze introducing some planned obsolescence in >> each new version. In the last year we had 4 new versions so if each version >> is valid for about 1 year (52560 blocks) this may be a reasonable time frame >> for node operators to upgrade. If a node does not upgrade it will stop >> working instead of participating in the network with an outdated protocol >> version. > > When you introduce anti-features like this in free software they can > be trivially removed and they likely will. > >> These changes may also simplify the developer's jobs in some cases by >> avoiding them having to deal with ancient versions of the client. > > There's a simpler solution for this which is what is being done now: > stop maintaining and giving support for older versions. > There's limited resources and developers are rarely interested in > fixing bugs for very old versions. Users shouldn't expect things to be > backported to old versions (if developers do it and there's enough > testing, there's no reason not to do more releases of old versions, it > is just rarely the case). > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Planned Obsolescence
Perhaps if there were a message that would nag your stdout or log output letting you know there's a new version available, or N more versions available and that you might be missing out on X security patches, Y protocol improvements, depending on how far back you are, you'd be tempted to upgrade, works for me in Ubuntu every time I log to my servers and I see how far behind I am in terms of available updates. Other thing done in open source projects to encourage updates, is to automatically distribute (download) the patches and let the node operator know an update has been downloaded for them, and let them know they're just one step away from applying such update. We do this for our bittorrent client. We don't ever want to do automatic upgrades of our network, however, we want to make it painless to update. For Bitcoin this could be done for the official binary distribution, would not be an option for those that build from source. On Thu, Dec 15, 2016 at 11:49 AM Jorge Timón via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev >wrote: > > Older node versions may generate issues because some upgrades will make > > several of the nodes running older protocol versions obsolete and or > > incompatible. There may be other hard to predict behaviors on older > versions > > of the client. > > Hard to predict or not, you can't force people to run newer software. > > > In order to avoid such wide fragmentation of "Bitcoin Core” node versions > > and to help there be a more predictable protocol improvement process, I > > consider it worth it to analyze introducing some planned obsolescence in > > each new version. In the last year we had 4 new versions so if each > version > > is valid for about 1 year (52560 blocks) this may be a reasonable time > frame > > for node operators to upgrade. If a node does not upgrade it will stop > > working instead of participating in the network with an outdated protocol > > version. > > When you introduce anti-features like this in free software they can > be trivially removed and they likely will. > > > These changes may also simplify the developer's jobs in some cases by > > avoiding them having to deal with ancient versions of the client. > > There's a simpler solution for this which is what is being done now: > stop maintaining and giving support for older versions. > There's limited resources and developers are rarely interested in > fixing bugs for very old versions. Users shouldn't expect things to be > backported to old versions (if developers do it and there's enough > testing, there's no reason not to do more releases of old versions, it > is just rarely the case). > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Planned Obsolescence
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-devwrote: > Older node versions may generate issues because some upgrades will make > several of the nodes running older protocol versions obsolete and or > incompatible. There may be other hard to predict behaviors on older versions > of the client. Hard to predict or not, you can't force people to run newer software. > In order to avoid such wide fragmentation of "Bitcoin Core” node versions > and to help there be a more predictable protocol improvement process, I > consider it worth it to analyze introducing some planned obsolescence in > each new version. In the last year we had 4 new versions so if each version > is valid for about 1 year (52560 blocks) this may be a reasonable time frame > for node operators to upgrade. If a node does not upgrade it will stop > working instead of participating in the network with an outdated protocol > version. When you introduce anti-features like this in free software they can be trivially removed and they likely will. > These changes may also simplify the developer's jobs in some cases by > avoiding them having to deal with ancient versions of the client. There's a simpler solution for this which is what is being done now: stop maintaining and giving support for older versions. There's limited resources and developers are rarely interested in fixing bugs for very old versions. Users shouldn't expect things to be backported to old versions (if developers do it and there's enough testing, there's no reason not to do more releases of old versions, it is just rarely the case). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Planned Obsolescence
Maybe there are still some advantages but I don't know why this is not considered as a major issue by the bitcoin community for the future and why this looks to be never discussed: - the size of the bitcoin network in terms of full nodes is ridiculous and this is continuously decreasing, we cannot consider the bitcoin network as a decentralized p2p network, what you are proposing is logical but will of course amplify the problem >For reasons I am unable to determine a significant number of node operators do not upgrade their clients. Why should they? What is the incentive for people to run full nodes and upgrade? FYI I am part of the 2071 0.13.1 nodes for some good reasons but will just shut it down when I am done, same for zcash (which as a matter of fact I upgraded today since by some chance I noticed some updates I was not aware of neither notified, just running it because I need it from time to time and just don't kill it so I don't have to wait for the restart process, maybe others are doing the same or just forgot that they were running a full node) Because, again, why should I or we maintain it/them? I have looked at the proposals in the past (as well as the incentive program) to reward those that are running full nodes but only found a very few, never implemented (or even considered) This is the very same for proposals allowing to start a full node from zero in an acceptable timeframe (ie not 10 days in my case) If the consensus is not to solve those two points and have a bitcoin network controlled then it would be interesting to know why, so people don't waste time trying to find solutions Satoshi himself predicted that the full nodes will get centralized, I think it's wrong, or in that case the bitcoin network cannot pretend to be a decentralized immutable system (can be compared then to the Tor network which does not pretend to be decentralized, because it is centralized, and in addition does not encourage small nodes) PS: IMHO the email notificiation system makes it difficult to follow whom is answering to whom/what on this list compared to other lists -- Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev