7 ms·

BIP150[0] adds peer authentication, BIP151 adds encrypted peer communication. Having them implemented and enforced is probably overdue - afaik so far i've only

by nikcub 9y ago

BIP150[0] adds peer authentication, BIP151 adds encrypted peer communication. Having them implemented and enforced is probably overdue - afaik so far i've only seen bcoin[2] implement it [0] https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0150.mediawi... [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi... [2] https://github.com/bcoin-org/bcoin https://github.com/bcoin-org/bcoin

Laforet 9y ago
None of the bitcoin core developers have much experience in network engineering nor do they recognise the importance of having robust netcode. It is no susprise that they see no urgency to address the vulns. Morever, their obsession with phasing in every change via a soft fork (i.e. updated nodes must be eternally backwards compatible with older versions) puts an unreasonable constraint on protocol development and snuffs any progress that is ever so slightly controversial.
- mitchellberry 9y ago
  > None of the bitcoin core developers have much experience in network engineering https://github.com/bitcoin/bitcoin/graphs/contributors https://github.com/bitcoin/bitcoin/graphs/contributors Many are anonymous or use psuedonoyms. Cohort easily over 100. Seems like an incredibly bold assertion to make about such a large group of developers.
  - pas 9y ago
    OP probably meant Core members: https://bitcoincore.org/en/team/ https://bitcoincore.org/en/team/
    - mitchellberry 9y ago
      The "team" section of that page doesn't contradict what I said at all.
      - Laforet 9y ago
        Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present.
        fanquake 9y ago
        "nor do they recognise the importance of having robust netcode" Refactoring of the core networking code has been ongoing for quite some time. See https://github.com/bitcoin/bitcoin/projects/4 https://github.com/bitcoin/bitcoin/projects/4. "Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present" sipa? He worked as an SRE at Google before starting work on bitcoin. [1] rustyrussell? He has done extensive work on the linux kernels networking subsystems. [2] cdecker? He did a phd at the Distributed Computing Group in Zurich which included work on scaling bitcoin. [3] gwillen? Also a SRE at Google before bitcoin, and worked on Dapper[1]. [1] https://www.linkedin.com/in/pieterwuille https://www.linkedin.com/in/pieterwuille [2] https://en.wikipedia.org/wiki/Rusty_Russell https://en.wikipedia.org/wiki/Rusty_Russell [3] https://disco.ethz.ch/alumni/cdecker https://disco.ethz.ch/alumni/cdecker [4] https://static.googleusercontent.com/media/research.google.com/en//archive/papers/dapper-2010-1.pdf https://static.googleusercontent.com/media/research.google.c...
        Laforet 9y ago
        Pieter's background is in algorithms and cryptography, he's not a networking engineer. The other people you mentioned are solid but their involvement in development is fairly peripheral, with only a handful of commits between them combined. It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along.
        EthanHeilman 9y ago
        >It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along. 1. The Bitcoin-devs rewrote the netcode quiet recently moving from a polling model to an event driven model. 2. Look at all the changes in net_processing [0]. 3. There has been a long term project to refactor and improve the netcode which has been ongoing for several years and has made massive changes to the netcode. How do I know? Over the last two years I have had to rewrite pull requests several times because the netcode has been rapidly changing. [0]: https://github.com/bitcoin/bitcoin/commits/master/src/net_processing.cpp https://github.com/bitcoin/bitcoin/commits/master/src/net_pr...
- VMG 9y ago
  > Morever, their obsession with phasing in every change via a soft fork (i.e. updated nodes must be eternally backwards compatible with older versions) This "obsession" is about the consensus layer, for very good reasons. The peer-to-peer protocol is much more flexible, and a lot of work is being done there.
  - Laforet 9y ago
    Adding authentication needs to break compatibility with older versions to be safe, or else an attacker could simply masquerade as an older client and perform an effective downgrade attack. As in what's happening with DNSSEC implementations.
    - EthanHeilman 9y ago
      When talking about breaking compatibility in Bitcoin you should recognize two district classes of compatibility. 1. Consensus compatibility i.e. that a node running the new software and a node running the old software will, when given the same blockchain, will always agree on which blocks are valid and which blocks are invalid. 2. Everything else. Breaking consensus compatibility is viewed as very risky and should only happen under extreme circumstances or under extreme agreement. Breaking backwards compatibility at the network level should be carefully thought through but it is much more likely to happen. >an attacker could simply masquerade as an older client and perform an effective downgrade attack BIP-151 is only designed to defeat a passive attacker since it does not include a way of attaching a long term identity to a node. Thus, even without a downgrade attack you can just MITM a connection and substitute your own keys. As BIP-151 says: "The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization." BIP-150 is the identity mechanism for BIP-151 however establishing the pubkey to node mapping requires out of band communication. "The identity-public-key(s) can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access."

