The proposal introduces a signaling mechanism that imposes a cost on signaling. This cost distribution is uneven, offering free signaling for those already making transactions but imposing a fee on others. There's concern this might distort usage by incentivizing users to split batched payments into multiple transactions to signal support at a lower cost, which could lead to increased demand for blockspace.

The use of the nLockTime field in transactions for signaling also faces criticism. This field is not unused as suggested; it plays a role in other protocol functions and is proposed for anti-fee sniping measures, which are incompatible with the suggested signaling mechanism. Moreover, most wallet software does not currently allow users to manually set nLockTime, limiting who can signal support without changing their software. Furthermore, this method introduces a unique fingerprint for transactions from software that enables manual setting of nLockTime, potentially affecting user privacy.

There are also concerns about the practicality of the signaling method. A transaction can only set one nLockTime value, restricting signals to support for only one proposal unless nLockTime is used as a bit array for multiple signals. Questions arise regarding how to interpret the signaling data, including the relevance of a single signaling transaction among thousands and the difficulty of distinguishing between apathy and opposition to proposals. The suggestion that miners could exclude signaling transactions if unprepared is seen as overly simplistic, as doing nothing is easier for miners, and inclusion of such transactions does not necessarily indicate endorsement.

To enhance the proposal, it is suggested that it should more thoroughly address these critiques and questions raised by others. A detailed motivation section is recommended to clearly outline the current issues this proposal aims to solve and how it plans to do so. It should also include a rationale section explaining the design choices, comparing them to alternative designs and related works. Furthermore, a section on backwards compatibility would be beneficial, detailing considerations for implementers regarding the use of nLockTime for anti-fee sniping alongside the new signaling proposal. Lastly, the specification needs to provide a clear syntax and semantics for developers to implement the proposal effectively.