<p>Here's a very good article about slot battles, but in short, prop time is not a factor in winning or losing...</p>
<p><a href="https://www.beaver-stake-pool.net/post/slot-battles-height-battles-and-orphaned-blocks" rel="nofollow noreferrer">https://www.beaver-stake-pool.net/post/slot-battles-height-battles-and-orphaned-blocks</a></p>

CC BY-SA 4.0
2022-01-20T17:47:12.233Z
Nice article! I see why prop time alone not a factor in winning/losing a height battle. What I am more concerned about is the idea that such a high prop time may be indicative of some sort of malicious MEV. If I understood the article correctly, the stake pool in question here did not receive IOGP's block for a whole 40 seconds before pushing their block to the network. Does this mean that any SPO can orphan any block that comes before theirs just by not accepting it before publishing their own?
zhekson
CC BY-SA 4.0
2022-01-22T23:23:11.343Z
OP and @nomad0 Great question and answer.  The answer would be even better if it followed the guidelines at: https://cardano.stackexchange.com/help/referencing
gRebel
CC BY-SA 4.0
2022-01-20T13:13:56.347Z
2022-01-20T13:13:56.347Z
Tygar Pool
<p>Here is interesting discussion about height and slot battles, what I had.</p>
<p><a href="https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14" rel="nofollow noreferrer">https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14</a></p>
<p>Here some more details from @BEAVR:</p>
<p>I should clarify and probably update my blog post regarding Height Battles.</p>
<p>From my experience, height battles are actually won by whichever block was received first. The slot number has no effect. We discovered that relays accept which block comes first when looking into this problem:</p>
<p><a href="https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14" rel="nofollow noreferrer">https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14</a></p>

CC BY-SA 4.0
2022-01-24T08:17:50.083Z
That is not correct, height battles are won following the same rules as slot battles.
https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407
George - APEX Stake Pool
CC BY-SA 4.0
2022-01-24T08:02:19.453Z
2022-01-24T08:02:19.453Z
os11k
<p>Would someone please be so kind as to explain how a block with a <strong>43 second prop time</strong> wins a height battle???</p>
<ul>
<li>Block #: 6777986</li>
<li>Pool ID: 2cf87fadec7130c7e41910492073ae4dbe65ca462c1fdc3d2a56d015</li>
</ul>
<p>Perhaps I could use a refresher on shallow forks/rollbacks, but this just doesn't add up in my head... as far as I understand, the only way this is possible is if the higher-slot leader does not &quot;receive&quot; the previous block, and posts their own block in place of the most recent one. For such a large prop time, this seems like a massive arbitrage opportunity for the higher slot leader.</p>
<p>What can be done about, or is there a way to minimize, this?</p>
<p><a href="https://i.sstatic.net/0IBmY.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/0IBmY.png" alt="enter image description here" /></a></p>

<stake-pool><proof-of-stake><ouroboros>
Is a block winning a height battle with a 43 second prop time a potential form of MEV?
# Is a block winning a height battle with a 43 second prop time a potential form of MEV?

(Asked by: username_0 on 2022-01-20)

Would someone please be so kind as to explain how a block with a **43 second prop time** wins a height battle???

* Block #: 6777986
* Pool ID: 2cf87fadec7130c7e41910492073ae4dbe65ca462c1fdc3d2a56d015

Perhaps I could use a refresher on shallow forks/rollbacks, but this just doesn't add up in my head... as far as I understand, the only way this is possible is if the higher-slot leader does not "receive" the previous block, and posts their own block in place of the most recent one. For such a large prop time, this seems like a massive arbitrage opportunity for the higher slot leader.

What can be done about, or is there a way to minimize, this?

[![enter image description here](https://i.sstatic.net/0IBmY.png)](https://i.sstatic.net/0IBmY.png)

**Tags:** stake-pool, proof-of-stake, ouroboros

---

## 2 answers

### Answer by username_1 on 2022-01-20. Score: 1

Here's a very good article about slot battles, but in short, prop time is not a factor in winning or losing...

<https://www.beaver-stake-pool.net/post/slot-battles-height-battles-and-orphaned-blocks>

> **Comments:**
> **username_0**: Nice article! I see why prop time alone not a factor in winning/losing a height battle. What I am more concerned about is the idea that such a high prop time may be indicative of some sort of malicious MEV. If I understood the article correctly, the stake pool in question here did not receive IOGP's block for a whole 40 seconds before pushing their block to the network. Does this mean that any SPO can orphan any block that comes before theirs just by not accepting it before publishing their own?  
> **username_2**: OP and @nomad0 Great question and answer.  The answer would be even better if it followed the guidelines at: https://cardano.stackexchange.com/help/referencing  

---

### Answer by username_3 on 2022-01-24. Score: 0

Here is interesting discussion about height and slot battles, what I had.

<https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14>

Here some more details from @BEAVR:

I should clarify and probably update my blog post regarding Height Battles.

From my experience, height battles are actually won by whichever block was received first. The slot number has no effect. We discovered that relays accept which block comes first when looking into this problem:

<https://forum.cardano.org/t/how-to-figure-out-when-pool-wins-slot-battles-or-causes-height-battles/90639/14>

> **Comments:**
> **username_4**: That is not correct, height battles are won following the same rules as slot battles. https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407  

---

