He explores a payment channel model where a casual user pre-pays cost-of-capital fees for a dedicated user's funds over the entire active lifetime of the channel. This allows for safe agreement on a long channel lifetime, with an example given of 110,000 blocks or approximately 2.1 years. The model includes provisions for casual users to renew their channels every 10,000 blocks, which is about 2.5 months.

John details the considerations for ensuring that timeout-trees can be processed within the blockchain's capacity. He calculates that with full block capacity devoted to processing leaves, one year allows for putting 100 million leaves onchain. He suggests that adding a two-year inactive period might be feasible for handling 100 million leaves but extending this to a 20-year period is impractical, implying a tradeoff between safety and scalability.

He also notes the importance of setting a minimum leaf value to ensure dedicated users have an incentive to act honestly. With a feerate of at least 2 satoshis/vbyte, each leaf must be worth at least 21,000 satoshis to make it economically viable for dedicated users to process them.

To analyze the scalability of the system, John wrote a Python program that factors in various parameters including the active and rollover periods of timeout-trees, transaction sizes, feerates, probability of timeout-trees being put onchain, and others. The program aims to minimize the combined cost of capital and expected costs of putting leaves onchain while ensuring all leaves are processed before expiration.

Using assumed values for these parameters, the results suggest that up to 65% of block space may be needed for processing timeout-tree leaves, with an inactive lifetime of 1.55 years and an expected overall cost of 2.5% of the casual user's funds.

John provides a GitHub link [2] to the program along with sample inputs and outputs, highlighting that other scalability limits exist, such as the rate at which HTLCs timeout and need to be processed onchain. His analysis seeks to determine when the trust/safety versus capital efficiency tradeoff becomes unavoidable.

[1] Unfortunately, John's message does not include the actual URL for section 4.8 and 5, so the reference cannot be provided here. [2] Similarly, the GitHub link mentioned by John is not included in the provided context.