He argues that such an approach would not only put the network at risk of significant harm but also create detrimental incentives for both users and miners. Users might be tempted by the short-term benefit of lower fees due to increased block space, neglecting the long-term consequences for the entire user base. Similarly, miners could be driven by the prospect of obtaining more block rewards at the expense of future miners, with larger miners disproportionately benefiting from increased block frequency. Riard suggests avoiding the introduction of a minimum transaction size; instead, he proposes making transactions below 64 bytes invalid, as detailed in his write-up available at DelvingBitcoin.

Riard's correspondence further delves into technical aspects concerning backend implementations, particularly focusing on Bitcoin full nodes reimplementations. He points out that transactions serialized without witness under 64 bytes have been non-standard in Bitcoin Core for over six years, indicating a pre-existing restriction that wouldn’t impact his proposed changes regardless of the witness data involved.

Additionally, Riard seeks clarification on suggestions regarding the use of nLockTime in the coinbase transaction, contrasting it with the idea of implementing a "monotonic counter in the past." His preference leans towards making the coinbase commitment mandatory for compatibility purposes, even suggesting that if changes are to be implemented, they could possibly include mandating the block height in nLockTime. This approach is seen as straightforward ("the Obvious Thing") and potentially beneficial if considered for future soft fork proposals, highlighting Riard’s intent to ensure that no significant aspect is overlooked in planning future network modifications.