3

I've been trying to understand what exactly happened in July 2015. Specifically, I can't figure out why F2Pool and AntPool mined for so long (~1 hour) on an unverified chain?

According to blockchain.info, the first orphaned block was generated at 2:09am [1], while the 6th block was generated at 3:05am [2]. This suggests that F2Pool was "SPV mining" for over an hour, which seems very risky considering they had no information about the validity of the preceding block that they built their first (invalid) block on (i.e. the block in [1]). I realize that block header timestamps could be off by a little bit, but the time should still be close to an hour, right?

Here's my understanding: I think I see how "SPV mining" can reduce orphan rates by starting to mine earlier on an empty block before verifying its predecessor. From [3] and [4], I understand that an SPV miner would mine block B on top of an unverified block header A (or hash, as in July 2015) under the assumption that it would receive A's block contents soon and verify them. This way, the miner would be sure that its SPV-mined, empty block B is also valid. I also understand that if block A is invalid, then the Bitcoin P2P network (and perhaps other gossip channels Bitcoin miners use such as BRN) will not relay the invalid block's contents to save bandwidth, which means the SPV miner now has to rely on a timeout to tell whether A is valid or not.

What I don't understand is how come F2Pool did not time out in July 2015? Did they not implement that logic? That would seem silly from a money making perspective.

I could not find much about this online.

PS: I've read the answer here but it doesn't explain why F2Pool went on to SPV mine for so long.

Improve this question

1 Answer 1

Reset to default
3

It seems that F2Pool implemented their version of SPV mining with insufficient thought to the effects it would have. The proof is right there in the blockchain: they they didn't implement a timeout.

It was a financially expensive mistake, but miners are highly incentivized to decrease latency, so not implementing SPV mining would also have cost them money.

Improve this answer
4
  • Are we sure this is true though? If so, wouldn't this be the first case where a miner implemented a mining policy that was guaranteed to lose them money big time if something went wrong, like in July 2015? I guess one could argue that this policy increased their revenues, but it seems like a modified policy with a timeout would've done the same thing and better.
    – Alin Tomescu
    Oct 13, 2016 at 21:13
  • If you trust the BlockCypher 'received_time' timestamps from their API, you can see that the BTC Nuggets Block was received at 2:09:34 am, and the last mined F2Pool block was received at 3:05:59 am. Note that this is different than the timestamp mined into the block, this is when Blockcypher's node actually saw the block for the first time on the P2P network.
    – morsecoder
    Oct 14, 2016 at 14:22
  • a modified policy with a timeout would've done the same thing and better - Absolutely, but hindsight is 20:20 :)
    – morsecoder
    Oct 14, 2016 at 14:23
  • Hehe, I suppose. To me, it's very surprising that a miner would implement logic that mines on an unvalidated chain for an indeterminate period of time, risking his reward coins. This mean one might not need 51% malicious miners to break Bitcoin. To be a little harsh, 51% incompetent seems enough.
    – Alin Tomescu
    Oct 14, 2016 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.