<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2016-10-13T21:13:02.987Z
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
CC BY-SA 3.0
2016-10-14T14:22:39.127Z
If you trust the BlockCypher 'received_time' timestamps from their API, you can see that the [BTC Nuggets Block](https://api.blockcypher.com/v1/btc/main/blocks/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99) was received at 2:09:34 am, and the [last mined F2Pool block](https://api.blockcypher.com/v1/btc/main/blocks/000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436) 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
CC BY-SA 3.0
2016-10-14T14:23:33.660Z
`a modified policy with a timeout would've done the same thing and better` - Absolutely, but hindsight is 20:20 :)
morsecoder
CC BY-SA 3.0
2016-10-14T14:34:03.620Z
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
CC BY-SA 3.0
2016-10-13T20:19:40.250Z
2016-10-13T20:19:40.250Z
morsecoder
<p>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 <strong>unverified</strong> chain?</p>
<p>According to blockchain.info, the first orphaned block was generated at 2:09am [<a href="https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99" rel="nofollow noreferrer">1</a>], while the 6th block was generated at 3:05am [<a href="https://blockchain.info/block/000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436" rel="nofollow noreferrer">2</a>]. This suggests that F2Pool was &quot;SPV mining&quot; 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 [<a href="https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99" rel="nofollow noreferrer">1</a>]).
I realize that block header timestamps could be off by a little bit, but the time should still be close to an hour, right?</p>
<p><em>Here's my understanding:</em> I think I see how &quot;SPV mining&quot; can reduce orphan rates by starting to mine earlier on an empty block before verifying its predecessor. From [<a href="https://bitcointalk.org/index.php?topic=1108668.msg11799081#msg11799081" rel="nofollow noreferrer">3</a>] and [<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009333.html" rel="nofollow noreferrer">4</a>], 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.</p>
<p>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.</p>
<p>I could not find much about this online.</p>
<p>PS: I've read the answer <a href="https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa">here</a> but it doesn't explain why F2Pool went on to SPV mine for so long.</p>

<bip66>
July 2015 forks and SPV mining: Why did F2Pool and AntPool mine an unverfied chain for so long?
Alin Tomescu
# July 2015 forks and SPV mining: Why did F2Pool and AntPool mine an unverfied chain for so long?

(Asked by: username_0 on 2016-10-13)

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](https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99)], while the 6th block was generated at 3:05am [[2](https://blockchain.info/block/000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436)]. 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](https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99)]).
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](https://bitcointalk.org/index.php?topic=1108668.msg11799081#msg11799081)] and [[4](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009333.html)], 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](https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa) but it doesn't explain why F2Pool went on to SPV mine for so long.

**Tags:** bip66


---

## 1 answers

### Answer by username_1 on 2016-10-13. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: If you trust the BlockCypher 'received_time' timestamps from their API, you can see that the [BTC Nuggets Block](https://api.blockcypher.com/v1/btc/main/blocks/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99) was received at 2:09:34 am, and the [last mined F2Pool block](https://api.blockcypher.com/v1/btc/main/blocks/000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436) 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.  
> **username_1**: `a modified policy with a timeout would've done the same thing and better` - Absolutely, but hindsight is 20:20 :)  
> **username_0**: 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.  

---

