"SPV Mining" or mining on invalidated blocks

[unamis76]

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?

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.

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.

[1714775900]

1714775900

[1714775900]

1714775900

[TierNolan]

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.

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.

Code:

a <- b <- c

A <- B <- C

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

The header d is received first

Code:

a <- b <- c <- d

A <- B <- C

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.

Code:

a <- b <- c <- d

A <- B <- C <- D

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.

Code:

a <- b <- c <- d <- e

A <- B <- C <- D

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.

Code:

a <- b <- c <- d <- e <- f <- g <- h

A <- B <- C <- D

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.

Code:

a <- b <- c <- d <- e
                 <- e*

A <- B <- C <- D

Soon afterwards E* is received.

Code:

a <- b <- c <- d <- e
                 <- e*

A <- B <- C <- D <- E*

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.

Code:

a <- b <- c <- d <- e
                 <- e* <- f

A <- B <- C <- D <- E*

and then F is received and validated.

Code:

a <- b <- c <- d <- e
                 <- e* <- f

A <- B <- C <- D <- E* <- F

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

[unamis76]

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

[cypherdoc]

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

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

[TierNolan]

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

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.

[Cryddit]

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 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?

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?

[gmaxwell]

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

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

[TierNolan]

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

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.