@steffen
2. I suppose than an element of the attack must be to somehow change some rules of the network but what if our original "satoshi vision loving" software simply refuse to work with the updated rule set? Wouldn't that make the attempted attack fail?
I see a few possible ways to attack that could be termed "changing the rules of the network", but they are not limited to an attack against our hypothetical fork, and I don't see how we could "simply refuse" them:
2.a) Denial of Service attacks focusing on a particular subset of the network, e.g. against nodes of this fork. Could be based on bandwidth starvation (like the DNS amplification DDOS we've seen), or could be based on vulnerabilities in the Bitcoin protocol (e.g. lack of authentication and encryption).
2.b) Exploiting security vulnerabilities against the client or operating systems it runs on. As for the OS's, there are always exploits in circulation, and probably the majority of Bitcoin nodes are not running on hardened installations. Someone might have been quietly charting vulnerabilities and waiting until it's profitable (e.g. one of the fork's adversaries offers a bounty to take down some nodes).
3.c) Sybil attack on the fork - swamp the network with clients that look like the fork, but are running a slightly modified version of the fork.
They can't easily change the POW function to make it easier for themselves, otherwise they'd be a complete hard fork in themselves. So it'd probably be something else, like difficulty algorithm etc.
If the Sybil nodes gain the majority, the fork is in deep trouble as it will effectively have been overtaken.
We can only detect this by monitoring the processing and comparing to what is expected according to the fork's original software. And of course monitor the p2p network for signs of trouble.
[doublepost=1457941960][/doublepost]
3. And couldn't this goal of making the attack unsuccessful be reached by (temporarily) going back to using only fully validating clients instead of using clients that just follow the longest chain (which might be created as part of an attack on the new network)?
I don't know exactly what you mean by "fully validating". I am going to assume every node that is participating has a full copy of the blockchain.
In the ideal case, we could prevent an attack by recognizing branches that are created by attackers.
However, I don't see any practical way to do that.
The assumption is that an attacker could be running the exact same software (our fork) but just with more hashpower.
So one could start to discriminate against attackers on the basis of measured hashpower.
If their branch grows too fast, it must be an attacker.
Of course, this is not necessarily true, so what one would end up doing is artificially constraining the growth of hashpower on one's fork, discouraging new miners, while the Bitcoin main chain is free to grow unrestrained. I'd say it's not a successful strategy.
[doublepost=1457942383,1457941392][/doublepost]
4. How would a typical bitcoin full node react if it was sent a new block where all included transaction are valid, and block size limit is valid but the block header version is different from the ones the node knows about? Would the block be accepted or rejected?
I think it depends on how the receiving node's software is set up to handle the case.
It could be written so it rejects all blocks that don't match a specific block version. This is what you would do if you want to create a fork that _definitely_ forks off some chain. This is what e.g. the POW fork will do.
Or a client could accept a range of block versions which are supposed to be compatible with it. This is the way that current elective hard fork versions like Classic, BU and XT work - they still process Core blocks ...