SPV clients are at risk in scenarios like this. We should encourage them to check node versions against the minimum required for safety. This check should be upgraded when new BIPs go into effect. It won't help against malicious nodes. But it will help in cases such as today's.
>

On 3 Jul 2015 8:17 pm, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> > > >
>
On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn@hotmail.com> wrote:
> > We need some analysis on why this has happened. It appears the larger hashrate is violating BIP66. Thus it appears the network is rejecting this BIP, though potentially accidentally. If this is an accident, how is such a large portion of hashrate forking, and what can we do to avoid this in the future?
>
> A near majority of the hashrate on the network appears to be SPV mining.
>
> Btcnuggets was a non-upgraded miner that produced an invalid block
> after the lock in and f2pool and antpool have been extending it.
> Fortunately their extension contains no transactions (an artifact of
> SPV mining). Obviously a complete understanding is going to take some
> time; though I would note that this general failure mode was one we
> were aware of and is part of the reason the treshold is so high.
>
>
> >