by nikcub 9y ago

Laforet 9y ago

None of the bitcoin core developers have much experience in network engineering nor do they recognise the importance of having robust netcode. It is no susprise that they see no urgency to address the vulns. Morever, their obsession with phasing in every change via a soft fork (i.e. updated nodes must be eternally backwards compatible with older versions) puts an unreasonable constraint on protocol development and snuffs any progress that is ever so slightly controversial.

mitchellberry 9y ago
> None of the bitcoin core developers have much experience in network engineering https://github.com/bitcoin/bitcoin/graphs/contributors https://github.com/bitcoin/bitcoin/graphs/contributors Many are anonymous or use psuedonoyms. Cohort easily over 100. Seems like an incredibly bold assertion to make about such a large group of developers.
- pas 9y ago
  OP probably meant Core members: https://bitcoincore.org/en/team/ https://bitcoincore.org/en/team/
  - mitchellberry 9y ago
    The "team" section of that page doesn't contradict what I said at all.
    - Laforet 9y ago
      Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present.
      - fanquake 9y ago
        "nor do they recognise the importance of having robust netcode" Refactoring of the core networking code has been ongoing for quite some time. See https://github.com/bitcoin/bitcoin/projects/4 https://github.com/bitcoin/bitcoin/projects/4. "Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present" sipa? He worked as an SRE at Google before starting work on bitcoin. [1] rustyrussell? He has done extensive work on the linux kernels networking subsystems. [2] cdecker? He did a phd at the Distributed Computing Group in Zurich which included work on scaling bitcoin. [3] gwillen? Also a SRE at Google before bitcoin, and worked on Dapper[1]. [1] https://www.linkedin.com/in/pieterwuille https://www.linkedin.com/in/pieterwuille [2] https://en.wikipedia.org/wiki/Rusty_Russell https://en.wikipedia.org/wiki/Rusty_Russell [3] https://disco.ethz.ch/alumni/cdecker https://disco.ethz.ch/alumni/cdecker [4] https://static.googleusercontent.com/media/research.google.com/en//archive/papers/dapper-2010-1.pdf https://static.googleusercontent.com/media/research.google.c...
        Laforet 9y ago
        Pieter's background is in algorithms and cryptography, he's not a networking engineer. The other people you mentioned are solid but their involvement in development is fairly peripheral, with only a handful of commits between them combined. It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along.
        EthanHeilman 9y ago
        >It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along. 1. The Bitcoin-devs rewrote the netcode quiet recently moving from a polling model to an event driven model. 2. Look at all the changes in net_processing [0]. 3. There has been a long term project to refactor and improve the netcode which has been ongoing for several years and has made massive changes to the netcode. How do I know? Over the last two years I have had to rewrite pull requests several times because the netcode has been rapidly changing. [0]: https://github.com/bitcoin/bitcoin/commits/master/src/net_processing.cpp https://github.com/bitcoin/bitcoin/commits/master/src/net_pr...
VMG 9y ago
> Morever, their obsession with phasing in every change via a soft fork (i.e. updated nodes must be eternally backwards compatible with older versions) This "obsession" is about the consensus layer, for very good reasons. The peer-to-peer protocol is much more flexible, and a lot of work is being done there.
- Laforet 9y ago
  Adding authentication needs to break compatibility with older versions to be safe, or else an attacker could simply masquerade as an older client and perform an effective downgrade attack. As in what's happening with DNSSEC implementations.
  - EthanHeilman 9y ago
    When talking about breaking compatibility in Bitcoin you should recognize two district classes of compatibility. 1. Consensus compatibility i.e. that a node running the new software and a node running the old software will, when given the same blockchain, will always agree on which blocks are valid and which blocks are invalid. 2. Everything else. Breaking consensus compatibility is viewed as very risky and should only happen under extreme circumstances or under extreme agreement. Breaking backwards compatibility at the network level should be carefully thought through but it is much more likely to happen. >an attacker could simply masquerade as an older client and perform an effective downgrade attack BIP-151 is only designed to defeat a passive attacker since it does not include a way of attaching a long term identity to a node. Thus, even without a downgrade attack you can just MITM a connection and substitute your own keys. As BIP-151 says: "The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization." BIP-150 is the identity mechanism for BIP-151 however establishing the pubkey to node mapping requires out of band communication. "The identity-public-key(s) can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access."