A key argument against this proposal is the existence of a simpler, more efficient solution that does not necessitate the introduction of a new consensus rule. This alternative approach hinges on preventing attacks against simplified verification by enlarging proofs by approximately 400 bytes per block at most. Although this represents a roughly 70% increase in proof size, it's argued that such an increase is relatively insignificant in the broader context of network traffic.

Lightweight clients, for instance, already handle significantly larger data volumes through mechanisms like BIP157/158 compact block filters, which involve transferring extra megabytes of data even under optimal conditions. Therefore, the additional data from enlarged proofs is seen as manageable and unlikely to burden the network unduly. The concern, however, shifts when considering the validation of these merkle proofs within consensus protocols, especially following a script upgrade to Bitcoin. Here, the impact of the increased proof size becomes more pronounced, raising questions about its feasibility and potential implications for the network's operation. The ongoing discussions and the viewpoints shared, including those in the referenced thread here, highlight the complexity of implementing changes within Bitcoin's decentralized framework and underscore the need for careful consideration of any proposed modifications.