The sender argues that this classification may not be so straightforward in practice, as trust assumptions in Lightning, for example, are more of a matrix than a dichotomy. There are various choices and trade-offs to consider, such as using a full-node or light client for block-relay, different mempool sizes for fee estimations, routing HTLCs, and running local watchtowers.The sender suggests introducing different scaling notions to measure the performance of off-chain constructions. These include onboarding scaling, which considers the number of users that can co-exist off-chain while considering throughput limits; transactional scaling, which focuses on the number of transfers that can be performed off-chain per on-chain transaction; and user resource scaling, which determines how much resource a user should mobilize/consume to make a trust-minimized usage of the off-chain construction.The proposal mostly focuses on onboarding scalability, maximizing the number of channels owned by a user. However, it is unclear if other scalability dimensions are being weighted. The sender mentions that no known protocol using the current Bitcoin consensus rules allows for the creation of a large number of Lightning channels from a single on-chain unspent transaction output (UTXO). They provide an example of a potential solution involving radixpool and Musig2, but acknowledge challenges with rebalancing and subranch transactions hitting the chain.The sender points out that the requirement for casual users to sign transactions specifying the exact set of casual users whose signatures are required creates a difficult group coordination problem. They mention two more precise problems related to this coordination: the dynamic novation of the group and the dynamic update of the accounts/channels owned by the users. Additionally, there is uncertainty about having a dedicated user as a gateway to route the balance and the potential for jamming, which may affect draining in the network.The sender also raises concerns about the design goal of casual users performing actions at specific times in the future. They question whether there is a guarantee that an on-chain transaction triggering the move of funds will be broadcasted by another user, especially considering mempool congestion and the need for fee risk mitigation. The meaning of "immediately-accessible" is also unclear in terms of confirmed or unconfirmed transactions.Lastly, the fault-tolerance of the off-chain construction is described as unclear, particularly if an unavailable or erring user causes the entire construction to end up on-chain. This is seen as a significant defect in the radixpool or old school apo channel factory.Overall, the email provides feedback and raises several questions and concerns regarding the proposed classification of users, scaling notions, group coordination, routing, and fault-tolerance in off-chain constructions.