There is an opportunity for SHA256 expander to be partially prefilled for a fixed public key if the inputs to the hash were reordered as hash(bytes(dG) || bytes(x(R)) || m). It was suggested that if the message precedes the nonce, it could lead to potential security risks where an attacker could find pairs of messages that result in the same midstate and get a signature that works for both messages. However, the current design with the pubkey logically prepended on the message is not sufficiently attacker controlled to apply this argument. It was noted that hardwiring part of the expander to a pubkey dependant way would be an optimization that virtually no one would use. The suggestion was made that if the hash function were defined as using 31 zeros then P||R||m (or P || 31 zeros bytes || R || m) could be used to cache an entire midstate for different pubkeys. It was also suggested that the final compression run in that case would only be the constant update with the length, which is an easy optimization.