Bitcoin Improvement Proposal BIP 110 has officially been advanced to the 'Complete' status in its official version 1.0.0, meaning the proposal's author has finalized the planning and recommends adoption across the network. The core goal of this proposal is to address the controversy surrounding the excessive use of node resources on the Bitcoin blockchain by non-financial data (such as inscriptions, tokens, and embedded files). It aims to purify the network by introducing a temporary consensus rule lasting one year. However, Saylor later published an in-depth article outlining his objections, launching a comprehensive critique of the proposal's underlying logic, technical scope, and activation mechanism. In terms of technical details and roadmap changes, BIP 110 proposes extremely strict and broad consensus restrictions. The proposal requires new scriptPubKeys to be limited to 34 bytes (with an exception for OP_RETURN, which retains 83 bytes), restricts the payload and script parameter witness items to 256 bytes, completely bans spending undefined witnesses and Tapleaf versions, disables Taproot annexes, caps Taproot control blocks at 257 bytes, and prohibits Tapscripts containing OP_SUCCESSx opcodes as well as the execution of OP_IF/OP_NOTIF. The most controversial aspect is its activation mechanism. BIP 110 abandons the traditional 95% miner readiness threshold defined by BIP 9, aggressively lowering it to a 55% miner signaling threshold. It also eliminates the usual timeout and 'FAILED' status, introducing a mandatory signaling period and a new 'EXPIRED' status after 52,416 activation blocks. The advancement of this proposal will impose direct commercial and technical costs on the evolving Layer 2 networks, advanced smart contracts (such as the BitVM development roadmap), and wallet compilation toolchains within the Bitcoin ecosystem. Saylor argues that BIP 110, in its pursuit of deployment speed, adopts a blunt approach by imposing restrictions that effectively sacrifice consensus layer flexibility, forcibly closing off scarce hooks in the design space that could have been used for future upgrades. This approach not only undermines backward compatibility, forcing Miniscript compilers and affected wallet toolchains into emergency adjustments, but could also lead to rare pre-signed Taproot workflows facing risks of frozen funds or unintended asset expenditures during the activation period. On a deeper commercial level, in the macro context of Bitcoin's block rewards halving every 210,000 blocks, miners' overall service fee income is becoming a critical security pillar for maintaining long-term network resistance against attacks. As block rewards approach zero, miners will need to rely on transaction fees to secure the network. Yet, by blindly suppressing demand for non-payment transactions without clearly quantifying the actual benefits to node bandwidth, storage, and validation load, BIP 110 risks causing an irreversible contraction in the overall fee market, which could weaken the incentive for hash power investment. So, I support Saylor's perspective!