This approach involves a change in the proof-of-work algorithm, alongside smoothing out the subsidy schedule, both of which are seen as significant modifications to the security model underpinning previously mined UTXOs. The choice of hash function for proof-of-work is critical since not all functions offer the same level of security or have been subject to extensive cryptanalysis. There's a concern that selecting a less secure hash function could compromise the security of all users' coins, especially considering the vast increase in hash rate over the years.

Furthermore, the notion that fundamental changes affecting coin security should receive consent from a super-economic majority, including non-mining nodes, is emphasized. The proposal seems to endorse updates to the proof-of-work algorithm by a coalition of mining and upgraded non-mining nodes, potentially leading to security vulnerabilities due to the adoption of a weaker algorithm. Adding to this, the papers introduce ideas on full-node validation costs and censorship resistance but may benefit from considering the inherent difficulty of changing core aspects of Bitcoin's network as a valued feature.

There's also a critical view on the management of older nodes within the ecosystem, pointing out their potential as security risks due to Bitcoin Core's limited policy on backporting security fixes. The discussion extends to the broader issue of software maintenance, suggesting that a long-term support (LTS) policy similar to that of the Linux kernel could be beneficial for Bitcoin Core, encouraging operators of older nodes to adopt newer versions to mitigate security and scalability concerns before analyzing complex proposals like "forward block."

Lastly, the possibility of using a multi-stage deployment for the "forward block" concept is proposed. This would involve a new difficulty adjustment algorithm to extend the average block interval for upgraded mining nodes, followed by utilizing this increased block interval capacity for implementing a flexible block size on the forward chain. This suggestion aims to challenge the notion that on-chain settlement throughput cannot be improved without addressing existing issues such as the timewarp bug.