The UTXO holds funds belonging not only to B, but also millions of casual users, C_1.C_1000000. If B cheats by not signing any further lightning updates between now and time T+L, each casual user needs to drop their channel to the chain or lose all their funds.This situation presents a "thundering herd" problem where instead of the expected one-in/one-out transaction, there would be between 1M and 2M on-chain transactions as everyone recovers their funds. The number of casual users multiplied by the factor that depends on how many outputs each internal transaction has determines the additional transactions. The impact of this additional transaction volume depends on the timeframe over which they are spread. If it's a day or two, it might be impossible to handle, but if it's over a year or more, it may not be noticeable. Somewhere in between, it could result in paying a modest amount in additional fees.To address this concern, casual users can calculate how many extra transactions per block their worst-case scenario generates. They can then determine when to ensure all their funds are rolled over to a new UTXO, considering the timeout period. This reduces B's capital efficiency since B will own all the funds in Fx for five months before accessing them. Each UTXO has an active lifetime (LA) and an inactive lifetime (LI = 5 months), which would have been used by everyone to recover their funds if B attempted to block normal rollover. The capital efficiency is reduced by a factor of 1/(1+LA/LI).Casual users cannot easily reduce their LI timeout by splitting into different UTXOs because if the provider cheats or fails, all participants across each UTXO will need to drop to the chain to preserve their funds, competing with each other for confirmation. Collusion among different providers can also cause problems as it increases the number of transactions significantly.The email then presents a scenario for a provider issuing a new UTXO every week and having a million casual users as customers. The provider targets an LA of 16 weeks (~3.5 months) and each user has a balanced channel with $2000 of their own funds and $2000 of the provider's funds. In this case, only 30% of the $6.5B worth of working capital dedicated to lightning is available for routing.Optimizing the LA does not necessarily work because if a casual user spends all their funds and disappears prior to the active lifetime running out, those funds cannot be easily spent by B until the total lifetime runs out. One possible solution to this is peering with a dedicated node and having a timeout path involving "you+them+timeout." This way, the funds can be rolled into a channel with the dedicated peer and used for routing.Varying the timeout at different layers of the internal tree is another option. For example, giving 500k users with a $10 balance a timeout of 16 weeks and giving the remaining 500k with an average $2000 balance a timeout of 26 weeks. Each group will calculate LI based on their timeout, and the rollover periods will vary accordingly. However, this may result in idle balances and should be carefully considered.Overall, the email raises concerns about what happens if the scalable path does not work and a large volume of transactions needs to be dumped on-chain. It suggests measuring and addressing this concern to ensure the smooth functioning of the system.