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.

> 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.

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.

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."

> None of the bitcoin core developers have much experience in network engineering

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.

OP probably meant Core members: https://bitcoincore.org/en/team/

The "team" section of that page doesn't contradict what I said at all.

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.

"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.

"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

[2] https://en.wikipedia.org/wiki/Rusty_Russell

[3] https://disco.ethz.ch/alumni/cdecker

[4] https://static.googleusercontent.com/media/research.google.c...

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.

>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_pr...