Topic: "SPV Mining" or mining on invalidated blocks - page 2. (Read 3450 times)

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 agree with your point about the independent miners on the non-verifying pools, they would be incentivised to switch to verifying pools.

These forks are highly unlikely to last for a significant proportion of a 2016 block difficulty period. The difference to the readjust that such an event produces in a given difficulty period may not be significant enough to produce the hashrate decrease you're imagining. If attack victims switch relatively quickly, then the effect it has on the hashrate/difficulty is none, as you say.

So if a large majority of miners (both SPV and fully verifying) act rationally, then this invalid block attack would bring everyone back into the verifying fold. I expect they would do so, the range of irrational actions they have to choose from could only be interesting to someone being self destructive, they can't harm the network to any significant extent.

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?

So, if I understand correctly, SPV mining when nobody is broadcasting forking blocks reduces the orphan rate trom ~4% to nearly 0%.

However, SPV mining when non-SPV pools and miners ARE broadcasting forking blocks increases the orphan rate from nearly 0% to nearly 100%, right?


I guess that depends on how much non-SPV hash power is participating in the attack against the SPV pools?  With 100% participation in the attack, there is 0 incentive to continue SPV mining. With 0% participation there is obviously still an incentive for SPV mining.  I suppose the question that would be interesting to answer is "How much hash power needs to participate in the attack for SPV mining to overcome the current SPV incentive?"


Perhaps.

Or perhaps people would quickly adjust to trusting non-SPV mining, and SPV mining would die rather quickly.

If a non-SPV pool knows that the fork CAN happen in the future, and that they can profit from causing it themselves instead of just waiting for it to happen, wouldn't they WANT to do this?  Either way it's likely to happen, and the panics will result.  What's the benefit of NOT being the one that does it, especially if the pool thinks that any other pool might already be thinking about doing it?

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.

Very interesting attack vector I had not thought about. From what I understand the practice of SPV mining can reduce orphan rate from ~4% down to near ~0% from F2Pools claims. This would give a very strong incentive to continue this practice despite this risk. Additionally, this form of attack would cause multiple panics like we are seeing now which would undermine our whole confidence in the bitcoin ecosystem which is not something non-SPV mining pools would typically be interested in.

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?

https://bitcoin.org/en/alert/2015-07-04-spv-mining

Thanks to Peter Todd, Luke-Jr, and Gregory Maxwell careful watch we averted a disaster, but it is a little disconcerting this problem was allowed to fork the chain for so long causing a panic that is still not completely resolved.

A few points of consideration:
If you do the math the pool operators that "SPV mine" or building empty blocks on the longest invalidated header chain they are still incentivized to SPV mine as the latency reduction advantages gained from this practice exceed the ~50k lost during this fork in the chain.

We shouldn't leave it up to alerts and  warnings after the fact as the panic itself creates tremendous loss of confidence in our ecosystem.

Have there been any discussions on various solutions to either force or incentivize miners to validate their block headers?

Are there any proposals to implement a warning system that SPV/Web wallets could implement that would pickup the same alerts from Bitcoin Core and warn the users?