As can be seen, the change in staking difficulty algorithm was more than a cosmetic change for the network — it impacted day to day pricing of tickets massively. The issues with the original staking difficulty algorithm are best summarized by Dave Collins in DCP0001 - New Stake Difficulty Algorithm:

“The current stake difficulty algorithm [Epoch 1] satisfies the dead minimum requirement of maintaining a relatively stable ticket pool size which is important since the ticket pool size growing too large or too small can substantially alter the social contract between stakeholders and the network, disrupting the predictable nature of average time to vote a ticket, percentage of tickets that expire, and, consequently, the expected rate of return. However, the current algorithm [Epoch 1] also exhibits several shortcomings. Most notably, it allows the prices to swing too wildly which encourages all tickets to be purchased during a single interval when the price is artificially low, followed by discouraging any purchases at all for several intervals due to the price becoming artificially high. In short, very limited price exploration occurs which leads to several undesirable outcomes and behaviors such as a poor user experience due to intense fee competition during the single interval where tickets can reasonably be purchased and huge swings in mining hash power since miners direct large amounts of hash power at the network during the high fee interval and remove it after the interval is over.”

The volatility in ticket prices naturally impacted the ticket purchasing volume over short timeframes, which ultimately caused a deviation from network staking targets over the first staking epoch:

Target Ticket Pool Size: 40,960 tickets

Actual Average Ticket Pool Size: 42,000–43,000 tickets

In a close to perfect world, the ticket pool size should be very close to equal to the sum of 28 days of ticket volume. During staking epoch 1 that proved to not be the case, whereas staking epoch 2 has shown a much closer fit between the two.

It seems the cause for this spread during staking epoch 1 can be attributed to the volatility in ticket purchasing, with many instances of the absolute maximum number of tickets (2,880 tickets) being purchased during a 144 block staking window — flooding the ticket pool very quickly and pushing stake participation beyond the 40,960 ticket target. This seems like a reasonable conclusion because:

The average 28 day sum of ticket purchases only differ by ~0.3% (both around 40,600 tickets purchased over 28 days) between epochs 1 and 2

The difference in average ticket pool size differs by ~4% between epochs 1 and 2

This is a large gap in average ticket pool size when considering the ticket buying over a 28-day span is near equal in both staking epochs

Note: This comparison and calculation for these bullet points is done from blocks 15,000–150,000, in order to provide time for staking to stabilize in the Decred network’s early days

Below we have a chart that highlights this disparity, showing the % spread between:

(1) Number of tickets purchased in a rolling 28 day window (TRANSACTED in tickets)

(2) Actual average ticket pool size (currently LOCKED in tickets)

Please note — this is smoothed over 28 days to give us a clear picture of the trend and begins at block 15,000, which is around when staking conditions started to level out. Note how around block 150,000 (when new stake difficulty algorithm went live on mainnet) the % spread starting correcting itself and moving towards 0%: