Addressing remaining points on BIP 54

The email from Sjors Provoost to Poinsot delves into various technical aspects regarding the Bitcoin protocol, specifically addressing concerns and suggestions related to transaction nonce handling, BIP54 implications, and consensus changes. Provoost begins by discussing Luke's concern about using the coinbase transaction's scriptSig to store an extranonce, noting that there is no consensus limit on the size of a transaction, which applies to the coinbase transaction as well. This situation leads to the point that the nLocktime field in the coinbase transaction could be utilized more efficiently as an extranonce due to its position in the serialized coinbase, potentially offering a speed advantage due to reduced computational work. However, it's unclear if mining software currently supports this optimization or if any non-published mining firmware exploits this technique.

Provoost also mentions that BIP54 aims to neutralize this theoretical speed advantage for miners, sparking a debate on whether it's beneficial to allow such advantages for energy consumption reasons. An alternative suggestion involves storing the height commitment in the commitment extension introduced by BIP141, which could address design concerns related to data availability and validation complexity for non-upgraded nodes and embedded signers. This approach, however, would necessitate a detailed design to avoid complicating the validation process, especially for devices with limited capabilities.

Further, Provoost proposes splitting the nLocktime field to include an extranonce, providing a potential solution to extend the utility of the nonce space without immediate concerns. He also touches on concerns raised by others regarding the risk of creating validity issues for smart contracts and the necessity of updating transaction toolchains post-BIP54 to avoid problems with new signature operation limits and transaction sizes.

Lastly, the email suggests that addressing long block validation times and difficulty adjustment exploits should be prioritized in the consensus changes. While less certain about the need to fix merkle tree malleability and duplicate coinbase transactions immediately, Provoost advocates for assigning a deployment bit to each proposed fix to facilitate better coordination within the ecosystem. This approach allows for separating the consensus changes into distinct proposals, which he believes is a better practice for development and deployment, even if it requires more coordination effort.

For further detail, the original discussion can be found at this link.