Topic: "SPV Mining" or mining on invalidated blocks (Read 3442 times)

1 confirm transactions aren't affected, since SPV-mining causes empty blocks when they haven't fully validated.  The issue is for 2 confirm transactions, where the 2nd block is an empty block.

If the timeout was also block based too, then the fork length could be restricted.

A rule could be added that the (great-)grandparent of the empty block must have been fully validated.

This would mean that 6 confirm transactions are still solid, since they are larger than that maximum fork.

For low confirms, SPV clients could use the timing of the headers.  If you receive 2 headers within 60 seconds of each other, then the 2nd header doesn't count as an additional confirm.  The confirm count could be min(confirms, (last_confirm_time - first_confirm_time) / 5 mins).

According to reddit, some of the SPV-miners didn't even have the headers they were building on.  They were pretending to be hashers and connecting to other pools.  When those pools updated their clients, they switched to building on the new block too by extracting the previous pointer for the stratum info send to hashers.

If miners are going to do that, maybe the reference client should be updated to broadcast the headers of new blocks in advance of the block.  It may give bad incentives, but it is arguably better than SPV-miners becoming blind-miners.

Blind miners can't do block based timeout properly, since they can't link the headers into a chain.  It also leads to pools trying to figure out which of their hashers are actually other pools, and sending then bad work data.

It's not safe SPV clients; its surely less unsafe, but it still undermines the security assumptions behind SPV clients... undermines it less.

Let me understand ... The member of F2Pool which is an Antpool plant, sees that F2Pool has a block (F2Pool sends an update message containing a hash) and immediately transmits the particulars (the hash) to Antpool, at the same time that F2Pool starts mining on the new hash.  

Now, we suppose that F2Pool sets an "SPV trap" by occasionally announcing a bogus hash. So all of their members (including the Antpool plant) switch to mining on the new hash - along with all the members of Antpool.  

Now F2Pool and Antpool are both mining on a bogus hash and losing money.  The difference is F2Pool knows the hash is bogus.  It wants to switch its miners back to mining on the real hash.

How does it do that without tipping off whichever of its members are Antpool plants?

Yeah.  If a majority is doing full validation mining, then the valid chain will grow faster than the invalid one, so invalid forks won't last long.

Even then, if a significant fraction is doing SPV-mining, then more confirmations are needed to get the same transaction confidence.

The problem with SPV-mining is that it can cause a majority of the hashing power to effectively skip validation.  Security of the network means that they should have a timeout and switch back to full mining if the full block associated with the header is not received.

does this mean a majority of the entire network and is what happened last night?

TierNolan thanks for the explanation. That seems like a really good system

Think of it that the mining pool has 2 nodes, an SPV node and a fully validating node.  The block generation core is connected to both nodes, though an arbitration node.

Headers are in lower case and full blocks are in upper case.

Normally, both SPV and the full node agree.


Block D is found, so the miner broadcasts d (the header) and then broadcasts D.

The header d is received first


At this stage, the arbitrator says that the two nodes disagree, so the pool mines empty blocks on d.

Soon after, block D arrives and is validated.


The two nodes are back in agreement.  This means that the pool mines full blocks (including transactions) on D.

The benefit is that any hashing done between when d is received and when D is received is not wasted.  It can be used to find empty blocks (which still pay the minting fee).

The problem is what happens if an invalid block is found.

In this case, a miner finds E but it is bad, it also broadcasts e.


The problem is that, since E is bad, it is not accepted by the full node.  This means that the header-only/empty block chain stays ahead.

If a majority is SPV-mining, then they will build f, g, h and so on.  These are all empty blocks.


A timeout prevents this.  The pool will only mine on e with empty blocks for one minute.  Once it sees that block E is invalid or if it doesn't arrive, it switches to building on D again.

Block E* is found by one of those miners and e* is broadcast.

e* is received but it doesn't become the main SPV chain, since it was received later than e.


Soon afterwards E* is received.


The SPV node and the full node still disagree, so the miner stays in non-SPV mode.

Eventually, a miner builds on E* producing F.  He broadcasts f and then F.


and then F is received and validated.


At this point, SPV mining can be reactivated, since both nodes agree on the longest chain again.

It would have been safe to switch back once e* was received though.

Build empty blocks on a block header if

• The header is the longest chain (ties allowed)
• The header was received less than 1 minute ago
• The header chain is longer than the fully validated chain
• The header is the earliest received header that meets the previous rules

Does that mean that SPV miners would jump on the next block and verify it while mining, and if the block was proven to be invalid they would switch to the correct chain? That would be the best of both worlds, I think.

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.

I am also of the opinion that SPV mining should me deincentivized... To begin with, this will only result in pools trying to attack themselves, as DannyHamilton referred. Besides that, would we risk having non valid blocks and lots of forks in near future? This one wasn't all that serious, and devs were here to help at the time and immediately took action... But what if no one was monitoring?

And we also don't know about the future. there may be more strict blocks rules from now on and breaking them might make a huge fork... I don't think that's worth risking for more mining profit, or less wasted hashrate.

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.

I think this is the crucial calculation for someone who's running a big, non-spv mining pool.  From what I could tell, Danny H's attack seems like it has just been shown that it would work (we just saw it go down), and so the only real question is how much you'd have to "waste" by finding the bad blocks that you're going to throw at the spv-miners to send them down the wrong path.

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

It isn't entirely validation speed.  It also includes network bandwidth to actually forward the block.

No matter how fast validation is, just validating the block header is going to be much faster.  Checking POW is very fast and sending 80 bytes of data is much faster than sending up to 1MB of data.

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 think they moved 2 blocks ahead by luck (the bad block was built on) and then were able to stay ahead for a while.

With 48% of the hashing power and a 2 block lead, it would take around 50 blocks for the 52% side to catch up, on average.

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.

It depends on the bad block rate and normal orphan rate.

With a 5% orphan rate, that means that miners are spending 30 seconds per block validating new blocks.  This is 30 seconds of wasted hashing.

If 10% of blocks are invalid and miners switch to non-SPV mode after 1 minute, then

90% of the time: 30 second of mining saved from wastage
10% of the time: 60 seconds wasted building on the invalid block

This means that on net, the miner saves 0.9*30 - 0.1*60 = 21 seconds and they are better off using SPV-mining.

The key to make it work is to have a timeout, so you can handle the (rare) invalid blocks correctly.

The timeout can be made less than 60 seconds, if they actually check the block they are building on when it is received.

If miners do this, then there is no risk to the network.  The miner automatically switches back to non-SPV mode after the 60 second timeout.  A fork can only exist for that long, so probably less than 1 block.

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.

To implement this attack, non-SPV-mining pools need to waste enough hash power to create a "bad" block. This is profitable to all of them together, but they have to cooperate.  Cooperation seems more difficult to achieve. THen again, if there is one single big pool, the insentive may be big enough for him to do it alone.

It's not difficult to calculate how big it should be; the main unknown paramter is for how long it sends the SPV-miners off to mind the wrong side of the fork.