He agrees with the analysis and suggests a different approach to address the issue. John proposes pairing dedicated user B with another dedicated user C, where each leaf of the timeout-tree funds a hierarchical channel. This idea is described in the "Improving Capital Efficiency" section of the post.John explains that if A_i (a casual user) performs an active rollover, funds not owned by A_i can always be used by B and C to route payments unrelated to the casual users in the timeout-tree. However, passive rollovers complicate this process as A_i's funds are neither definitely in the old timeout-tree nor in the new timeout-tree during the rollover. To overcome this complexity, John suggests using aj's idea of funding an HTLC from two possible sources, where one source will eventually be available to the offerer and offeree of the HTLC.By implementing this approach, B and C can utilize the funds from both the old and new timeout-trees that are not owned by A_i to route payments. If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds from the new timeout-tree to fund their HTLC, and vice versa.John also expresses concern about the "thundering herd" problem when using hierarchical channels to improve capital efficiency. He explains that casual users may become accustomed to ever larger timeout-trees without any issues. However, if a large number of dedicated users collude by failing to roll over timeout-trees simultaneously, they could create congestion on the blockchain and potentially steal a significant portion of the casual users' funds.To address this problem, John proposes a change to the Bitcoin consensus rules. Instead of timeout-trees expiring at a specific block height, they should only expire after a sufficient number of low-fee blocks have been added to the blockchain. This way, if dedicated users attempt to steal funds by not rolling over timeout-trees, the thundering herd of transactions from casual users would push up fees, preventing the timeout-trees from expiring and safeguarding the casual users' funds.John believes that this change would deter dedicated users from attempting such thefts, as it would also result in their capital being unavailable for a longer period of time. He mentions that he is currently writing a paper and post explaining this proposal in detail.In addition to the main points discussed above, John provides a few more details about the proposed mechanism. He suggests measuring time in low-fee windows instead of counting low-fee blocks, with the window size being programmable. This makes it harder for dishonest miners to collude with dedicated users and create enough fake low-fee blocks to enable theft. It also reduces the computational cost of counting the low-fee windows. The threshold for a "low-fee" block can be programmable, and there is a bound on how long one waits for low-fee windows to limit storage and compute overheads. Furthermore, a similar technique supports relative delays instead of absolute delays.John concludes by stating that he believes such a mechanism would be useful in various areas, including HTLCs, and emphasizes the need for a solution like this in the context of timeout-trees.