public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

• * [bitcoin-dev] Planned Obsolescence
         [not found] <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
  @ 2016-12-15  3:38 ` jg
    2016-12-15 18:12   ` Aymeric Vitte
                       ` (2 more replies)
    0 siblings, 3 replies; 13+ messages in thread
  From: jg @ 2016-12-15  3:38 UTC (permalink / raw)
    To: Bitcoin Dev
  
  Today according to the stats at https://bitnodes.21.co/nodes/ the top 10 
  Bitcoin running node versions are:
  
  1.
  _Version Satoshi:0.13.1
  _Nodes 2071
  _38.97%
  
  
  2.
  _Version Satoshi:0.12.1
  _Nodes 1022
  _19.23%
  
  
  3.
  Satoshi:0.13.0
  _Nodes 604
  _11.36%
  
  
  4.
  Bitcoin Unlimited:0.12.1
  _Nodes 373
  _7.02%
  
  
  5.
  Satoshi:0.11.2
  _Nodes 183
  _3.44%
  
  
  6.
  Satoshi:0.12.0
  _Nodes 131
  _2.46%
  
  
  7. Satoshi:0.13.99
  _Nodes 122
  _2.30%
  
  
  8.
  Satoshi:0.11.0
  _Nodes 87
  _1.64%
  
  
  9.
  BTCC:0.13.1
  _Nodes 53
  _1.00%
  
  
  10.
  Satoshi:0.10.2
  _Nodes 52
  _0.98%
  
  
  Other
  _Nodes 617
  _11.61%
  
  
  There are 75 different versions of visible nodes on the network.
  
  More than 30% of the nodes running Bitcoin Core are running versions 
  older than 0.13.0.
  
  For reasons I am unable to determine a significant number of node 
  operators do not upgrade their clients.
  
  I also know newer versions require the same or fewer hardware resources 
  to run than the same network requirements as older versions of the 
  client.
  
  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.
  
  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.
  
  These changes may also simplify the developer's jobs in some cases by 
  avoiding them having to deal with ancient versions of the client.
  
  Regards
  Juan Garavaglia
  
  
  ^ permalink raw reply	[flat|nested] 13+ messages in thread

• • * Re: [bitcoin-dev] Planned Obsolescence
      2016-12-15  3:38 ` [bitcoin-dev] Planned Obsolescence jg
    @ 2016-12-15 18:12   ` Aymeric Vitte
      2016-12-15 18:48   ` Jorge Timón
      2016-12-18 20:07   ` Alice Wonder
      2 siblings, 0 replies; 13+ messages in thread
    From: Aymeric Vitte @ 2016-12-15 18:12 UTC (permalink / raw)
      To: jg, Bitcoin Protocol Discussion
    
    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
    
    
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • * Re: [bitcoin-dev] Planned Obsolescence
      2016-12-15  3:38 ` [bitcoin-dev] Planned Obsolescence jg
      2016-12-15 18:12   ` Aymeric Vitte
    @ 2016-12-15 18:48   ` Jorge Timón
      2016-12-15 22:25     ` Angel Leon
      2016-12-15 22:44     ` Ethan Heilman
      2016-12-18 20:07   ` Alice Wonder
      2 siblings, 2 replies; 13+ messages in thread
    From: Jorge Timón @ 2016-12-15 18:48 UTC (permalink / raw)
      To: jg, Bitcoin Protocol Discussion
    
    On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
    <bitcoin-dev@lists•linuxfoundation.org> 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).
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • • * Re: [bitcoin-dev] Planned Obsolescence
        2016-12-15 18:48   ` Jorge Timón
      @ 2016-12-15 22:25     ` Angel Leon
        2016-12-15 22:44     ` Ethan Heilman
        1 sibling, 0 replies; 13+ messages in thread
      From: Angel Leon @ 2016-12-15 22:25 UTC (permalink / raw)
        To: Jorge Timón, Bitcoin Protocol Discussion, jg
      
      [-- Attachment #1: Type: text/plain, Size: 3015 bytes --]
      
      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
      > <bitcoin-dev@lists•linuxfoundation.org> 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
      >
      
      [-- Attachment #2: Type: text/html, Size: 4373 bytes --]
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • * Re: [bitcoin-dev] Planned Obsolescence
        2016-12-15 18:48   ` Jorge Timón
        2016-12-15 22:25     ` Angel Leon
      @ 2016-12-15 22:44     ` Ethan Heilman
        2016-12-18 10:34       ` Matt Corallo
        1 sibling, 1 reply; 13+ messages in thread
      From: Ethan Heilman @ 2016-12-15 22:44 UTC (permalink / raw)
        To: Jorge Timón, Bitcoin Protocol Discussion
      
      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
      <bitcoin-dev@lists•linuxfoundation.org> wrote:
      > On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
      > <bitcoin-dev@lists•linuxfoundation.org> 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
      
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: [bitcoin-dev] Planned Obsolescence
          2016-12-15 22:44     ` Ethan Heilman
        @ 2016-12-18 10:34       ` Matt Corallo
          2016-12-18 20:50         ` Chris Riley
          0 siblings, 1 reply; 13+ messages in thread
        From: Matt Corallo @ 2016-12-18 10:34 UTC (permalink / raw)
          To: Ethan Heilman, Bitcoin Protocol Discussion,
        	Ethan Heilman via bitcoin-dev, Jorge Timón
        
        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
        ><bitcoin-dev@lists•linuxfoundation.org> wrote:
        >> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
        >> <bitcoin-dev@lists•linuxfoundation.org> 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
        
        
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

      • • * Re: [bitcoin-dev] Planned Obsolescence
            2016-12-18 10:34       ` Matt Corallo
          @ 2016-12-18 20:50         ` Chris Riley
            0 siblings, 0 replies; 13+ messages in thread
          From: Chris Riley @ 2016-12-18 20:50 UTC (permalink / raw)
            To: Matt Corallo, Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 5631 bytes --]
          
          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
          > ><bitcoin-dev@lists•linuxfoundation.org> wrote:
          > >> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
          > >> <bitcoin-dev@lists•linuxfoundation.org> 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
          >
          
          [-- Attachment #2: Type: text/html, Size: 7456 bytes --]
          
          ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • * Re: [bitcoin-dev] Planned Obsolescence
      2016-12-15  3:38 ` [bitcoin-dev] Planned Obsolescence jg
      2016-12-15 18:12   ` Aymeric Vitte
      2016-12-15 18:48   ` Jorge Timón
    @ 2016-12-18 20:07   ` Alice Wonder
      2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
      2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
      2 siblings, 2 replies; 13+ messages in thread
    From: Alice Wonder @ 2016-12-18 20:07 UTC (permalink / raw)
      To: bitcoin-dev
    
    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.
    
    
    ^ permalink raw reply	[flat|nested] 13+ messages in thread

  • • * [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence)
        2016-12-18 20:07   ` Alice Wonder
      @ 2016-12-18 20:51     ` Douglas Roark
        2016-12-19  8:13       ` Alice Wonder
        2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
        1 sibling, 1 reply; 13+ messages in thread
      From: Douglas Roark @ 2016-12-18 20:51 UTC (permalink / raw)
        To: bitcoin-dev
      
      
      [-- Attachment #1.1: Type: text/plain, Size: 831 bytes --]
      
      On 2016/12/18 12:07, Alice Wonder via bitcoin-dev wrote:
      > 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.
      
      Can you post more info about the problems you're seeing, how you fixed
      them, your environment, etc., or at least post an issue on Github? I'm
      sure somebody would be happy to help. Some info on how to reproduce the
      problems would be very helpful. :)
      
      Thanks.
      
      -- 
      ---
      Douglas Roark
      Cryptocurrency, network security, travel, and art.
      https://onename.com/droark
      joroark@vt•edu
      PGP key ID: 26623924
      
      
      [-- Attachment #2: OpenPGP digital signature --]
      [-- Type: application/pgp-signature, Size: 842 bytes --]
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence)
          2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
        @ 2016-12-19  8:13       ` Alice Wonder
          2016-12-21 18:33         ` Marco Falke
          0 siblings, 1 reply; 13+ messages in thread
        From: Alice Wonder @ 2016-12-19  8:13 UTC (permalink / raw)
          To: bitcoin-dev
        
        On 12/18/2016 12:51 PM, Douglas Roark via bitcoin-dev wrote:
        > On 2016/12/18 12:07, Alice Wonder via bitcoin-dev wrote:
        >> 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.
        >
        > Can you post more info about the problems you're seeing, how you fixed
        > them, your environment, etc., or at least post an issue on Github? I'm
        > sure somebody would be happy to help. Some info on how to reproduce the
        > problems would be very helpful. :)
        >
        > Thanks.
        
        For 0.13.0 I had to do
        
        export LANG=en_US.utf8
        
        before running the test suite. I build in clean chroot build environment 
        to avoid accidental linking to non-standard libraries, and in that 
        environment the LANG is normally set to C as LANG normally doesn't 
        matter for compiling software that is expected to run regardless of what 
        the LANG is.
        
        That I believe was fixed in 0.13.1.
        
        In 0.13.1 the error is
        
        
        Running test/bitcoin-util-test.py...
        Traceback (most recent call last):
           File "./test/bitcoin-util-test.py", line 12, in <module>
             "bitcoin-util-test.json",buildenv)
           File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 
        54, in bctester
             bctest(testDir, testObj, buildenv.exeext)
           File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 
        26, in bctest
             outputData = open(testDir + "/" + outputFn).read()
        FileNotFoundError: [Errno 2] No such file or directory: 
        './test/data/blanktx.json'
        make[3]: *** [check-local] Error 1
        make[3]: Leaving directory `/builddir/build/BUILD/bitcoin-0.13.1/src'
        make[2]: *** [check-am] Error 2
        make[2]: Leaving directory `/builddir/build/BUILD/bitcoin-0.13.1/src'
        make[1]: *** [check-recursive] Error 1
        make[1]: Leaving directory `/builddir/build/BUILD/bitcoin-0.13.1/src'
        make: *** [check-recursive] Error 1
        
        0.13.0 test works just fine (once the LANG is set to something utf8)
        
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

      • • * Re: [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence)
            2016-12-19  8:13       ` Alice Wonder
          @ 2016-12-21 18:33         ` Marco Falke
            0 siblings, 0 replies; 13+ messages in thread
          From: Marco Falke @ 2016-12-21 18:33 UTC (permalink / raw)
            To: Alice Wonder, Bitcoin Protocol Discussion
          
          > In 0.13.1 the error is
          >
          >
          > Running test/bitcoin-util-test.py...
          > Traceback (most recent call last):
          >   File "./test/bitcoin-util-test.py", line 12, in <module>
          >     "bitcoin-util-test.json",buildenv)
          >   File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 54,
          > in bctester
          >     bctest(testDir, testObj, buildenv.exeext)
          >   File "/builddir/build/BUILD/bitcoin-0.13.1/src/test/bctest.py", line 26,
          > in bctest
          >     outputData = open(testDir + "/" + outputFn).read()
          > FileNotFoundError: [Errno 2] No such file or directory:
          > './test/data/blanktx.json'
          
          
          This was a known problem on the *master* branch. If you still
          encounter any issues on the current 0.13.2 release candidate, please
          let us know in https://github.com/bitcoin/bitcoin/issues/9394. (Make
          sure to include the version of centos you are running)
          
          
          ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • * Re: [bitcoin-dev] Planned Obsolescence
        2016-12-18 20:07   ` Alice Wonder
        2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
      @ 2016-12-19  2:22     ` Matt Corallo
        2016-12-19  6:39       ` Btc Drak
        1 sibling, 1 reply; 13+ messages in thread
      From: Matt Corallo @ 2016-12-19  2:22 UTC (permalink / raw)
        To: Alice Wonder, Bitcoin Protocol Discussion, Alice Wonder via bitcoin-dev
      
      Please do report bugs to https://github.com/bitcoin/bitcoin . If you never report them of course they won't get fixed. I'm not aware of test suite failures and know a bunch of folks who use CentOS, though not sure how many develop on it.
      
      On December 18, 2016 12:07:36 PM PST, Alice Wonder via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      >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
      
      
      
      ^ permalink raw reply	[flat|nested] 13+ messages in thread

    • • * Re: [bitcoin-dev] Planned Obsolescence
          2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
        @ 2016-12-19  6:39       ` Btc Drak
          0 siblings, 0 replies; 13+ messages in thread
        From: Btc Drak @ 2016-12-19  6:39 UTC (permalink / raw)
          To: Matt Corallo, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
        
        Maybe something trivial like lack of Python 3 dependency on older CentOS
        builds?
        
        On Mon, Dec 19, 2016 at 2:22 AM, Matt Corallo via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > Please do report bugs to https://github.com/bitcoin/bitcoin . If you
        > never report them of course they won't get fixed. I'm not aware of test
        > suite failures and know a bunch of folks who use CentOS, though not sure
        > how many develop on it.
        >
        > On December 18, 2016 12:07:36 PM PST, Alice Wonder via bitcoin-dev <
        > bitcoin-dev@lists•linuxfoundation.org> wrote:
        > >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
        >
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        
        [-- Attachment #2: Type: text/html, Size: 2807 bytes --]
        
        ^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2016-12-21 18:40 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
2016-12-15  3:38 ` [bitcoin-dev] Planned Obsolescence jg
2016-12-15 18:12   ` Aymeric Vitte
2016-12-15 18:48   ` Jorge Timón
2016-12-15 22:25     ` Angel Leon
2016-12-15 22:44     ` Ethan Heilman
2016-12-18 10:34       ` Matt Corallo
2016-12-18 20:50         ` Chris Riley
2016-12-18 20:07   ` Alice Wonder
2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
2016-12-19  8:13       ` Alice Wonder
2016-12-21 18:33         ` Marco Falke
2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
2016-12-19  6:39       ` Btc Drak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox