Am I mistaken, or is there a significant financial incentive for non-SPV mining pools to get their miners to mine a block that will send SPV mining pools onto a bad fork?

Doing so would cut the hash power of the network nearly in half for a short period of time (either until the non-SPV fork exceeds the length of the SPV fork, or until the SPV pools notice the problem and switch to the correct fork) which should double the chances of the non-SPV pools finding blocks until the SPV mining pools get themselves back on to the correct fork.

If all of the non-SPV pools continuously send the SPV pools off on forks that will get orphaned, then they will all increase their own revenue and destroy the revenue (and incentive) for SPV mining, right?

Furthermore, all the mining participants that are participating in SPV pools will see their personal revenue drop to miniscule levels.  As such, they will have very strong financial incentive to leave the SPV pools and join one of the non-SPV pools. This will increase the number of participants (and the total hash power) of the non-SPV pools and will therefore eventually reduce the length of the orphaned chains.

If non-SPV pools implement this, isn't this SPV mining dis-incentive likely to outweigh the incentives of SPV mining?  As such, wouldn't any pool that wants to remain relevant be forced to switch to non-SPV mining?

Hmmm, difficulty remains the same though. It could work if a huge miner kept some (otherwise uneconomic) idle hashing power in wait, to be deployed only when a chain fork is detected.

Difficulty only remains the same until the next adjustment.  Then it will decrease, since a significant percentage of the network has been continuously participating in orphaned chains.

Meanwhile, the miners that leave the SPV pools (due to inadequate revenue) and join the non-SPV pools will increase the hashing power of the non-SPV pools.  This is the "idle hashing power" you are talking about, isn't it?  Hash power that the non-SPV pools don't have right now, but which they gain as the attack progresses?

I agree.  Which is why I presented it as a response to this thread...


If I ran my own mining pool, I would be giving some serious consideration to implementing this attack right now.

I considered this too, but it depends on your definition of "waste". The progenitor of the attack stands to gain both financially and in esteem (and also builds overall confidence in the network), whether by attracting independent miners from SPV pools, or by infilling with spare hashing capacity. It's true that there will be a critical hashrate below which creating attack/invalid blocks represents too large a proportion of the blocks they do find such that they can write it off against the potential gains, but miners/pools of that size can still gain marginally from another miner conducting the attack, as long as they're also verifying new blocks.

How much hashing power was supporting the fork?  I only saw AntMiner, F2Pool and BTCNugget, which have less than 50 % together.  Wouldn't the fork have stopped automatically when these pools ran out of "luck" and the remaining network caught up?  We'll probably never know who of the smaller pools would have supported the wrong chain.

The 150 BTC reward that these pools lost is not really lost; they will be reflected in a slightly smaller difficulty soon and thus evenly distributed between all pools.  Also, the 100 BTC f2pool lost is probably less than what they gained by their dangerous tactic of mining on the longest chain without verifying it.

However, it's hard to say how much they really gain with their "SPV-mining" strategy.  The orphan rate would be higher, but this would apply for the other pools as well. Sometimes they would produce a block on the old parent that gets orphaned immediately, sometimes they orphan the block of another miner that didn't distribute fast enough.  Since China has most mining power, maybe the big Chinese pools would even profit from this higher orphan rate, when the difficulty is adjusted.

do you guys  think that current ASICs or GPUs could speed up block validation?
Currently (as far as I'm aware) bitcoind  only uses CPUs.

May be including GPU support to bitcoind  it could solve the problem, by
simply making verification time negligible.

I thought the block transmission time problem was solved by the relay network. The one that
allows miners that found a block  only transmit txs that are not in the mempool.
I'm not sure how widely it's used though.

sure, but if the validation time is reduced to milliseconds then it's a negligible expenditure

With a timeout SPV-mining is actually good for the health of the network, since it drops the orphan rate to almost zero.  Miners should be encouraged to do it not discouraged.

If 50% of miners produce 10% of bad blocks, then the profits are as follows

Non-SPV coalition:
Output: 50% * 90% = 45%

SPV-coalition:
Bad previous block (10%)
1 minute out of 10 of wasted hashing
9 minutes out of 10 of valid hashing
Output: 50% * 90% * 10% = 4.5%

Good previous block (90%)
10 minutes of valid hashing
Output: 50% * 100% * 90% = 45%

Total outpout: 49.5%

The SPV effective miner's hash rate only drops from 50% to 49.5%.  The attacking coalition drops from 50% to 45%.  This means that the SPV-miners get 49.5/(49.5 + 45) = 52.4% of the blocks for 50% of the hashing power.

The attack causes the SPV-miners block rate to drop from 50% to 49.5% and then after the next difficulty adjustment they get 52.4% of the blocks.

The attackers go from 50% of the blocks to 45% of the blocks and then to 47.6% after the next difficulty update.

SPV mining is safe if there is a timeout (say 1 minute).

The problem was that the SPV-miners kept building more and more blocks on top of the invalid chain.  If they had a rule that said if the fully validated chain doesn't catch up with the SPV chain within 1 minute switch back to non-SPV mining, then the fork would never have happened.

The SPV-miners would have mined on the bad block for one minute and then switch back to mining on the good fork.