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.
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.
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."
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.
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. 
rustyrussell? He has done extensive work on the linux kernels networking subsystems. 
cdecker? He did a phd at the Distributed Computing Group in Zurich which included work on scaling bitcoin. 
gwillen? Also a SRE at Google before bitcoin, and worked on Dapper.
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 .
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.
Direct link to the paper:
How does bitcoin protect against this from happening by accident? Could someone surround my node with malicious nodes and put me on a forked chain?
Yes. You can’t know about blocks you don’t hear about. However:
1. Unless they can match the hashing power of the rest of the network, they can only publish new blocks to you at a very low rate (e.g. every 100 minutes if they have 10% of the hashing power)
2. If you connect to just a single node which tells the truth, you will discard the forked chain (again, unless the attackers can match the hash rate of the rest of the network)
All in all, proof-of-work makes it pretty easy for you to notice that something weird is happening.
> How does bitcoin protect against this from happening by accident?
You can prevent nodes from connecting to you (no inbound connections), such that you choose (randomly) which nodes to connect to. Choose a sufficiently high node count, and you’re almost certain that you don’t select a group of coordinating malicious nodes.
Side note: It would also be interesting to analyze the impact of this attack in the context of a proof-of-stake blockchain. I assume, although I’m not certain, that the attacked node would just consider the current stakers as defunct if the attackers don’t deliver blocks from them, and that the attackers would be able to become the new stakers, since the attackers would be able to censor competing staking transactions.
This sounds suspiciously like either a) choosing who to trust in advance, which negates one of the few benefits of blockchain-based cryptocurrencies that I accept exist (even if I don’t value it highly); or b) relying on random numbers being both fair and not being tampered with, even though over-reliance on that is one of the common failure modes with cryptography in general.
If you are interested I was an author on a paper which looked at the probability of choosing bad nodes, how an attacker could manipulate this and what bad things an attacker can do once they partition you from the network. Many of the countermeasures and security enhancements we proposed are now in Bitcoin making the network harder to attack.
> Could someone surround my node with malicious nodes and put me on a forked chain?
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
You can easily validate that a block is valid and has the correct PoW. For this to work an attacker needs to be mining valid blocks (expensive) and partition the bitcoin network in a way that nodes can't talk to each other (mission impossible). Then the attacker needs to make use of this split chain so that a double spend can occur. I wouldn't be that worried.
(Hint: ISP didn't block BitTorrent because of the MPAA.)
torrents are hard to hide because no matter how much encryption/obfuscation you do, you can't hide gigabytes of data being transferred between residential IPs, using random ports. bitcoin uses megabytes of data per hour, which means it's much easier to use stenography to hide it.
If we're going to defend net neutrality, we should at least understand what we're fighting for. And it's decidedly not to allow BitTorrent traffic to make real-time protocols like VOIP unreliable. It's about not letting ISPs favor one service over its competitors. And it's about making sure that an indie developer can send traffic to internet users just as fast as Google can.
Discussions on technically-informed sites like this one should get the details of net neutrality correct.