Addressing remaining points on BIP 54

The recent discussion on the Bitcoin Development Mailing List highlighted some technical considerations regarding the potential for rolling nLockTime and nTime in the context of mining. Specifically, it was addressed that although some might speculate about future modifications to stratum protocols v1 or v2 to facilitate new functionalities, such alterations seem highly unlikely. The enforcement of nLockTime within the coinbase transaction as a consensus rule significantly limits its flexibility for mining purposes. This constraint exists because nLockTime has an established meaning within the network's consensus, ensuring that only minimal adjustments are viable until reaching the current block height, at which point alternative actions must be pursued.

Furthermore, the dialog shifted towards the practical aspects of mining operations, particularly focusing on the capabilities of Application-Specific Integrated Circuits (ASICs) and their controllers. It was clarified that ASICs, in practice, tend to manipulate the nTime field found in the block header, which presents fewer restrictions and allows for adjustments roughly every second. This approach is favored over attempting to roll nLockTime due to the ease with which nTime can be adjusted by the controller. Additionally, this method facilitates the modification of a nonce in the coinbase transaction, providing ample leeway for the ASIC through the utilization of nTime and several midstates. This conversation sheds light on the intricacies of mining technology and the strategic considerations involved in optimizing mining efficiency within the existing consensus rules and hardware capabilities.